Direct answer
A stage should describe where the buyer is, not what your rep did. "Sent proposal" is an activity; "buyer has a proposal and is evaluating" is a state. Good stages are few, mutually exclusive, and each has a written exit criterion that a second person could check. If two reps would put the same deal in different stages, the stages are not defined well enough. Start with five to seven stages, write what has to be true to enter and leave each one, and only then decide which fields are required at each step.
Symptoms of a badly designed pipeline
You can usually see a pipeline problem before you can name it. Common signs:
- Most deals pile up in one middle stage that nobody can explain
- Reps skip stages or jump a deal from the start to closed because the stages do not match how deals actually move
- Stage names are internal jargon or task names ("follow-up 2", "waiting") rather than buyer states
- Managers ask reps for updates in meetings because the CRM cannot answer the question
- Forecasts change every week for no visible reason
- The same stage means different things to different people, so nobody trusts a stage-based report
Stage definitions and exit criteria
For each stage write three lines: what the buyer has done or confirmed, what evidence is in the CRM, and what moves the deal forward. Keep the criteria observable. "Buyer is interested" is not observable; "buyer has named a budget owner and a target date" is.
An illustrative structure for a service sale, not a template to copy blindly: new enquiry; qualified (fit and need confirmed); discovery done (requirements captured); proposal delivered; negotiation or decision; won or lost. A shorter cycle may need fewer stages, and a long, multi-stakeholder sale may need one or two more. The number matters less than whether each stage can be defended.
Rules of thumb
Name stages with nouns describing state, not verbs describing effort. Avoid stages that mean "waiting", because waiting is a status, not progress. Do not create a stage for every internal handoff; if the buyer cannot tell the difference, the pipeline probably should not either. And do not put probability numbers on stages until you have enough closed deals of your own to justify them; otherwise you are averaging opinions.
Required fields per stage
A stage without evidence is a label. Tie a small number of required fields to the moment a deal enters a stage, and only fields that change what happens next. Examples of the kind of thing to require: at qualified, the source and the deal owner; at discovery, the buyer's stated need and decision-maker; at proposal, the amount and an expected decision date; at closed-lost, a reason chosen from a short list. Many CRMs can enforce required properties at a stage change, but check how your platform handles this. Keep the list short: every required field is friction and reps will fill it with junk if it is not useful. For which fields deserve to exist at all, see CRM fields for a service business.
Stalled and lost deals
Most pipelines fill with deals that are neither alive nor closed. Decide the rules in advance:
- A stalled threshold per stage: a deal with no logged activity or next step after a set number of days is flagged for review (choose the number from your own sales cycle, not from a blog)
- A visible next-step date on every open deal; a deal without one is treated as at risk
- A closed-lost reason from a short fixed list plus a free-text note, so that you can learn from losses
- A separate nurture route for "not now" so that these deals do not sit in the active pipeline distorting the numbers
- A rule for reopening: who decides, and whether a reopened deal keeps its original creation date
One pipeline or several
Use a separate pipeline only when the buying process is genuinely different: different stages, a different owner team or a different sales cycle length. Do not create a pipeline per product just because the products are different. Extra pipelines multiply reporting effort and make it harder to compare performance. If two offers share the same stages and differ only in what is being sold, keep one pipeline and use a field for the offer type. If a business unit really has its own process, give it its own pipeline and its own owner. Note that many teams underestimate how much routing logic depends on this decision; see route leads between sales teams.
Reporting consequences
Design stages backwards from the questions you want answered. If you want to know where deals die, you need consistent stage entry and reliable lost reasons. If you want conversion between stages, deals must not skip stages and stage changes must be timestamped, which most CRMs do but you should check. If you want a forecast, the stage must mean the same thing to every rep. Changing stage definitions later breaks comparisons with the past, so write down the date of any change and treat earlier reports as a different version of the pipeline.
Migrating existing deals to new stages
Do not remap stage names mechanically. Export open deals, add a column for the new stage, and have the owner of each deal confirm it against the exit criteria, which is quick for a few dozen deals and a good sanity check for the definitions. Closed deals can usually be mapped to won or lost without further review, though you should keep the original stage as a field if you want to preserve history. Run the old and new stages side by side for a short period only if reports need it, and set an end date. For larger moves between platforms see the CRM migration checklist.
Where a fixed-scope setup fits
Redesigning stages, required fields and stalled-deal rules for one principal pipeline is the core of the CRM Cleanup & Sales Workflow Setup entry package, currently €1,990. It covers one CRM, one principal pipeline and up to 10,000 existing records; several pipelines or larger data are scoped separately. Details are on CRM & Sales Workflow Implementation. If you are still choosing a platform, HubSpot vs Pipedrive for small teams covers the structural differences.
Questions
How many pipeline stages should a CRM have?+
There is no correct number. Five to seven is a common starting range for a service sale, but the test is whether each stage has a clear exit criterion and whether two people would classify the same deal the same way.
Should stages have win probabilities?+
Only once you have enough of your own closed deals to base them on. Until then, probabilities are guesses that make forecasts look more precise than they are.
What do we do with deals that have been sitting for months?+
Review them against a stalled rule. Either close them with a lost reason, move them to a nurture list, or confirm a real next step with a date. Leaving them in the pipeline distorts every report.
Can we change stages later without losing history?+
Yes, if you record the change date and keep the original stage in a field or an export. Comparisons across the change will not be like for like, so annotate reports.
Is this included in your CRM setup work?+
Stage design, required fields and stalled-deal handling for one principal pipeline are part of the scoped CRM workflow setup. Multiple pipelines or complex data are custom scope.