Sales pipeline stages that tell the truth: exit criteria, outcomes and the stuck-deal test

Sales pipeline stages are the steps a deal passes through between first contact and a decision. A good stage is defined by an exit criterion: a fact you can check that proves the deal has earned the next column. "Proposal sent" is a stage only if everyone agrees what a sent proposal is and what had to be true before it went out.

Without those definitions, a pipeline board shows opinions. Two salespeople with identical deals put them in different columns, the forecast mixes optimism with evidence, and the weekly pipeline review turns into an argument about where a card belongs. This guide shows how to define stages that hold up, how many you need, and which metrics tell you the pipeline is working.

A stage is a fact about the buyer, not a task for the seller

The most common mistake is naming stages after what the salesperson does next: "Call", "Send deck", "Follow up". Those are tasks. They belong on the deal as activities with due dates, and they repeat at every stage.

A stage describes what the buyer has committed to. Each move to the right should represent new evidence that this customer is more likely to buy than they were yesterday. That is what makes stage counts mean something: twenty deals in Proposal should be twenty buyers who have done the same things, whoever owns them.

A quick test for any stage name: could a manager look at the deal record and verify, without asking the owner, that the deal belongs there? If the answer depends on the owner's mood, the stage needs a sharper definition.

A worked example: six stages with exit criteria

Here is a pipeline for a typical B2B service sale, the kind with a discovery call, a proposal and a decision by more than one person. Adjust the names; keep the shape of the right-hand column.

Notice what is missing: there is no "Lost" column and no "Won" column in the middle of the process. Those are outcomes, and the next section explains why they deserve their own field.

Notice also that every criterion is written in the past tense. "Budget is known" can be checked. "Discuss budget" cannot. Writing criteria in the past tense is the fastest way to turn a list of activities into a list of stages.

Keep outcomes out of the stage list

Many CRMs model "Won" and "Lost" as the last two columns of the board. It looks tidy and quietly destroys information. When a deal is dragged into "Lost", the board forgets where it was lost, and the stage where you lose most deals is the single most useful thing a pipeline can tell you.

The cleaner model treats stage and outcome as two independent fields:

• Stage is the position in the process. Each pipeline has its own list.
• Outcome (or status) is the same everywhere: in progress, won, lost, on hold.

A deal lost at Proposal stays at Proposal with the outcome Lost. Now the report can say "we lose 40% of deals after the proposal and 5% after negotiation" (an illustrative figure), which points directly at pricing or proposal quality. A deal put on hold because the buyer's budget froze leaves conversion maths alone instead of counting as a loss.

Record a reason when a deal is lost. A short fixed list works better than free text: price, timing, chose a competitor, no decision, not a fit. After a quarter, the reasons and the stage together tell you whether the problem is the leads, the offer or the follow-up.

How many stages, and when to split the pipeline

In our experience, five to seven stages between first contact and decision suit most B2B sales. Fewer than four and the board cannot show where deals stall; more than eight and stages start to describe tasks. Two signals that a pipeline has too many stages:

1. Cards skip columns. If deals routinely jump from stage 2 to stage 5, stages 3 and 4 are not real steps for most buyers.
2. Two stages always move together. If every deal leaves "Demo booked" for "Demo done" within a day, they are one stage with a task inside it.

Split into separate pipelines when the process differs, not when the product does. A self-serve subscription closed in one call and a six-month equipment sale with a site visit need different boards. Two subscription tiers sold the same way need one board and a product field. Every extra pipeline fragments reporting, so the burden of proof is on the split.

Time in stage: the metric that finds stalled deals

Conversion between stages tells you where deals die. Time in stage tells you where they wait, and waiting is where most deals start dying. For each stage, look at how long deals usually spend there and which ones have overstayed.

Use the median rather than the average. One deal forgotten in Discovery for nine months drags the average up and hides the fact that most deals pass through in a week. The median ignores that outlier and shows the normal pace.

Then give every stage an expected duration: Qualified within 5 days, Proposal within 10, and so on, based on your own history. A deal that passes its stage's limit is stuck, and stuck deals deserve a list of their own rather than a manager scrolling the board looking for old cards. The fix for a stuck deal is usually a specific next step with a date, or an honest decision to mark it lost.

A stage limit on the number of cards is useful too, especially for stages that need a scarce resource, such as a solutions engineer for demos. When the column passes its limit, the problem is capacity, not effort.

How Nextora handles stages, outcomes and stuck deals

In Nextora a deal has two independent fields. Stage is its place in a pipeline: each pipeline has its own list, and switching pipelines replaces it. Status is the outcome: In progress, Won, Lost, On hold, the same in every pipeline. Neither changes the other, so a deal can be lost at the stage where it actually stopped, and Lost is available even in a pipeline with no column for lost deals.

Each stage has a type that decides how it counts: Active is work in progress, Won counts as a conversion, Lost is a refusal, and Paused is excluded from conversion. So teams that want closing columns on the board can have them, while the outcome itself is always recorded in Status. A column can carry a card limit; the counter reads current / limit and turns red once it is passed. The top of the board shows money in flight, won this month and the probability-weighted forecast.

When you create a pipeline by describing your process in a sentence, such as "equipment sales with a site visit and a quote to approve", the pipeline is composed with its stages, their order and a test for each: the sentence that says how you can tell a deal is already here. That test is the exit criterion from this article, written for you as a starting point.

Pipeline analytics is computed from the history of stage moves. Its Time in stage table shows each stage's median, average and maximum, how many cards passed the threshold and how many are there now. The stagnation threshold comes from the stage's expected duration, or from your own history when none is set. The CRM page shows the board and the analytics side by side.

A one-hour pipeline audit

1. Export the deals that closed (won or lost) in the last two quarters, with the stage each was in when it closed.
2. For each stage, write the one-sentence exit criterion. Where the team disagrees, that disagreement is your first fix.
3. Find stages that are skipped by most deals and merge them.
4. Check whether Won and Lost are columns. If they are, move them to an outcome field and record a loss reason going forward.
5. Set an expected duration per stage from the median of past deals, and review the stuck list weekly.

Stages only work if the records underneath are clean. The five records a CRM actually needs covers where a deal should sit relative to leads and contacts. Once stages are honest, the forecast becomes worth reading: see weighted pipeline forecasting. And the stage before all of these, the first reply to a new enquiry, is covered in speed to lead.