How to Design CRM Stages That Reflect the Customer's Journey
How to design CRM stages: the three conditions of a useful stage, how many to have, exit criteria, four tests for your design and reading where deals die.
CRM stages are the skeleton of your sales process. Badly designed stages do not just distort reports; they distort how the team works, because people work to the question the system asks. If your stages ask "what did we do", the team produces activity. If they ask "where has the customer got to", the team produces progress.
What a good CRM stage looks like
A useful stage meets three conditions:
- It reflects customer behaviour: "Proposal sent" is our action; "Proposal under review" is the customer's step. Only the second carries information.
- It is observable: There must be a concrete event proving the stage happened. A stage requiring interpretation gets filled differently by two reps.
- It moves one way: A record that advances does not normally come back. Frequent regressions mean the definition is vague.
How many stages should you have?
Five to seven is the right range for most teams. Fewer is too coarse to see the process; more makes it hard for reps to pick correctly and degrades data quality.
A simple test: if a stage holds less than 5 percent of records, it is unnecessary. If it holds more than 40 percent, it should be split — there are at least two distinct jobs hiding inside it.
Write an exit criterion for every stage
A stage name is not enough; each stage needs a written answer to "what must be true to leave here". An example structure:
- Qualified: Budget range and decision process discussed.
- Need confirmed: The problem to solve is recorded in the customer's own words.
- Solution presented: Technical or operational fit confirmed by the customer.
- Proposal under review: The proposal reached the decision maker and a review date is set.
- Contracting: Commercial terms agreed, in legal or procurement.
Surface these criteria as stage descriptions in the CRM. Do not make the team memorise them.
How to test your stage design
- Distribution test: Look at how open records spread across stages. A pile-up means a blurry definition.
- Duration test: Measure average time in each stage. An unusually long one is really two steps.
- Win rate test: Win rate should rise as stages advance. If it does not, that stage does not represent progress.
- Consistency test: Have two reps independently stage the same five records. Mismatched answers mean the definition is at fault, not the team.
Require minimum fields to advance a stage
This is where stage design meets data quality. Make a few fields mandatory for each transition: budget range at qualification, amount and close date at proposal, decision maker at contracting. Data then accumulates as a natural part of the work rather than an extra chore. The key is restraint — ask for no more than two or three fields per stage, or the team simply stops advancing records.
Where do lost deals sit?
The most valuable output of stage design is showing where you lose. Group all closed-lost records by the stage they died in:
- Concentrated early: A targeting problem. You are talking to the wrong customers, not running a bad process.
- Concentrated in the middle: Weak value articulation. The customer accepts the problem but does not connect your solution to it.
- Concentrated late: Price, competitor or decision-process issues. This is the most expensive category, because these are the deals you invested most in.
The common mistake: mapping your own process
Most CRM setups convert internal approval steps into stages. The result is a list that never shows where the customer actually is. Stages should track the customer's buying journey, not your internal workflow. Use a separate field or task list for internal steps.
Practical tip: review annually
Products change, segments change, stages stay frozen. Run the four tests once a year and update the definitions. When you change them, remap historical data too — otherwise you lose all period-over-period comparison and every historical rate becomes unusable.
Closync makes it easier to fill the fields a stage transition requires by letting reps update records by voice.
