B2B Sales Pipeline
Stages Template
(Built on Buyer State,
Not Seller Activity)

Pipeline stages are the skeleton of your CRM and your forecast — the structure that says where every deal is and how close it is to closing. And most B2B pipelines are built on the wrong skeleton: stages named after what the seller did ("demo scheduled," "proposal sent") rather than where the buyer is in their decision. The distinction sounds subtle and is decisive, because a pipeline built on seller activity tracks your effort, while a pipeline built on buyer state tracks your progress — and only the second produces a forecast that means anything. A deal can have a "proposal sent" without the buyer being anywhere near a decision; the proposal going out tells you what you did, not where they are. This guide is a B2B pipeline stages template built on buyer state, with the exit criteria that make each stage real — the structure that turns your pipeline from a record of seller activity into a reliable map of where deals actually stand.

The reason the buyer-state principle matters so much is that the entire point of a pipeline is to predict and diagnose, and both require the stages to correspond to real deal progress. A forecast works by assigning probabilities to stages, which only makes sense if reaching a stage actually means a deal is more likely to close — true for buyer-state stages (a buyer who has confirmed budget and a decision timeline really is closer) and false for activity stages (a sent proposal does not move a buyer who was not ready). Diagnosis works by finding where deals stall, which requires stages that represent real points in the buyer's journey where stalls are meaningful. Build the pipeline on seller activity and you forfeit both: the forecast is built on stages that do not predict, and the diagnosis is built on stages that do not correspond to where deals actually die. The template below is built entirely on buyer state for exactly this reason — so the pipeline does the predicting and diagnosing it exists to do.

The Principle: Buyer State, Not Seller Activity

The foundational rule of pipeline design is that stages represent where the buyer is, not what the seller did. A seller-activity stage ("demo completed") records an action you took; a buyer-state stage ("solution validated — buyer agrees we solve their problem") records a position the buyer has reached. The difference shows up everywhere downstream. Activity stages let deals advance because you did something, even if the buyer did not respond — so the pipeline fills with deals that "progressed" on seller activity while the buyers stayed put, inflating the forecast with deals going nowhere. Buyer-state stages only advance when the buyer actually moves, so the pipeline reflects real progress and the forecast is grounded in where buyers genuinely are. This is why every stage in a well-designed pipeline is phrased as a buyer state with a verifiable condition — not "we sent a proposal" but "the buyer has agreed on scope and price and committed to a decision timeline." The test for any stage you are tempted to add: does it describe something the buyer did or reached, or something the seller did? If the latter, rewrite it as the buyer state that activity was supposed to produce, or cut it.

The B2B Pipeline Stages Template

A clean B2B pipeline needs about five stages plus closed outcomes — enough to model the buyer's journey, few enough to apply consistently. Each is a buyer state with an exit criterion.

• 1 · Qualified. The buyer fits the ICP and a real two-way conversation is established. Exit criterion: verified ICP fit and an engaged contact with standing to evaluate — not just a name in a list.
• 2 · Discovery / Need Confirmed. The buyer has a real, prioritized problem and a path to a decision. Exit criterion: confirmed pain, an identified decision process, and a plausible timeline — verified, not assumed.
• 3 · Solution Validated. The buyer agrees your solution addresses their specific problem. Exit criterion: the buyer has seen how you solve their articulated problem and confirmed it fits — the demo or evaluation landed.
• 4 · Commit / Proposal. Terms are aligned and there is a mutual plan to close. Exit criterion: agreement on scope and price, the real decision-makers engaged, and a shared, dated path to signature.
• 5 · Closed Won / Closed Lost. The deal resolved. Exit criterion: a signed agreement (won) or a clear, recorded reason (lost) — captured honestly so the data informs future deals.

Notice every stage is a buyer position with a checkable exit condition, and there are five, not twelve. This is the skeleton most B2B teams should start from and adapt — not adopt a longer, activity-based pipeline because more stages feel more rigorous.

How Many Stages You Actually Need

Founders tend to err toward too many stages, believing more granularity means more insight — but excess stages degrade the pipeline rather than improving it. Too many stages create ambiguity about which stage a deal is in (when the boundaries between stages are fine, reps disagree and place deals inconsistently), add friction to keeping the pipeline updated, and produce per-stage conversion data so thinly spread it is statistically meaningless. The right number is the fewest stages that capture the meaningful transitions in your buyer's journey — usually around five for B2B, occasionally a few more for genuinely complex enterprise sales with distinct, meaningful phases. The test for whether a stage earns its place: does crossing into it represent a real, meaningful change in the buyer's likelihood to close, with a verifiable criterion that distinguishes it from the stage before? If two adjacent stages do not have a clear, checkable difference in buyer state, they should be one stage. Conversely, too few stages (just "open" and "closed") give you no diagnostic resolution — you cannot see where deals die. The balance is enough stages to diagnose and forecast, few enough to apply consistently, each representing a real buyer-state transition — which for most B2B companies lands around five.

