If two salespeople would put the same deal in different stages, your pipeline is not a forecast. It is a collection of opinions with a total at the bottom.
- ›The buyer-evidence test for stage definitions
- ›How many stages you need
- ›Exit criteria that make stages mean something
- ›Keeping the pipeline honest without policing it
The buyer-evidence test
A stage should be defined by something the buyer did, not by something the seller believes.
Bad stages: interested, warm, very interested, likely to close. These describe seller optimism, and optimism does not distribute evenly across a team.
Good stages: discovery call completed, technical evaluation started, proposal delivered, procurement engaged, contract in legal. Each names an observable event with a yes or no answer.
Apply the test to your current stages right now. Any stage where two reps could reasonably disagree is a stage that needs redefining.
How many stages
Five to seven. Fewer than five loses resolution; more than seven becomes bookkeeping that reps resent and skip.
A workable default:
Exit criteria
Each stage needs written exit criteria: what must be true to advance. This is what turns stages from labels into a process.
Exit criteria also make AI useful. When the system can compare a deal's stage against whether its criteria are actually met, it can flag the deals that advanced on hope. That is one of the highest-value detections in any CRM, and it depends entirely on having written the criteria down.
Important: A deal that skips a stage is a signal, not an error to correct. Investigate before you fix the data: sometimes the process is wrong, and sometimes the deal is not as advanced as the rep believes.
Keeping it honest without policing
Make the next step mandatory. Every open deal needs a defined next action with a date. This single field predicts slippage better than any other, and it is the one most often left empty.
Let the system chase, not the manager. Stalled-deal detection catches inactivity automatically. A manager asking "what's happening with Acme?" is expensive and feels like surveillance; a system flag is neither.
Review the pipeline against evidence, not against the rep's memory. A pipeline meeting where the AI has pre-flagged the mismatches is shorter and less defensive than one where a manager probes deal by deal.
Close lost deals promptly. Pipelines full of zombie deals distort every metric. If nothing has happened in 90 days, it is lost; mark it and learn from it.
What good looks like
Stage distribution roughly matches your historical conversion pattern. Deals move forward or die rather than aging in place. Forecast accuracy within a sensible band. Reps update the pipeline because it tells them what to do, not because a manager asked.
FAQ
Should we use probability percentages?
Use them as historical conversion rates per stage, computed from your own data, rather than as rep-entered confidence. Rep-entered probability is optimism with extra steps.
How often should the pipeline be reviewed?
Weekly at team level, and continuously by detection. The weekly meeting should discuss the exceptions the system flagged, not walk the whole list.
What about deals with long cycles?
Long cycles need more stages, not fewer, and stricter stall thresholds per stage. A six-month cycle with four stages gives you almost no early warning.
Brainis Revenue OS supports multiple pipelines with exit criteria and automatic stall detection, connected to delivery and finance. See Revenue OS.
Sharing insights on business operations, AI, and modern team management.
Run your company on Brainis
All 11 Operating Systems on every plan, from $29 a month. No per-seat pricing — you pay for AI capacity, not headcount.
See pricing