Here is a scenario I run into constantly. A founder calls me because their Q1 forecast was off by $400K. They had 32 deals in the pipeline. Sales was confident. Then the quarter ended and 14 of those deals were still open, 6 had gone quiet, and 4 were officially lost. The forecast was fiction.
When I pull up their HubSpot, the problem is obvious. Their deal stages look like this: "Intro Call," "Demo Scheduled," "Follow-up Sent," "Proposal," "Negotiation," "Closed." Sounds reasonable on paper. In practice, every rep moves deals forward for different reasons, win probabilities are HubSpot defaults (20%, 40%, 60%, 80%), and nobody can tell you what has to be true for a deal to sit at stage four.
This is the most common RevOps problem I fix. It is fixable. But you have to understand what deal stages are actually for before you can set them up right.
What deal stages are actually measuring
Most teams treat deal stages as a tracking tool. Something to show the board, something to organize the pipeline view. That is not what they are.
Deal stages are a forecast instrument. The whole point is to build a model where the stage a deal is in predicts, with some accuracy, the probability it will close. If your stages do not do that, your forecast is a guess dressed up in software.
And here is where most teams go wrong from day one.
The activity vs milestone problem
HubSpot's default stages have names like "Presentation Scheduled" and "Appointment Scheduled." Notice the pattern: they describe activities the rep is performing, not things the buyer has decided.
"Demo Scheduled" tells me the rep sent a calendar invite. It tells me nothing about whether the prospect has a problem worth solving, a budget to spend, or a timeline to buy.
The distinction matters because activity-based stages let reps advance deals unilaterally. The rep sends a demo recording and moves the deal forward. But the buyer has not committed to anything. If the demo went badly or the prospect ghosts you, you have inflated your pipeline with a deal that was never as far along as it looked.
Milestone-based stages require that something has changed on the buyer's side. "Problem Confirmed" means the prospect has acknowledged a specific problem and agreed it is worth addressing. That is a much harder bar to clear, which is exactly the point. Deals that pass that bar actually belong in the pipeline at that level.
This shift alone will shrink your reported pipeline by 20-30%. That number is not bad news. It is good news. It means your forecast is getting honest.
Why HubSpot's defaults work against you
HubSpot gives you seven default stages with preset win probabilities. They look organized. They work fine as a demo. For a real B2B sales team, they are almost always wrong.
The problem is not the stages themselves but the probabilities. HubSpot assigns 20% to "Qualified to Buy" and 80% to "Decision Maker Bought-in." These are guesses, not your historical data. A company that closes 15% of qualified opportunities should not be using 20% probability for that stage. A company with a long enterprise sales cycle might close 30% of proposals, not 80%.
When your win probabilities do not match your actual close rates, your forecast is off by a predictable amount in a predictable direction. You cannot fix that without changing the stages and probabilities to reflect your actual history.
I worked with a SaaS company earlier this year that had been running HubSpot for 18 months. They had never changed the default stages. When we pulled their actual win rates by stage against the forecast probabilities, every stage was off. Some by 10 points, two by 30. Their sales manager had been manually adjusting the forecast every week in a spreadsheet to compensate. We rebuilt the stages, calibrated probabilities to historical data, and got them to 91% forecast accuracy within 90 days.
How to audit your current stages in 30 minutes
Before you redesign anything, do this audit. It takes one pipeline review call and a spreadsheet.
Pull every deal in your current pipeline and ask three questions for each stage:
First, what does a rep have to do to advance a deal to this stage? If the answer is "send an email" or "schedule a call," your stages are activity-based. Mark those stages for revision.
Second, do two different reps interpret this stage the same way? Pick two reps at random and ask them separately when they would move a deal from stage three to stage four. If you get two different answers, you have an exit criteria problem.
Third, do the deals in this stage close at the rate implied by the win probability? Pull closed-won deals from the last 12 months and check what percentage of deals in each stage eventually closed. If your stage four is set to 60% but you actually close 35% of those deals, your forecast is inflated by a factor of 1.7x at that stage alone.
This audit almost always shows the same thing: two or three stages that need to be merged, one or two that need clear exit criteria, and probabilities that are off across the board. That is a two-week fix.
The deal stage framework that works for most 50-person B2B companies
After auditing pipelines across dozens of companies, I keep coming back to the same structure. Six stages, milestone-based, with clear exit criteria for each.
The probabilities here are starting points. Replace them with your own historical close rates once you have 3-6 months of clean data. That is when the forecast model gets genuinely useful.
One note on Closed Won and Closed Lost: they are not really stages in the predictive sense. They are outcomes. Include them in HubSpot but do not assign a meaningful probability to Closed Won (it is 100% by definition). For Closed Lost, the stage label matters less than the loss reason property. Make that a required field. Over 6 months you will have data on why deals die, and that is worth far more than knowing how many went to zero.
Exit criteria: the thing every team skips
You can have perfect stage names and still have a broken pipeline if your team disagrees about when to advance a deal. This is the most common thing I see in otherwise well-designed pipelines.
Deal stages are only as good as their exit criteria.
Without exit criteria, two reps will interpret the same stage differently, and your forecast becomes an average of their individual optimism levels.
Exit criteria are the conditions that must be true before a deal moves to the next stage. Specific and verifiable, not aspirational.
Here is what they look like in practice for a B2B SaaS company:
For the Qualified stage, exit criteria might include: budget explicitly confirmed with a number, decision-maker name recorded in HubSpot, a specific problem statement documented in the deal notes, and a target go-live date or decision timeline provided. All four boxes must be checked before the deal moves to Fit Validated.
For Champion Identified, the exit criteria might be: one internal contact has explicitly agreed to advocate for the purchase internally, you have had a call with them where they expressed willingness to push this forward, and you know the names of the other stakeholders involved in the decision.
Write these criteria down. The best place to store them is in HubSpot's internal notes or as a deal property checklist. Some teams paste their stage criteria into the deal stage description field in HubSpot Settings so reps can see it while they work. Whatever method you use, make it visible.
The weekly pipeline review conversation should stop being "when does this deal close?" and start being "which exit criteria are still missing for this stage?"
How many pipelines do you actually need?
The default answer for most teams at the 50-person stage is one pipeline for new business. Full stop.
I see teams create separate pipelines for SMB vs enterprise, for different products, for inbound vs outbound. They think more granularity will give them better insight. What they get is maintenance overhead and fragmented reporting.
Start with one pipeline. Add a deal property for segment (SMB, mid-market, enterprise) and another for source (inbound, outbound, partner). Filter your reports by those properties when you need segment-level visibility. Keep the pipeline structure unified.
The one exception is expansion and upsell. Once your new business pipeline is stable and you have dedicated capacity managing expansion, a separate expansion pipeline makes sense. The stage definitions for expansion are meaningfully different from new business. Until then, you are adding complexity without benefit.
Setting this up in HubSpot
The deal stage editor is in Settings, then CRM, then Deals, then Deal Stages. You can rename, reorder, add, and delete stages here. The probability field is editable. Change the default probabilities before you go live with new stages.
Required properties by stage is a HubSpot feature most teams ignore. You can require specific CRM fields to be filled before a deal advances. This is the closest thing HubSpot has to enforcing exit criteria automatically. Set it up for your most impactful fields: budget amount, decision-maker name, close date, and company size.
If you want to see how long deals spend in each stage, go to Reports, Create Report, and build a funnel report showing average time-in-stage. This is your pipeline bottleneck diagnostic. If the average deal sits 30 days in "Qualified" but only 5 days in "Fit Validated," qualification is your constraint. That is where coaching attention goes.
Deal rotation is worth configuring if you have multiple reps. HubSpot's deal rotation tool (available in Professional and Enterprise) assigns new deals based on rules you define. Pair it with clear stage definitions and you get consistent process from rep one to rep ten.
One last thing: do not let old deals rot in the pipeline. Set a rule (15-30 days of no activity, no advancement) that flags deals for manager review. Either the rep revives the deal with a clear next step or it gets closed. Ghost deals inflate your pipeline, distort your forecast, and waste rep attention. The goal is an honest pipeline, not a large one.
For more on how we approach CRM and RevOps setup and how AI automation can support these workflows, you can see examples from our client work. If you are evaluating a CRM migration or switch, the deal stage design question comes up in every engagement we run.
Your pipeline is probably lying to you.
Book a free 30-minute audit and we'll show you the three fixes we would make to your deal stages first.
Book an audit →FAQ
What are HubSpot deal stages?
Deal stages in HubSpot are the steps in your sales pipeline that represent a buyer's progress toward a closed deal. Each stage has a name, a win probability, and ideally a set of exit criteria that must be met before a deal advances. They determine how HubSpot calculates forecasted revenue and how your sales team tracks pipeline health.
How many deal stages should I have in HubSpot?
Most B2B teams work best with 6-7 stages. Fewer than 5 makes it hard to identify where deals stall. More than 8 creates rep confusion and inconsistent data. Start with 6 well-defined milestone-based stages and adjust based on what you observe over your first two quarters.
Should I use HubSpot's default deal stages?
HubSpot's defaults are fine for getting started, but most growing B2B teams outgrow them quickly. The default stages are activity-based and use generic win probabilities that do not match most real sales processes. Replacing them with milestone-based stages tied to your actual historical win rates is the single most impactful pipeline fix most teams can make.
How do deal stages affect forecast accuracy in HubSpot?
HubSpot calculates forecasted revenue by multiplying each deal's value by its stage probability. If your stage definitions are inconsistent (different reps advancing deals at different points) or your probabilities do not match historical data, the forecast will be off. Well-designed stages, combined with weekly pipeline hygiene, can take teams from 45% forecast variance to below 10%.
Can I have multiple pipelines in HubSpot?
Yes, HubSpot supports multiple pipelines. For most teams at the 50-person stage, one pipeline for new business is enough. Add deal properties for segment and source to filter reports without creating separate pipelines. A second pipeline for expansion makes sense once you have a dedicated team managing that motion separately.