Opportunity stages that mean something in a forecast

Ask a sales team what Stage 3 means and the answer is almost always a description of something the seller did. The demo has been delivered. The proposal has gone out. The quote is with the customer. Every one of those sentences has the rep as its subject, and that is the reason the forecast does not work.

A stage defined on seller activity moves when a rep decides to move it. The pipeline then records intention rather than progress, and it produces the pattern every revenue leader recognises: a deal holds the same stage for eleven weeks, gets discussed politely in three consecutive reviews, and closes lost in a single afternoon having never once appeared at risk.

#A stage is a claim about the buyer

The repair is a change of subject. In a stage definition worth having, the buyer is the one doing something.

Proposal sent records postage. It is true, it is timestamped, and it predicts nothing, because a proposal can be sent to somebody with no budget, no authority and no intention of opening it. Buyer confirmed in writing who signs and what they need to see before signing is a different class of statement. It is equally verifiable, and it is verifiable by somebody other than the rep, which is the property that matters.

The test we use in stage workshops is blunt. Read the exit criterion aloud and ask whether the buyer, if shown it, would agree that it had happened. They are interested fails immediately, because interest is a reading of a room rather than an event. Proposal sent passes the test and still predicts nothing. Budget holder named, timeline stated and evaluation process described passes and does predict something, because a buyer who has explained their approval steps has spent effort on your deal, and effort is the only currency a buyer has to spend before they spend money.

Evidence, here, means something the buyer said, wrote, gave or signed. An email. A recorded answer on a call the whole team can hear. An introduction to a colleague. A completed security questionnaire. A date they put in their own diary. It does not mean a rep's summary of a conversation, however honest that rep is, because a summary is precisely the thing that softens when a quarter gets tight.

#Exit criteria, written as evidence

A stage model is not the list of stage names. It is the list of exit criteria, and most organisations have the first without the second. The names sit in a picklist that every rep sees every day, and the criteria sit in a slide from an enablement session two years ago that nobody has opened since. The gap between those two artefacts is where the forecast leaks.

Written properly, an exit criterion has three parts: what the buyer must have done, how you would know, and what the record must contain as a result. The middle part is the one teams skip, and it is the one that stops the criterion decaying into a slogan.

Read the third column first. Every entry in it describes a deal sitting at the correct stage on paper while carrying none of the evidence that stage is supposed to represent. Nothing in the platform can separate those from the real ones, because both look identical in a pipeline report: same stage, same amount, same close date, same confident row in a summary.

The first row deserves particular attention, because the quality of everything downstream is set by what is allowed to become an opportunity at all. If leads convert on the strength of a form fill and a phone call that got answered, the top of the pipeline fills with records that have no buyer evidence behind them and never will. That handover is a design problem in its own right, and we set out how to draw the line in lead management that survives the handover.

#Probability percentages are usually decorative

Almost every stage model ships with a percentage attached, and almost none of them survives contact with an experienced rep.

The problem is what the number claims. A fixed probability on a stage asserts that deals in this state close at this rate, which is a statement about a distribution somebody would have had to examine. In most orgs nobody has. The figures came from the implementation partner, or from the previous CRM, or from a workshop where the room settled on values that felt about right and then never revisited them through two product changes, a change of market and a change of sales leadership.

What follows is predictable. Managers do not believe the weighted pipeline, so they build a second forecast in a spreadsheet. Reps who can edit the probability field turn it into a mood ring, nudging it up before a review and quietly down afterwards. The organisation ends up with a number that is arithmetically precise, evidentially empty, and printed on every summary as though it meant something.

Two positions are defensible. The first is to take the field off the layout and forecast on judgement categories instead, keeping commit, best case and pipeline as explicit human calls that a named person owns and can be held to. The second is to keep a percentage, derive it from your own closed history, review it on a schedule, and make it read only for everyone. Salesforce's own forecasting guidance treats the category call and the stage as separate instruments, and that separation is the useful part: stage says where the deal is, category says what a human is prepared to promise, and collapsing one into the other loses both.

#The close date is where the forecast actually breaks

Stage tells you where a deal is. Close date tells you when it lands, and it is the most edited and least examined field on the object.

Two failures are common and they have opposite shapes. In the first, the close date is set at creation, when the rep cannot possibly know it, so they enter the end of the current quarter and that guess becomes a data point indistinguishable from a date negotiated with a customer. In the second, the date is maintained honestly at first and then stops moving, because moving it has become expensive: it triggers an alert, a conversation, or a reputation for running deals that slip.

