|
End of the month. Forecast review. You scroll down the open pipeline and half of it sits in “Proposal Sent” or “Negotiation”.
The numbers look fine on paper. But you know — in your gut — that a big chunk of those deals isn’t real.
The reflex is the same everywhere: push harder. Follow up more. Book more meetings. Get the signature.
Some deals close. Most don’t. Next month, the same pile sits in the same place, and the same conversation happens again.
I want to make a case that this isn’t a sales performance problem. It’s a pipeline design problem. And if you fix the design, the performance follows almost on its own.
|
|
|
Stages as labels vs stages as operating rules
|
Most pipelines are built as labels:
- Discovery
- Demo
- Proposal
- Negotiation
- Closed Won / Closed Lost
They look tidy on a board. But labels don’t encode anything about what actually happened.
When a stage is just a label, every person on the team projects their own story onto it.
One AE moves a deal to “Negotiation” after a single positive call. Another waits until legal redlines are flying. A third treats “Proposal Sent” as a parking lot for anything that might close someday.
Same stage. Three completely different realities sitting under it.
That’s how you get:
- Stuck deals that look fine in the forecast.
- Coaching conversations based on anecdotes instead of evidence.
- Last-minute surprises when the pipeline doesn’t convert the way the dashboard said it would.
A pipeline stage isn’t a status. It’s an operating rule. Until you treat it that way, you’re describing the past, not running the future.
|
|
|
The four questions every stage must answer
|
If you want a pipeline you can trust, every stage has to answer four questions.
- Decision. What have we decided about this deal by putting it in this stage?
- Evidence. What verifiable proof do we have that the decision is real?
- Ownership. Who owns it from here?
- Next step. What happens — ideally automatically — when a deal enters or leaves this stage?
If you can’t answer those four for a stage, it’s not a stage. It’s a parking lot.
Take “Discovery”.
As a label, it sounds like: “We had an intro call and it felt good.”
As an operating rule, it sounds like: “We’ve verified pain, budget, and a key stakeholder. We’ve agreed on a specific next step with a specific date. The AE owns the relationship from here; the BDR is no longer in the loop. When a deal lands here, it triggers the discovery checklist and notifies the assigned manager for a first-call review.”
Same word. Completely different operating system underneath.
|
|
|
Where most pipelines quietly leak value
|
When you start writing the four answers for your own stages, two or three patterns show up almost immediately. I see them in nearly every audit I run.
The first is that the decisions are vague. “The customer is interested.” “They asked for a proposal.” Interested in what? A proposal for whom, with what scope? Vague decisions create vague stages, and vague stages can’t be trusted.
A good decision sounds like this: we believe we can win this deal, and the customer has committed to reviewing a specific proposal by a specific date. That sentence is observable. It’s testable. It either holds or it doesn’t.
The second is that the evidence isn’t in the system. Stakeholders are in someone’s head. The mutual action plan is in a Google Doc nobody can find. The last meeting date is “uh, last week, I think”.
The fix isn’t to be stricter with the team. It’s to pick the fields that matter, make them required, and refuse to move a deal until they’re populated. The evidence has to live in the same place the stage lives, or the stage is meaningless.
The third — and this is where most pipelines quietly bleed — is that stage transitions don’t trigger anything. The deal moves. Nothing happens. No task, no notification, no follow-up sequence, no internal review for the bigger ones.
A stage that doesn’t trigger behavior is just a label with extra steps.
|
|
|
What changes when you do this
|
When stages become operating rules, three things shift at once.
Forecasts stop being stories people tell at the end of the month. They become the natural output of decisions that have already been made and verified. The number you see is the number you can defend.
Coaching changes from opinions to mechanics. Instead of “you need to be more aggressive on these deals”, it becomes “this deal is stuck because the evidence for moving out of Discovery is missing — let’s go get it”. That’s a much easier conversation to have. It’s also a much more useful one.
Stuck stages become signals about design issues, not motivation problems. If “Proposal Sent” is bloated, the question isn’t “why isn’t the team pushing harder?” It’s “what’s broken in the operating rule for this stage?” Decision? Evidence? Ownership? Next step?
That’s a question you can actually answer.
|
|
|
One way to run the redesign
|
If you want to try this on your own pipeline, here’s the order I’d run it in:
- For each stage, finish the sentence “when a deal enters this stage, we have decided that…” — and write a decision that’s observable and testable, not a feeling.
- List the minimum evidence required to enter and exit the stage. Map every item to a field or object that already exists in your CRM, or create one. If it can’t live in the system, it doesn’t count.
- Connect each transition to a concrete behavior — a task, a notification, a sequence change, an internal review. If nothing happens when a deal enters or leaves a stage, the stage isn’t doing any work.
|