Your deal stages describe you, not the customer
Take a look at your pipeline stages. “Demo held”. “Proposal sent”. “Follow-up in progress”. Notice anything?
Every single one describes what you did. None describes what the customer decided. And that is exactly why your pipeline lies.
“Demo held” is the most treacherous stage of all. It sounds like progress, it feels like progress, the rep did present for an hour and the customer did nod. Except: watching is not commitment. The customer also watched three demos from the competition, and at one of them he is nodding just as politely right now. Yet the deal now sits in your Stage 3 at 40 percent probability, and those 40 percent flow into a forecast your CFO takes seriously.
The pattern runs all the way through. “Proposal sent” measures that someone clicked send. Whether the proposal was ever opened, whether there is a budget for it, whether the person who received it is even allowed to sign: unknown. You are tracking your own activity and calling it a buying process.
The fix is conceptually simple and culturally uncomfortable. Every stage gets tied to a customer commitment, to something the customer did or confirmed. Budget is confirmed, with a number and a name. The economic buyer was in the meeting, not just the friendly project lead. The contract is with the customer’s legal team, not in your drafts folder. A deal only advances when the customer has moved, not when you have moved.
What happens next is ugly at first. The pipeline shrinks, sometimes by a third, because all sorts of deals sat in Stage 4 that by customer logic belong in Stage 1. A CEO once accused me of “you broke my pipeline”. I had not. The pipeline was broken before, it just looked better.
After that it gets interesting. Conversion rates per stage suddenly mean something, because the stages mean something. The forecast calms down. And the reps start asking different questions in their calls, because advancing a stage now requires a customer answer, not a finished to-do. The data model trains the behavior, in both directions.
Technically this is one afternoon of work, define exit criteria, set validations, done. The real question is a different one: do you want a pipeline you like, or one that is true?