The second failure is the one worth designing against, because it destroys information rather than merely inventing it. A rep who pushes a date is telling you something early and for free. Punish that and they will hold the date until the final week of the quarter and then move it once, at the exact moment the news is least useful to anybody.

So make slippage visible instead of punished. Capture the first defensible close date in its own field, set at the stage where the buyer has actually said something about timing. Count date changes and total days of movement. Report the pattern at the level of the segment, the stage and the sales cycle rather than at the level of the individual, and use it to ask why a category of deal keeps taking longer than the model assumes. Slippage that is measured is a property of the market. Slippage that is punished is a property of your reporting, and it will be hidden from you inside a quarter.

#Fewer stages with hard criteria

Arguments about stage count usually run on taste. There is a better test.

The right number of stages is the number of times the buyer does something that materially changes the odds. Not the number of things the sales team does, which is much larger, and not the number of things management would like reported, which is larger still. Every additional stage costs a definition to maintain, a training moment to repeat, a boundary for two people to disagree about, and one more place for a deal to sit quietly while nothing happens.

The disagreement test settles most of it. Put the same three live deals in front of two experienced reps and ask each of them to place the deals. Where they agree, the boundary is real. Where they split, the boundary is a judgement call dressed as a data point, and every report built on it inherits that vagueness without ever disclosing it.

This is why four hard stages outperform nine soft ones. The nine feel more precise and are less accurate, because precision resting on unshared definitions is a presentation effect. Where a team genuinely needs finer detail, track it as fields on the opportunity: whether security review has started, whether the business case has been presented, whether a mutual action plan exists. Those are reportable and filterable, and they do not force a single linear ordering onto a buying process that rarely runs in one.

#Deals that skip stages are telling you something

Sooner or later somebody proposes a validation rule to prevent skipping. It is worth resisting, for the reason we set out in Sales Cloud automation that reps do not work around: a rule a rep cannot satisfy honestly does not produce compliance, it produces a plausible value that clears the rule and then gets reported as fact.

Skipping is data. Read it before you block it.

Some skips are legitimate. An existing customer expanding a licence they already own has done half the buying process before the opportunity existed. An inbound deal that arrives with budget approved and a deadline attached is not skipping stages, it entered further along than your model assumes. Others are less legitimate, and they cluster in the last fortnight of a quarter, where a deal jumps three stages in two days because somebody is back-filling a record to match an outcome that has already happened.

Both are visible in stage history, which Sales Cloud records for you whether or not anybody looks at it. Report on opportunities whose history shows a jump, then check how they closed. If skipped deals win at a rate comparable to the ones that walked through every gate, you have found a stage that is not carrying its weight, and the honest response is to remove it rather than to enforce it harder.

#Changing the model in a live org

The most damaging way to change a stage model is the one that looks tidiest: renaming picklist values in place.

Renaming rewrites history. Every closed opportunity from the last four years now displays the new label, every trend report aggregates old records under a definition they were never assessed against, and nothing in the org announces that the meaning changed in March. A year later somebody presents a conversion chart across the seam, and the chart is wrong in a way that is invisible and almost impossible to argue with.

The safer sequence has four parts. Add the new values rather than editing the old ones, so historical labels stay attached to the records that earned them. Write a mapping table, put the cutover date on it, and keep it somewhere a report author will actually find it. Snapshot the pre-cutover funnel metrics before you touch anything, because those numbers become unreproducible the moment the model changes. Then rebaseline conversion and cycle time once a full sales cycle has run through the new model, and refuse to compare across the seam without saying out loud that a seam is there.

Two rules carry most of the risk. Never reuse a stage name for a different meaning, because that is the one change no reader can detect. And never run the cutover mid-period, because a quarter split across two definitions cannot be reported honestly under either.

#Make the criteria useful to the rep, not just to the report

There is a version of all this that fails, and it fails for the reason most process work fails: the criteria get written for the report and handed to the rep as an obligation.

Buyer-verifiable criteria have an unusual property that makes the alternative available. Because each one names something the buyer must do, each one is also a next step. Confirm in writing who signs and what they need to see is not paperwork, it is the call the rep should be making anyway, and a good rep already knows it. Written as a stage gate, it stops being an administrative tax and becomes a checklist of the things that actually move a deal, which is the only framing under which it gets used voluntarily. The wider adoption question, and what it takes for a sales team to work inside Sales Cloud rather than around it, is one we cover in why Sales Cloud adoption stalls.

The forecast benefit follows from the rep benefit and not the other way round. A pipeline where every stage is backed by something the buyer did is a pipeline where a review can ask what evidence moved this deal and get an answer, instead of asking how confident are we and receiving a number.