When a sales team grows, someone usually suggests a second pipeline in the CRM. One for the new product, one for the region in the south, one for partners, one for the big accounts. Each request sounds reasonable. A year later the company has five pipelines, nobody knows which one a new deal belongs in, and the weekly forecast is a sum of numbers that were never defined the same way. Pomio CRM starts from the opposite assumption: one shared pipeline that the whole team understands.
What a pipeline is for
A pipeline is a description of your sales process: the steps a deal goes through and the conditions for moving to the next step. Its value comes from everyone using the same definitions, which is why shared stage definitions matter so much. A pipeline is not a folder for sorting deals by person, product or region. As soon as it is used that way, the stages start to mean different things in different places.
When a second pipeline is justified
A separate pipeline makes sense only when a type of sale follows a really different process:
Different steps. A one-off installation project needs a site visit, a quote and a planning date; a software subscription moves from trial to proposal to contract. Forcing both through the same stages means half the stages are skipped or misused.
Different exit criteria. If what “qualified” or “proposal sent” means is different for each type of sale, a shared stage hides that difference. Check this against the exit criteria of each stage.
Different cycle length. A sale that closes in a week and one that takes nine months distort each other’s conversion rates and days-in-stage figures when they share a pipeline.
Not really a sale. Renewals, partner recruitment or recruitment of staff are sometimes squeezed into the sales pipeline. If the steps have nothing to do with selling, they do not belong there.
What is not a reason for another pipeline
Most requests for an extra pipeline are really requests for a view. A salesperson wants to see only their own deals, a manager wants to see one team, someone wants a list of deals for one product. That is what owners, teams, labels and filters are for. Splitting by region or team in particular creates trouble, because the structure of teams changes more often than the sales process, as described in whether CRM teams should follow the org chart or the way you sell. The same applies to new versus existing customers: tracking them separately is usually a field or label, not a whole new pipeline.
The hidden cost of several pipelines
Every pipeline needs its own stage definitions, its own exit criteria, its own probabilities and its own place in the weekly review. Reporting gets harder: the total pipeline value is only meaningful if the stages are comparable, and conversion between stages cannot be compared across pipelines. Deals end up in the wrong pipeline and have to be moved. New colleagues have to learn several processes before they can enter their first deal. For a team of five to twenty people that overhead rarely pays off.
A simple test before you add one
Write the stages of the proposed pipeline next to the existing ones. If at least half the stages, or their exit criteria, are different, a second pipeline may be justified. If the difference is mainly who works the deal, which product it is or where the customer is located, keep one pipeline and add a field, label or team instead. Keep the number of stages small in either case, as discussed in whether a pipeline should have a maximum number of stages.
How Pomio CRM helps
Pomio CRM is built around one shared pipeline per organisation, so the team works with the same stages and the forecast adds up. Who sees which deals is set by role, sales rep, sales manager, viewer or organisation admin, and by scope own, team or organisation, enforced on the server, so separate views do not require separate pipelines. Deals have an owner, are linked to companies and contacts and can be filtered and labelled. An overview is on the features page.
A practical checklist
Start with one pipeline; write down the stages and their exit criteria; handle people, teams, regions and products with owners, teams, labels and filters; add a second pipeline only when the steps or exit criteria are really different; give every pipeline an owner who maintains its definitions; review once a year whether each pipeline is still used and merge the ones that are not.