Concord CRM Deal Stages: Designing a Pipeline That Reports

Open the board on a Monday morning and the pipeline looks healthy: 41 open deals, $380,000 of value, a weighted forecast of $164,000 for the quarter. The quarter closes at $71,000. Nobody falsified anything. Every deal was sitting in the stage the rep honestly believed it belonged in, and the number was still wrong by more than half.

That kind of failure is structural, and it starts with how the Concord CRM deal stages were defined in the first place. Most pipelines record what the sales team did - called, demoed, sent a proposal, chased - rather than what the buyer agreed to. A stage you can enter by working harder will always be full, and a percentage bolted onto it forecasts your effort instead of their intent.

The fix is almost never another stage. It is usually seven fewer.

The test every stage has to pass

Before naming anything, write the stage’s exit criterion. One sentence, and it has to survive a single question:

Could somebody who was not on the call verify it from evidence already in the CRM?

Criteria that pass:

• An email in which the buyer names the person who signs off the budget.
• A calendar invite accepted by the people who will actually use the thing.
• A scoping document returned with their corrections on it.
• A purchase order number, or a written request for the contract.

Criteria that fail:

• “Good fit.”
• “High interest.”
• “Champion identified” - unless the champion did something you can point at.
• “Decision maker engaged”, which in practice means somebody senior was copied in.

If you cannot write the sentence, you do not have a stage. You have a feeling with a percentage attached, and the forecast inherits the feeling.

The reason to be strict is not tidiness. Every stage is a place a deal can hide. A rep under pressure rarely invents fake deals; a vague stage simply lets a real one sit in a comfortable middle position for eleven weeks while looking like progress on the board.

Why “send proposal” is not a stage

A stage is a change in the buyer’s position, not a change in yours. “Send proposal” fails on two counts at once. You can enter it unilaterally, by emailing a document to somebody who never asked for one, and you can stay in it indefinitely without anything being true about the deal.

“Waiting on legal” fails differently, and it is worth separating the two failures because the fixes differ. Waiting on legal is not a position on a path - it is a blocking condition that can occur at three different points in the same deal, and it can clear without the deal advancing an inch. Blocking states are orthogonal to progress. Model them as a task with an owner and a due date, or as a field on the deal, and let the stage keep its meaning.

The line worth holding, and it settles most arguments: if your team can move the deal forward without the buyer doing anything, it is not a stage.

How many deal stages should a pipeline have?

Answer this with arithmetic rather than taste, because there is a real statistical floor underneath it.

A stage’s win probability is a proportion estimated from a sample: of all the deals that ever reached this stage and have since closed, what share were won? Ten closed deals behind a stage gives you a proportion with a 95% confidence interval of roughly plus or minus 30 percentage points. Thirty gets you to about plus or minus 18. A hundred gets you to about plus or minus 10. Below roughly 30 outcomes per stage, the percentage in the settings screen is decoration.

So the rule is: closed deals per year, divided by 25, capped at six and floored at four. A team closing 120 deals a year has the evidence for about five stages. A team closing 40 does not really have the evidence for four, which is a genuine limitation worth stating plainly - at that volume, drop weighted forecasting entirely and run commit / best case / omitted judgement calls against maintained close dates instead. That is not a downgrade. It is the honest instrument for the sample size.

Two diagnostics tell you your pipeline has too many stages, and both are visible today:

1. Skipping. Export stage history and look for deals that jumped from stage two to stage five. If reps routinely skip a stage, that stage does not describe anything real.
2. Pooling. Measure average age in stage. One stage holding deals four times longer than its neighbours is usually two decisions crushed together, or a stage with no defined exit at all.

Five Concord CRM deal stages that hold up

Here is a five-stage structure where every exit criterion is something the buyer did. It is deliberately boring, and very hard for an optimistic rep to argue past.

Stage	The buyer has done this	Starting probability
New	Nothing yet. The deal exists because somebody created it.	5%
Qualified	Named the problem, the budget holder and a timeframe, in a two-way conversation.	15%
Scoped	Confirmed in writing what a good outcome looks like, or given access to the people and data needed to define it.	35%
Priced	Seen the real number and asked you to continue anyway.	55%
Selected	Said you are the choice and named the route to paperwork: a PO number, a contract request, a signature date.	80%

