Your Pipeline Stages Are Wrong. Here's the Two-Minute Test.
My first day at a new job was in a hotel conference room in Denver.
The company was an early-stage startup based in Arizona. We were small and fully remote, so instead of an office there was a rented room in a city roughly equidistant from everyone, a folding table, and not enough outlets.
Within a few minutes, the CEO was grilling me. Not about my quota history. Not about my book of business. About deal stages. What were the stages in the pipeline at my last company? Why those ones? What actually moved a deal from one to the next?
I was intimidated. I was also, a little to my surprise, excited — because I had answers, and I could feel in real time that those answers were going to shape the next two years of my job. They did. That conversation runs in a fairly straight line to what I do now, which is Sales and RevOps consulting on HubSpot full time.
Here's what I took from that room. Deal stages are not an admin task. They're the shape of how your company sells, encoded in software. And the person designing them needs to have carried a bag. You can't derive a good pipeline from best-practice articles. You derive it from having lost deals and knowing exactly where they died.
The test
Open your pipeline. Go stage by stage. For each one, answer a single question out loud:
What does a rep do to move a deal out of this stage?
The answer has to be an action your rep takes. Not something the customer does. Not something that happens. A verb the rep controls.
If you can't answer for a stage, that stage isn't a stage.
That's most of the test, and on a normal pipeline it takes about ninety seconds. Spend the last thirty on three follow-ups:
The skip check. Pull the funnel report. Is any stage being skipped by roughly half your deals?
The sub-status check. Are reps tracking where a deal really is somewhere other than the stage — in a note, a custom property, a nickname in the deal name?
The outsider check. Would someone in Customer Success read each stage name and understand the same thing your reps do?
Everything below is what those four questions surface.
Stages that are really statuses
This is the one the main question catches immediately, and it's the most common thing I fix.
You'll see a pipeline that runs Contract Sent → Contract Signed → Closed Won. Ask the question at Contract Signed: what does the rep do to move the deal out of it?
Nothing. The customer signs. And the moment they sign, the deal is won.
Contract Signed isn't a stage, it's the outcome of the previous one. If the contract gets signed, the deal goes to Closed Won. If it doesn't, it goes to Closed Lost. Adding a stage in between doesn't give you more visibility — it gives you a place for deals to sit looking alive when they're already resolved, and it corrupts every cycle-time report you run.
The tell is always the same: the rep's only job in that stage is to wait.
Names only your reps understand
Stage names are read by more people than you think. Reps live in them. Leadership forecasts off them. Customer Success reads them to figure out what's coming. Finance may be looking at them too.
So the name has to survive being read by someone who wasn't in the meeting where you named it.
"Quote Sent" works. It says what happened, who did it, and what state the deal is in. "Waiting on Signature" is worse — waiting on whom, from what, sent when? It describes a mood more than a milestone
Name for the action that just completed, not for the feeling of what comes next.
On numbering. Some teams prefix stages with numbers: 1. Discovery, 2. Demo, 3. Quote Sent. The argument for it is reporting — anywhere your stages get sorted alphabetically instead of by pipeline order, numbering makes them fall in the right sequence without manual reordering. That comes up more than you'd expect once you're exporting data or building views outside HubSpot.
The argument against is that some people find it ugly on a board. That's a legitimate objection and I'm not going to talk you out of it. Just know you're choosing slightly more work later.
Too many stages
This is the most common failure I see, and the reason is structural: creating a deal stage is trivially easy. So people get ambitious.
Less is more. You want the fewest stages that still leave reps in no doubt about where a deal belongs. Every stage past that point is a tax you pay on every deal, forever.
The skip check is how you find the excess. If half your deals never touch a stage, one of two things is true: the stage doesn't reflect how you actually sell and should go, or it does reflect how you should sell and reps are routing around it. The second case isn't a naming problem — that's where required properties and workflows earn their keep, so the stage can't be skipped without the information you need.
Don't fix a skipped stage by deleting it reflexively. Find out which of the two you're looking at first.
Too few stages
Rarer, but it happens.
The signal is stages inside stages. If reps have invented their own sub-statuses to track where a deal really is — a property, a note, a convention in the deal name — the pipeline isn't granular enough, and they've built a shadow version of it to compensate.
Demo is the usual culprit. Plenty of teams run an initial demo and then a second, deeper one with a Sales Engineer. Those are different motions, with different owners, different failure modes, and different conversion rates. Collapsing them into one stage means you can't see which of the two is killing your deals.
If your reps are tracking something you're not, that's your missing stage.
What stages should trigger
Once the stages are right, they become the backbone for everything else. Three things worth thinking through:
Approvals. Should a Sales Manager or Director sign off on a quote before it goes to the prospect? If yes, that belongs in the pipeline as a defined step rather than a Slack message someone hopes gets seen.
Internal notifications. Slack, email, and in-app are all available. The question isn't whether you can send them — it's which stage change is actually worth interrupting someone for. Notify on everything and people mute the channel, which is worse than never having built it.
The Customer Success handoff. Is there information CS should have before a deal closes? Almost always yes, and almost always they get it after, which is why onboarding starts with a scramble. Pick the stage where CS should be reading the deal, and build for that stage — not for Closed Won.
The point
None of this is exotic. It's the kind of thing that's obvious once someone who has actually sold sits down and asks the right question about each stage.
That's what the CEO was doing to me in that hotel conference room, and it's most of what I do now. If your pipeline hasn't been through this in a while, run the test yourself — it genuinely takes two minutes, and you'll know within the first three stages whether you have a problem.
KoiShark Consulting is a certified HubSpot Solutions Partner. We audit, rebuild, and train teams on HubSpot in English and Spanish, for startups and midsize companies across the US, Canada, and Latin America. If you want a second opinion on your pipeline, book a free 15-minute call or email contact@koishark.com.
