Multiple Sales Pipelines: When to Split One Pipeline Into Two

Split a sales pipeline into two only when deals exit each stage on different criteria, not because a different team, territory or product line sells them. If two deal types share the same stages and the same signals that move a deal forward, keep them on one pipeline with a filter, in a spreadsheet or in Senitix CRM.

This guide is for a sales manager or a RevOps lead deciding whether a second pipeline is worth managing, not a rep looking for stage names to copy. For what a pipeline’s stages are and how they work, see what a sales pipeline is; this post is about when one board becomes two, and how to make that split without losing deal history.

What is the test for splitting a sales pipeline into two?

A pipeline is a stage list plus the exit criteria that move a deal from one stage to the next: what has to be true before it advances. Two deal types belong on separate pipelines when that exit criteria genuinely differs, not when the people selling them do.

Ask three questions about the deals you are thinking of splitting:

• Do they reach a decision the same way? The same number of stakeholders, the same kind of proof (a demo, a reference, a usage report) and roughly the same timeline.
• Does one stage list describe both without half its stages reading “N/A”? If a renewal deal skips “Demo Completed” and “Needs Discovery” every time, it isn’t missing steps: it’s a different process wearing your new-business stages.
• Would a manager reading the board misread a stage for one deal type? “Proposal Sent” means one thing for a first-time buyer and something else for a partner reseller waiting on margin approval.

If the honest answer to any of these is no, those deals need their own stage list: a second pipeline. If the answer is yes to all three, you have one process with two labels on it, and a pipeline filter or a “deal type” field fixes it more cheaply than a second board.

Why does splitting by team, not process, backfire?

The tempting reason to add a pipeline is organizational: give the enterprise team its own board, give SDR-sourced deals their own board, give each region a board. None of that changes what has to be true for a deal to move: it relabels the same stages under a different name, and now two boards need updating every time the sales process changes.

A pipeline describes a process; a territory, a team or a rep is a way of slicing that process, not a different one. If what you actually want is “show me only my region’s deals” or “show me only deals I own,” that’s a filter or a saved view on one pipeline, not a second pipeline. Add a pipeline only when what a deal has to prove before it moves is genuinely different, usually true across deal types, rarely true across org-chart lines.

What are the four most common pipeline splits?

Most teams that split a pipeline are drawing one of four lines. The stage names below are illustrative: copy the shape, not the words, and adjust them to what your own team already agrees moves a deal.

Example: an Austin SaaS team adds a renewal pipeline

Example: a 12-rep B2B SaaS company in Austin sells scheduling software on annual contracts. For a year, renewals sat as deals in the same pipeline as new business, parked in “Negotiation” because none of the later stages fit: there was no demo to complete and no proposal to send, only a decision to keep paying. The sales manager couldn’t tell, from the board, whether a stalled “Negotiation” deal was a new prospect stuck on price or an existing customer who hadn’t answered a renewal email. The two needed different attention, and the shared pipeline hid which was which. The company and figures are illustrative.

The fix wasn’t a new stage bolted onto the existing pipeline: it was a second pipeline for renewals, with its own four stages built around usage data and a renewal quote instead of a demo and a discovery call. New-business deals stayed exactly where they were. The forecast review now opens two boards instead of scrolling past renewal deals stuck in the wrong stage, and win rate on each pipeline reads as a real number instead of a blend of two different sales motions. On running the renewal process itself, see renewal management.

How do you migrate deals into a new pipeline without losing history?

Splitting a pipeline is a small project with an owner at each step, not a setting you flip on a Friday afternoon.

1. Name the split and write its one-sentence rule. Owner: sales manager or RevOps. Output: a pipeline name and a sentence that says which deals belong in it: “any deal on an existing customer’s account” is a rule; “the enterprise team’s deals” is not.
2. Write the stage list and what exits each stage. Owner: whoever runs that process day to day. Output: a stage list short enough to fit on one screen, with a plain sentence for what has to be true before a deal leaves each stage.
3. Decide the cutoff. Owner: RevOps. Output: a written rule for which deals move, usually “new deals of this type start here; deals already open finish on the old pipeline” rather than moving everything on day one.
4. Map old stages to new ones. Owner: RevOps. Output: a one-to-one mapping, even an approximate one, so a deal’s stage history reads as a continuation rather than starting over at stage one.
5. Run one review meeting on the new board before it’s official. Owner: sales manager. Output: a short list of anything the stage list got wrong, fixed before the whole team relies on it.
6. Set the roll-up rule. Owner: RevOps. Output: one dashboard or report that adds both pipelines back together for whoever needs total pipeline value, so splitting for clarity doesn’t cost the company a single number when the board needs one.

What does splitting a pipeline too early cost you?

A pipeline with too few deals in it can’t forecast anything: a “50% win rate” on four deals is two coin flips, not a trend, and a manager who reports it as one invites a question they can’t answer. Splitting early usually trades one readable number for two unreliable ones.

The other cost shows up in maintenance, not in the first week. Every pipeline’s stage list has to change when the sales process changes (a new qualification step, a renamed stage, a new required field), and two pipelines mean doing that twice, in sync, or watching “Negotiation” quietly come to mean different things on different boards. A company-wide report that adds pipelines together also has to agree on what each stage counts as, which is one more thing that can drift.

None of this argues against splitting when the test above says to. It argues for splitting on a real difference in exit criteria, where the second pipeline earns its keep, rather than splitting on an org-chart line that a filter would have handled for free.

How do you run multiple pipelines in Senitix CRM?

Senitix CRM supports more than one pipeline, each with its own stages. A deal record carries the same fields (amount, close date, probability, owner) on every pipeline, and each stage can show guidance text and up to five key fields, so the team sees what it agreed has to be true before a deal moves; the product shows this, it doesn’t enforce it. See deals and pipelines for the rest of what a pipeline record holds.

Whether your team needs one pipeline or several is a process question that belongs in CRM strategy, before it becomes a setup task; plan details are on the pricing page.

Frequently asked questions

How many pipelines should a sales team have?

Most teams need just one pipeline for a single sales motion; two to four covers most companies that split on a real process difference, such as new business, renewal and a channel motion. Add one only when the test above says the exit criteria genuinely differ, not to give a team its own board.

Can a CRM have multiple pipelines with different stages?

Yes: most CRMs, Senitix CRM included, let each pipeline carry its own stage list, so a renewal pipeline’s stages don’t have to match a new-business pipeline’s. What differs between vendors is how many pipelines each plan level includes and whether a stage can carry guidance for the team, not whether the feature exists at all.

Should renewals live in the same pipeline as new business deals?

Only if they genuinely exit the same way, which is rare. A renewal is usually decided on usage and a budget cycle, not a demo and a discovery call, so it needs its own stage list. See renewal management for a full renewal process.

What is the difference between a pipeline and a filtered view?

A pipeline is a stage list with its own exit criteria; a filtered view is a slice of one pipeline (by owner, region or a “deal type” field) that reuses the same stages. If the two things you’re comparing move through identical stages, you want a view, not a second pipeline.