Pipeline stages are the most-edited and least-examined piece of CRM customization. They begin as a default list that came with the platform, get renamed to match whatever the last sales leader preferred, and eventually become a set of labels that reps click through without thinking. When stages stop meaning anything, the forecast stops meaning anything too.

What a Stage Is Supposed to Do

A stage answers one question: what has actually happened with this opportunity? Not how the rep feels about it, and not how long it has been open. A good stage describes an observable state of the buyer’s process, something you could verify by looking at the record or asking the customer.

That framing rules out a common flaw: stages named after seller activities, such as “Demo Done” or “Proposal Sent”. Those describe what you did. Buyer-centered stages describe what changed on their side, for example “Problem confirmed”, “Evaluating options” or “Decision process agreed”.

Define Exit Criteria for Every Stage

For each stage, write a short statement of what must be true before a deal can leave it. Keep them concrete:

• Qualified: we know the need, who the decision maker is, and a rough timeframe.
• Solution fit confirmed: the buyer has seen the offering applied to their situation and agrees it addresses the need.
• Commercial discussion: pricing or terms are on the table with someone who can approve.
• Closing: the paperwork is with the right person and a date is set.

Your own criteria will differ by business. The point is that two reps looking at the same deal should reach the same conclusion about its stage. Put the criteria where reps will see them, such as in the field help text, and where the platform supports it, make key criteria fields required at stage change.

Keep the List Short

Teams that add a stage for every nuance end up with a dozen steps and a pipeline view nobody can read. Five to seven active stages plus closed won and closed lost is usually enough for most sales processes, though a long or complex sale may justify more. If two stages are routinely skipped or bundled together, merge them.

Be careful too with “parking” stages like “On hold” or “Nurture”. They collect deals no one wants to close out, and inflate the pipeline. Consider a separate status field or a time-based rule that prompts review of deals sitting untouched.

Probability: Handle with Care

Most CRMs attach a default win probability to each stage and use it for weighted forecasts. Those defaults are guesses. Treat them as a starting point and adjust over time based on your own closed deal history, rather than numbers someone typed in on day one. If you do not have enough history, say so in the forecast instead of presenting false precision.

Compare Poor and Better Stage Design

Aspect	Weak design	Stronger design
Naming	Seller activity (“Demo done”)	Buyer state (“Fit confirmed”)
Entry rule	Rep discretion	Written exit criteria
Count	Many fine-grained steps	A handful of distinct steps
Probability	Default numbers, never reviewed	Adjusted using own history
Stalled deals	Parked indefinitely	Reviewed after an agreed idle period
Documentation	Lives in someone’s head	Visible on the record

One Pipeline or Several?

If your company sells genuinely different things, such as new subscriptions and renewals, or small self-serve deals and large negotiated ones, a single set of stages may fit neither. Separate pipelines are a reasonable answer when the buying process differs, but each new pipeline multiplies reporting work. A good test is whether the exit criteria are materially different. If only the product differs, a field is often better than a new pipeline.

Changing Stages on a Live System

Editing stages in an active CRM can quietly damage your reporting. Before you rename, delete or reorder anything, do the following:

1. Export current deals with their stage values and history, if the platform tracks it.
2. Decide how every old stage maps to a new one, including deals already open.
3. Check which reports, dashboards, automations and integrations reference stage names or values. These are the pieces that break.
4. Make the change outside a busy period and tell the team what changed and why.
5. After the change, rebuild or validate the key reports and confirm totals line up.

Deleting a stage that has history attached can orphan records or force a reassignment, so check your vendor’s current documentation first.

A Hypothetical Example

A small agency uses stages named “Lead”, “Contacted”, “Meeting”, “Proposal”, “Negotiation” and “Won”. Reviewing a few stalled deals, the manager sees that “Meeting” contains everything from a first intro call to a deep scoping session, and “Negotiation” is where reps park anything that has gone quiet. She replaces them with “Needs confirmed”, “Scope agreed” and “Terms in review”, each with a one-line criterion, and adds a rule that prompts an owner to review any open deal with no activity for a set period. Existing deals are mapped by looking at the last note on each. The pipeline becomes shorter on screen and, more importantly, the stage now predicts something.

Frequently Asked Questions

How many stages should a pipeline have? Enough to distinguish genuinely different buyer states and no more. For many teams that is between five and seven open stages, but your sales cycle should decide.

Should reps be allowed to skip stages? Allow it if the buyer genuinely moved faster, but require that the exit criteria are still met. Skipping often indicates stages that can be merged.

Why do deals get stuck in the same stage? Often the exit criteria are unclear, or the next step depends on the buyer and the rep has no way to move it. Review stalled deals together and look for the common blocker.

Can we change stage names without affecting reports? Renaming alone is usually harmless, but reports or automations that filter on a stage’s text value can break. Test after any change.

Do we need different stages for renewals? Often yes, because renewals follow a different path from new business. Consider a separate pipeline only if the criteria are really different.

Next Step

Take your current stage list and write one sentence of exit criteria beside each. Any stage you cannot define in a sentence is the first one to rework.