How to Define Sales Pipeline Stages That Mean Something
Define pipeline stages by what the buyer has done, with a checkable exit criterion for each, so CRM data and sales forecasts mean something.
To define sales pipeline stages that mean something, name each stage after something the buyer has done, and give every stage an exit criterion: a checkable fact that must be true before a deal can move to the next one. "Proposal sent" describes your activity. "Buyer has confirmed the scope in writing" describes theirs, and only the second tells you whether the deal is actually closer to closing.
That one change is what makes CRM deal stages worth reading. When stages are tied to buyer actions, two people looking at the same deal put it in the same place, stage counts mean the same thing every week, and a forecast built on them stops being a guess with decimals.
Why most sales pipeline stages produce bad data
The usual stage list comes from a template or a CRM's default settings: Lead, Contacted, Proposal, Negotiation, Won. Almost every one of those records something the salesperson did. You contacted them. You sent a proposal. None of it says anything about whether the buyer moved.
A rep can send a proposal to someone who never opens it, and the deal jumps a stage. The board looks healthy, the forecast goes up, and nothing about the buyer's intent has changed. Multiply that across a team and the pipeline becomes a record of effort rather than progress.
The second problem is vagueness. "Qualified" means five different things to five people. One rep qualifies a lead after a good first meeting, another waits until budget is confirmed. Both are using the same stage, so the stage tells a manager nothing. We covered how this feeds into failed rollouts in why CRM implementations get abandoned; this post is about fixing the stages themselves.
What does a buyer-action stage look like?
Here is a stage set for a business selling services or software to other businesses. Yours will differ, but the shape is what matters: each stage names what the buyer did, and each has a test for leaving it.
1. Enquiry received
The buyer has contacted you, replied to outreach, or filled in a form. Exit when you know who they are, what they asked for, and which person on your side owns the next step.
2. Problem confirmed
The buyer has described the problem in their own words in a conversation. Exit when the problem, the rough timing and the person who makes the final decision are recorded on the deal.
3. Qualified
The buyer has shared a budget range or their buying process and agreed to look at a solution. Exit when there is a named decision-maker and a next meeting on the calendar, with a date.
4. Scope agreed
The buyer has confirmed in writing what they want priced. Exit when your written summary of the scope has come back with a yes or with corrections you have accepted.
5. Proposal under review
The buyer has received the proposal and acknowledged it, and a review conversation is booked. A proposal sitting in an inbox with no reply stays in stage 4.
6. Committed
The buyer has said yes in principle and started their own internal steps: purchase order, legal review, board sign-off. Exit when the contract or order is signed.
7. Won or lost
Closed either way, with a reason recorded for every lost deal. Lost reasons are the cheapest market research you will ever get, provided they are picked from a short fixed list rather than typed freely.
How to write an exit criterion
An exit criterion is the rule for leaving a stage. Good pipeline exit criteria share four properties.
- It is binary. The fact is either true or not. "Buyer seems keen" fails. "Buyer has booked a demo for their finance lead" passes.
- It is visible in the system. The evidence lives on the record as a filled field, a logged meeting or an attached document. If proving it means asking the rep, it is not a criterion.
- It depends on the buyer. At least one condition in each stage should be something only the buyer can make true.
- Two people would agree on it. Give a manager and a rep the same deal record. If they would place it in different stages, the wording needs work.
A useful check: could someone who has never spoken to the customer look at the record and confirm the stage without asking anyone? If yes, the criterion is doing its job.
Where do stalled and awkward deals go?
Every team eventually asks for a stage called "On hold" or "Waiting on client". Resist it. A deal can be waiting at any stage, so waiting is a condition of the deal rather than a step in it. A separate "waiting" stage hides where the deal really is.
Instead, keep the deal in its true stage and make two fields mandatory: the next step and the date of that next step. A deal blocked by the buyer's budget cycle stays in "Committed" with a next step dated for when the budget opens. That is honest, and it shows up in any report of deals with old or missing next steps.
Deals that are genuinely dead should be closed as lost with a reason. Keeping them open because closing them feels like admitting defeat is one of the main ways a pipeline gets inflated.
How many stages should a sales pipeline have?
As many as there are points where the next action changes, and no more. If two stages lead to the same next action from the rep, merge them. If one stage covers two very different situations, such as a buyer who has never seen pricing and one who is comparing your quote with a competitor's, split it.
For most small teams that lands somewhere between five and seven open stages. Fewer and the pipeline cannot show where deals get stuck. More and people start guessing between neighbouring stages, which brings back the vagueness you were trying to remove.
Should each stage have a win probability?
Most CRMs let you attach a percentage to each stage and multiply it by deal value to produce a weighted forecast. The default percentages are made up. They were not calculated from your deals, and using them produces a precise-looking number with no basis, which does nothing for sales forecast accuracy.
Until you have enough closed deals to calculate your own figures, leave probabilities out and forecast from the later stages only: deals in "Committed" and "Proposal under review" with a realistic close date. Once you have a decent history, work out what share of deals that reached each stage went on to close, and use those numbers. Recalculate them every quarter, because they drift as your market and your team change.
Watch stage age as well. A deal that has sat in one stage far longer than your typical deal is a weaker deal, whatever its stage label says. A simple report of deals older than usual for their stage often tells a manager more than the weighted forecast does.
How to roll new stages out
Before changing anything in the CRM, take a batch of recent deals, won and lost, and walk each one through the new stages on paper. Ask where it would have sat each week and whether the exit criteria would have caught the moment it stalled. Deals that do not fit any stage point to a missing or badly worded one.
Then write the definitions where people will see them. Most CRMs allow a description on each stage or a required field when a deal moves. Definitions kept in a separate document get read once.
Move the existing open deals into the new stages in a single sitting with the reps who own them. It is slow, and it is the first real test of the definitions, because every disagreement about where a deal belongs is a sentence that needs rewriting.
After that, review the stages monthly for the first quarter. The signal to watch is disagreement. If people keep arguing about where a deal belongs, rewrite the definition until the arguments stop.
The short version
- Name each stage after something the buyer has done.
- Give every stage a binary exit criterion visible on the record.
- No "waiting" stages. Use a dated next step instead.
- Close dead deals as lost, with a reason from a fixed list.
- Keep stages to the points where the rep's next action changes.
- Ignore default win probabilities until your own history can replace them.
- Test the stages against real past deals before switching over.
Yoddha Lab builds LeadHeed CRM for small sales teams that want a pipeline with clear stages and dated next steps, and Kudos CRM, an AI CRM for agencies and professional-service firms that need the deal, quote, project and invoice on one customer record. If the stages are hard to define because the sales process itself is unclear, that is a job for business process reengineering before any software.
Frequently Asked Questions
How should you define sales pipeline stages?
Name each stage after something the buyer has done, not something the salesperson did, and give every stage an exit criterion: a checkable fact that must be true before a deal moves on. For example, 'Buyer has confirmed the scope in writing' is a buyer action, while 'Proposal sent' only records your activity.
What makes a good pipeline exit criterion?
A good exit criterion is binary, so it is either true or not; visible on the CRM record as a field, logged meeting or attached document; dependent on at least one thing only the buyer can make true; and clear enough that a manager and a rep would place the same deal in the same stage.
How many stages should a sales pipeline have?
A sales pipeline should have as many stages as there are points where the rep's next action changes, and no more. For most small teams that is between five and seven open stages. Fewer cannot show where deals get stuck; more makes people guess between neighbouring stages.