Won and lost are not on that list on purpose. In Concord they are the deal’s status, not a position in the pipeline, which is exactly right: a stage should never carry 0% or 100%, because those are outcomes rather than predictions. Record the reason on the way out so the lost column can answer “why” without you inventing a “Lost - price” stage to hold it.

Treat those percentages as placeholders rather than as your numbers. The next section replaces them.

Setting Concord CRM win probability from evidence

The Concord CRM win probability on each stage is the multiplier behind every weighted forecast you will ever look at, and most installs never touch the defaults. Compute yours from an export and a spreadsheet, once a quarter:

probability(stage) = deals that ever reached this stage and were won
                     ------------------------------------------------
                     all deals that ever reached this stage and closed

Two mistakes are common here. The first is measuring deals currently sitting in a stage rather than every deal that ever passed through it - that systematically overstates the early stages, because the failures have already left. The second is even spacing. A pipeline reading 10 / 30 / 50 / 70 / 90 is a tell that nobody measured anything; real curves stay flat and low for a long time and then jump hard once the buyer commits, which is why the table above goes 5 / 15 / 35 / 55 / 80.

One more thing decides whether the weighted number means anything: the expected close date. A weighted forecast counts only deals expected to close inside the period, so deals three weeks past their close date quietly distort every report they touch. Re-date them or lose them weekly, not at quarter end.

Concord CRM pipeline setup: where the deleted stages go

Collapsing twelve stages into five does not throw away twelve stages’ worth of information. It puts each piece where it can be queried. In a Concord CRM pipeline setup, the deleted stages land like this:

• Internal work (“send proposal”, “book demo”, “follow up”) becomes activities and tasks with an owner and a due date. The deal moves when the buyer responds, not when you hit send.
• Blocking states (“waiting on legal”, “on hold until Q3”) become a field or a tag, plus a dated next step. A deal can be blocked at any stage.
• Deal shape (product line, region, inbound versus outbound) becomes custom fields. Never a stage - segmentation is a filter, not a position.
• Different sales motions (new business, renewal, partner-sourced) become separate pipelines. Concord supports more than one, and two clean five-stage pipelines report far better than one eleven-stage compromise where half the stages are irrelevant to half the deals.
• Exit reasons go on the lost reason, so you get the analysis without a stage that only ever holds dead deals.

You lose one thing in this trade, and it is worth naming: a five-stage pipeline tells you less about precisely where a rep is stuck. You get that back from activity history and next-step dates, which is where it belonged anyway. Coaching detail and forecast structure are different jobs, and forcing the pipeline to do both is what produced the twelve stages in the first place.

Rebuilding without wrecking the history

Do not rename stages in place. Renaming rewrites the meaning of every historical record silently, and next quarter’s comparison against last quarter becomes meaningless with nothing on screen to warn you. Build alongside instead:

1. Export every open deal with its stage, amount, expected close date and owner. This is your rollback.
2. Compute the current per-stage win rate before you change anything. Without the baseline you cannot tell whether the new pipeline forecasts better or merely differently.
3. Write the five exit criteria. Name the stages afterwards, from the criteria.
4. Create the new pipeline as a new pipeline. Leave the old one intact.
5. Move open deals across by evidence, asking only “what has the buyer actually done”. Expect most deals to land one or two stages earlier than they sat before. That drop is the real state of the pipeline, not a loss.
6. Fix expected close dates in the same pass, while you have every deal open anyway.
7. Stop creating deals in the old pipeline and let the remainder drain. Accept that deals moved between pipelines break stage-history continuity, which is why you exported in step one.
8. Review after one full sales cycle. Any stage that never held a deal longer than a day gets deleted.

Step two is the one people skip, and it is the only step that expires. Pull that baseline win rate today, before anybody touches a stage name, because once the pipeline changes you can never calculate it again.