Generally, when a revenue leader asks us to fix the forecast, the forecast is not the problem. The pipeline stages underneath it have stopped meaning the same thing to the reps moving deals through them. Discovery is one rep's first call and another rep's signed mutual action plan. Closed Won is contract-signed in one team and kickoff-scheduled in the other. The conversion math is correct and operationally useless, the numbers add up against definitions nobody shares.
Why this matters now
Checkpoint GTM treats stage definitions as the prerequisite for any AI in the funnel. Harvard Business Review (Sinha, Shastri, Lorimer, Mantrala, September 2025) found the teams growing alongside AI use it as a coaching and orchestration layer on an already-clean process. Loose definitions just let agentic tooling automate the drift faster.
The pressure on stage definitions has gotten worse, not better, since AI started showing up inside the funnel. The Sinha, Shastri, Lorimer, and Mantrala September Harvard Business Review piece on sales teams growing alongside AI made the point that the teams pulling ahead are the ones treating AI as a coaching and orchestration layer on top of an already-clean sales process, not as a substitute for one. That is the asymmetry. If your stage definitions are tight, agentic tooling accelerates a system that already works. If they are loose, the AI cheerfully automates the drift, routing deals on a stage signal that already means three different things.
Why does "Closed Won" mean three different things to three reps?
In the instances Checkpoint GTM inherits, a single stage like proposal-sent routinely carries four distinct operational realities across reps: pricing sent; sent and acknowledged; sent plus procurement engaged; sent plus a verbal champion yes. One stage value, four meanings, and a forecast model that treats them as equivalent. It is a definition problem, not rep discipline.
Run a small test on your own instance. Pull the last few dozen deals that moved from a stage like proposal-sent to a stage like negotiation, and ask each rep what the stage transition meant. You will get answers like: pricing was sent; pricing was sent and acknowledged; pricing was sent, acknowledged, and procurement is engaged; pricing was sent and the champion verbally said yes. Four operational realities, one stage value, one forecast model that treats them as equivalent.
This is not a rep discipline problem. It is a definition problem. Reps are doing what people always do when a system gives them ambiguous inputs: they fill the ambiguity with their own working definition, and then the team optimises around the gap. That's why pipeline reviews end up feeling like depositions. The manager isn't actually reviewing the deal; they are reverse-engineering what the rep meant by the stage.
What should each pipeline stage actually mean?
Checkpoint GTM gives every pipeline stage exactly four lines on one shared page: a one-sentence definition, verifiable entry criteria, different exit criteria, and a named owner. Anything Checkpoint GTM cannot define in one sentence is two stages; anything where entry and exit criteria match is a flag, not a stage.
The fix is small and unglamorous. Every stage in the pipeline gets four lines on a single shared page:
- One-sentence definition. What this stage is, in language a new rep could read on day three and immediately apply. If you cannot write it in one sentence, the stage is doing two jobs and needs to be split.
- Entry criteria. The specific, verifiable thing that has to be true on the deal record for the stage to be entered. "Champion has confirmed budget exists this fiscal year, captured in the Budget Confirmed property."
- Exit criteria. The specific, verifiable thing that has to be true for the deal to leave the stage in the forward direction. Different from entry, that is the point.
- Owner. The role accountable for the transition. Sometimes the AE; sometimes the SE; sometimes the deal desk. Naming the owner is what makes the stage a process step instead of a label.
This is the whole template. It fits on one page. The cost is not in the writing. The cost is in the disagreement that surfaces while you are writing it: which is why the template only works as a workshop, not a doc handed to one person to draft alone.
Walking it on a deal: what happens at each stage edge
So for example: a B2B SaaS team I worked with recently had a six-stage pipeline. The middle stage, call it the evaluation stage, had no entry criteria and an exit criteria that matched the entry criteria of the next stage almost word for word. Functionally, the stage was a parking lot. Deals lived there for a median of about three weeks longer than every other stage, and the team had quietly accepted this as how the middle of the pipeline worked. When we ran the rewrite workshop, two things happened in the first 20 minutes. The AEs realised they were using that stage to mean the deal stalled and they did not want to lose it from forecast. The CRO realised the stage existed because somebody five years ago wanted a place to track POCs and nobody had revisited it since. The decision was straightforward once both things were on the same page, split it. POCs got their own stage with its own entry and exit; the parking-lot version of the middle stage got deleted.
That's why the workshop matters. The artefact at the end is the one-pager. The work is the surfacing.
Stages you can't define
Some stages survive the rewrite cleanly. Some don't. The pattern, after running this on enough HubSpot instances to lose count: about a third of stages need definition tightening but stay; about a third need to be split into two stages because they are doing two different operational jobs; the rest get merged or deleted. If you can't write a one-sentence definition in the room, the stage is not a stage. It is a flag, and it should live as a property on the deal record, not as a pipeline position.
Operational vs. reporting stages
On the one hand, your reps need stages that match what they actually do every day: the action shape, the next call, the artefact required to move forward. On the other hand, your CFO needs stages that aggregate cleanly into a forecast model that holds up at board level. Those two needs are not always the same shape. The way I tend to resolve it: keep the pipeline stages operational (rep-facing, action-shaped, four to six of them) and use a separate forecast category property, commit, most-likely, best-case, pipeline, that the manager owns. The rep moves the deal stage; the manager assigns the forecast category. Different fields, different owners, no fight over what a single column has to mean.
Pattern from the field
Running the rewrite for a DACH Series B SaaS team, Checkpoint GTM collapsed an eight-stage pipeline to five: one stage promoted to a property, one split because POCs and paid pilots are different motions. The rebuilt forecast landed inside ten percent of actual the next quarter, because the inputs finally meant something.
A DACH B2B SaaS team at Series B came to us asking for forecasting help. The CRO's stated problem was that the weighted forecast missed by a significant margin every quarter. The actual problem, surfaced inside the first working session, was that the eight-stage pipeline had three stages with overlapping exit criteria and one stage the SDR team was using as a holding pen for unqualified leads. We ran the rewrite as a two-hour workshop with the AE leads, the SDR lead, the CRO, and the RevOps lead in the room. The output: pipeline collapsed from eight stages to five; one stage promoted to a property; one stage split because POCs and paid pilots were different motions. The forecast model rebuilt against the new architecture landed inside ten percent of actual the next quarter, not because the math got smarter, but because the inputs finally meant something.
Resolution: a playbook for the rewrite
If you are about to run this on your own instance, the order matters:
- Block two hours and put the right people in the room. AE leads, the SDR or BDR lead if your top of funnel is shared, the CRO, and whoever owns RevOps. No spectators. The disagreement is the work.
- Walk the current pipeline stage by stage and read the existing definitions out loud. If there is no written definition, ask each rep in the room to write one in 60 seconds and compare. The deltas are the diagnosis.
- For every stage, fill in the four lines. Definition, entry, exit, owner. If the room cannot agree on a one-sentence definition in three minutes, the stage is doing two jobs. Split it.
- Flag any stage where entry and exit criteria match. That is not a stage; it is a deal property masquerading as one. Promote it to a property and remove it from the pipeline.
- Decide operational vs. reporting now, not later. Pipeline stages stay rep-facing and action-shaped. Forecast category becomes a separate manager-owned field.
- Configure the changes in HubSpot before anyone leaves the room. Stage names, entry/exit criteria captured as required properties or workflow gates, owner assignments. If you defer the configuration, the agreement decays inside a week.
- Re-baseline the forecast against the new architecture. Old conversion rates do not transfer. Run the next two pipeline reviews against the new stages before you trust the model again.
Where Checkpoint comes in
Pipeline stage rewrites are one of the most common working sessions we run inside RevOps engagements at Checkpoint: usually in the first month, almost always before any forecasting or reporting work. If your forecast is missing, your conversion math feels untrustworthy, or your reps are fighting about what a stage means in pipeline review, this is the workshop to run before you spend another quarter modelling on top of definitions that nobody shares.
Noah Charak