Stage Probabilities: Earned, Not Assigned

Most CRMs let you assign a win probability to each stage — a deal in "Commit" is, say, 70 percent likely to close — and these probabilities are how stage-based forecasting works. The common mistake is to assign these probabilities by intuition ("Commit feels like 70 percent") rather than deriving them from your actual historical conversion data. An assigned probability is a guess dressed as a number; an earned probability is the real historical rate at which deals in that stage have closed, which is what makes the forecast trustworthy. The discipline is to calculate, from your closed deals, what fraction of deals that reached each stage actually went on to win, and use those real rates as your stage probabilities — updating them as more data accumulates. This only works if the stages are buyer-state stages with consistent exit criteria, because then "reached Commit" means the same thing across deals and the historical rate is meaningful; with inconsistent activity stages, the historical "rate" is noise because the stage meant different things for different deals. So earned probabilities and buyer-state stages reinforce each other: the buyer-state stages make the historical conversion rates meaningful, and the meaningful rates make the forecast accurate. A pipeline with buyer-state stages and earned probabilities produces a forecast grounded in how your deals actually convert; a pipeline with activity stages and guessed probabilities produces a confident number with no basis in reality.

The practical implication is to treat your stage probabilities as a measured quantity that you recalculate periodically from real outcomes, not a set-and-forget guess. As your conversion rates shift — because the market changed, the motion improved, or the ICP sharpened — the earned probabilities shift with them, keeping the forecast calibrated to current reality. This is a small discipline with a large payoff: it is the difference between a forecast you can run the business on and one that merely looks quantitative while resting on intuition.

The Pipeline Stage Mistakes to Avoid

Beyond activity-based stages, a few specific pipeline mistakes recur. The first is the "happy ears" stage problem — reps advancing deals to later stages based on optimism rather than the exit criterion, so the pipeline looks healthier than it is and the forecast inflates; the cure is enforcing the exit criteria, not just defining them. The second is the graveyard stage — a stage (often an early one) where deals accumulate and never move or get cleared, padding the pipeline with dead deals that distort every metric; the cure is hygiene discipline that ages out stalled deals. The third is asymmetric closed-lost data — recording wins carefully but losses lazily ("lost to competitor" with no detail), forfeiting the diagnostic value of understanding why deals die; the cure is capturing honest, specific loss reasons. The fourth is stage-stuffing for activity tracking — adding stages to track tasks (like "follow-up sent") that belong as activities or tasks, not pipeline stages, which clutters the pipeline with non-buyer-state steps. Each mistake degrades the pipeline's reliability as a forecasting and diagnostic instrument, and each traces back to either violating the buyer-state principle or neglecting the hygiene that keeps the stages honest. A well-built pipeline is not just well-designed once; it is well-maintained continuously, with the exit criteria enforced and the data kept clean, which is what keeps the buyer-state skeleton from quietly filling with the activity-stage and dead-deal rot it was designed to avoid.

Adapting the Template to Your Motion

The template is a starting point to adapt, not a universal answer, because the right stages depend on how your specific deals actually move. A product-led motion with a self-serve trial might need a stage capturing the trial-to-sales-conversation transition; a complex enterprise sale might need a distinct stage for technical evaluation or procurement, which are real, meaningful buyer-state phases in that motion. The adaptation principle stays constant even as the stages change: every stage must represent a real buyer state with a verifiable exit criterion, and there should be the fewest stages that capture the meaningful transitions in your buyer's journey. So you adapt by mapping your actual buyer's journey — the real sequence of states a buyer passes through on the way to buying from you — and defining a stage for each meaningful transition, with its exit criterion. What you do not do is adapt by adding activity stages or by proliferating stages for granularity's sake; the adaptation is about matching the stages to your buyer's real journey, not about making the pipeline more elaborate. Done right, the adapted pipeline is recognizably built on the same buyer-state, exit-criteria, lean-stage principles as the template, just mapped to your specific motion rather than the generic one.

FAQ: B2B Pipeline Stages Template