Why this matters
A pipeline stage is a claim about a deal. When a rep moves a deal to Proposal, the stage says the buyer has seen a scope and a price. When the stage has no exit criteria, that claim means whatever the rep needs it to mean that week. This guide on how to design CRM pipeline stages with exit criteria is about making each claim checkable.
Exit criteria are the conditions a deal must meet before it enters the next stage. Good ones are observable: a signed NDA, a booked technical call, a budget range confirmed by the buyer. Bad ones are internal feelings: interested, engaged, warm. The difference shows up in the forecast.
Fuzzy stages cause three concrete failures. Deals sit in late stages for months because nobody agreed on what late means. Handoffs break because delivery learns about a project only after a kickoff date was promised. And the forecast swings every time you ask for it, because each rep counts differently.
Good exit criteria also protect reps. When a deal stalls, the criteria tell the rep which question to ask next, and the manager which deal to coach.
Before you start
Start with evidence from your own deals, not from a template. Pull the last twenty to thirty closed deals, won and lost, and read the notes and emails in order. Write down what the buyer actually did before each step: the call that changed the scope, the introduction to the budget holder, the security review.
Name one owner for the design. Usually that is the sales lead, with a delivery manager and a finance contact joining for the handoff stage. Design by committee produces twelve stages. One owner with reviewers produces six.
Check what your CRM can enforce today. Most systems let you make a field required at a stage, block a stage jump, and keep stage history. Know which of those exist before you promise rules you cannot enforce.
Decide the record model too. Deals need an amount, a close date, an owner, a source and a next step date. If your spreadsheet has three columns for the same thing, resolve that now, because stages built on messy data get questioned in week two.
How to do it
Work from the buyer's side of the table. A stage changes when the buyer does something, not when your team sends something. Sending a proposal is an activity. The deal moves when the buyer confirms receipt and agrees to review it with a named decision maker.
Write the criteria in a shared document first, one line per stage, then configure. Keep each criterion to something a second person could verify by opening the record or the email thread. If a line needs a judgment call, it needs a field or a note.
- Map the real buying journey. Interview two or three reps and one delivery lead about the last ten deals. List the moments where the deal actually changed, in the buyer's words. Group those moments into four to seven buckets.
- Write exit criteria as evidence. For each bucket, write two or three conditions that must be true before a deal leaves it. Prefer artifacts and confirmations: named contact, written scope, agreed budget, signed order. Test each line by asking whether a skeptical manager could check it in under a minute.
- Set the stage count and names. Use five to seven stages for most business to business sales, plus closed won and closed lost. Pick one naming style so the list reads as a sequence, for example Qualify, Discover, Propose, Negotiate, Commit. Cut any two stages that mean nearly the same thing.
- Attach required fields to each stage. Decide which fields must be filled before a deal can enter each stage: amount, close date, decision maker, next step date, competitor. Make them required in the stage rules so the form enforces the criteria instead of a memo doing it.
- Define the handoff stage. Add a stage or checklist covering what delivery or finance needs: signed contract, scope document, billing contact, kickoff date. Name the person who confirms it. Handoffs are where most CRM designs quietly fail.
- Configure the rules in the CRM. Turn on stage validation, block stage jumps without a reason, and keep stage history. Add an override field so a manager can record why a jump was allowed. Test with two sample deals before you touch live records.
- Add stale deal rules. Create a rule that flags a deal with no activity or no next step date after a set number of days. Show the flag on the pipeline view. Stale deals are the cheapest signal you get.
- Pilot with a small group. Run the new stages with two or three reps for two or three weeks. Compare what they actually did with what the criteria assumed. Fix wording in this pass, not the overall design.
- Train, publish and freeze. Hold a short session with the whole team and publish the criteria as a one page document. Agree a review date and freeze changes for at least a quarter so the reports have something to compare.
How to check it worked
After four to six weeks, look at time in stage for each stage. If one stage holds most deals for a long stretch, either the exit criteria are too hard to meet or the work before it is missing.
Sample ten open deals above the first two stages. Check whether the required fields hold real values and whether the exit criteria show up in the notes. Fields filled with 1 or a date in the past, followed by a stage jump, tell you the rules are not enforced.
Compare your commit forecast with what actually closed. If the gap narrows, the late stages are doing their job. Ask each rep one question: which stage do you argue about most? That answer points to the next fix.
Watch the handoff. Count how many deals reached delivery with a complete handoff checklist. Missing items show up as invoicing delays and confused kickoffs, not as CRM complaints, so ask finance and delivery directly.
Mistakes to avoid
Too many stages. Every extra stage adds a decision and a place for deals to hide. If two stages always hold the same deals, merge them.
Criteria that a single click can satisfy. A required field filled with 1, or a close date already in the past, is worse than no field because it looks like data. Pair each required field with a short note and spot check it.
Copying the vendor's default stages. Defaults describe a generic sale, not yours. Avoid changing stage definitions every quarter as well, because reports need a stable definition to mean anything.
Leaving old deals in the new pipeline. Archive or close anything older than your normal sales cycle before you switch, or the stage reports will be wrong from day one. If you would rather have someone build it, options run from a freelance admin to a full implementation, and the Cloudverg Sales CRM implementation package is one fixed price option at $9,500 that includes stages and exit criteria, quoting, follow up and the delivery handoff.
Frequently asked questions
What are exit criteria in a CRM pipeline?
Exit criteria are the conditions a deal must meet before it moves to the next stage. They describe evidence, such as a confirmed decision maker or a written scope, rather than a rep's opinion. Each stage has its own set, and together they define what the stage means.
How many stages should a sales pipeline have?
Most business to business sales fit in five to seven stages plus closed won and closed lost. Fewer stages blur the forecast, and more stages slow reps down and create places for deals to sit. Count the distinct buyer commitments in your process, then set the number.
How do I stop reps from skipping stages?
Make the CRM enforce it: block jumps, require the fields, and log an override reason when a manager allows one. Review the overrides weekly for the first month. Rules that nobody checks stop working within a quarter.