In short: a pipeline stage is only useful for forecasting if it names something the buyer did that someone can verify. "Proposal sent" describes your rep; "proposal reviewed on a call" describes your customer. Rewrite each stage around an exit criterion, make the properties that prove it required, and your forecast starts to mean something.
On September 25, 2026, we reviewed our own HubSpot pipeline using the same checklist we use in client diagnostics. Of seven stages, three described what we did: "proposal sent," "diagnostic delivered," and "assessment delivered." Not one of the seven described something the customer had done. It is the most common mistake we see in B2B portals, and we had it at home.
When a stage is called "proposal sent," the deal lands there the moment your rep clicks send. From that second on, HubSpot applies the stage probability and adds the deal to the forecast. But the stage can't tell a proposal the buyer reviewed with their team from one sitting in a spam folder. Both count the same in the report.
The result is a forecast that measures activity, not progress. If your team is busy, the pipeline looks healthy even if no buyer has moved. And when the quarter closes short, the explanation is usually "a few deals slipped at the end," when in reality they were never where the CRM said they were.
The rule we use now is simple: a stage exists only if it names something the buyer did and someone else can verify it without asking the rep. If the only evidence is "I sent it," that is not a stage. It is a task.
You don't need to throw the pipeline away. Most of the time it is enough to change the verb and the subject of each stage, from what we did to what the customer did, and add what proves it happened. Below are the three stages we fixed in our own portal, plus two illustrative examples of patterns we see often.
| Rep stage | Buyer stage | What proves it |
|---|---|---|
| Proposal sent | Proposal reviewed on a call | Logged meeting with the decision maker and notes on objections |
| Diagnostic delivered | Diagnostic discussed with the decision maker | Session date and agreed next step |
| Assessment delivered | Findings prioritized by the customer | The three findings the customer chose to tackle first |
| Demo scheduled (example) | Problem confirmed in the demo | Main problem written in the customer's own words |
| Negotiation (example) | Terms sent to procurement or legal | Procurement contact associated with the deal |
The third column is the one that matters. Each row becomes one or two deal properties, and those are the properties you will make required.
Better names change nothing if a deal can move forward without the evidence. These are the pieces that lock it in, all documented in HubSpot's knowledge base:
With that in place, the forecast no longer depends on someone remembering to update the CRM on Friday. For context on why so many companies own HubSpot and still sell from spreadsheets, see our article on the 54%.
At the Fall 2026 Spotlight on September 16, HubSpot presented the redesigned Deal Progression: it reads a deal's emails, calls, and meetings and proposes stage and next-step updates the rep approves with one click. It sounds like the problem solves itself. It doesn't.
The agent needs stages with exit criteria to know when to propose a move. If your stage says "proposal sent," all it can detect is that someone emailed a PDF, and it will move the deal as loosely as your team does today. And anything that never comes up in a conversation (approved budget, procurement contact, loss reason) still needs a required property.
Another change pushes in the same direction: starting with the 2026-09 API version, HubSpot rejects integration writes that break the conditional required properties you configured. The rules you set on your stages will also apply to whatever comes in through Zapier, Make, or any connector, so it pays to define them well before your integrations upgrade.
If you run more than one pipeline, if your reports already depend on current stage names, or if integrations create and move deals, changing stages without a plan breaks dashboards and workflows nobody remembers building. In those cases it is worth reviewing it with someone who has done the migration before. Our HubSpot diagnostic includes the stage redesign with its properties and the order to change them without losing history.
If you want to know where your HubSpot stands today, the free self-assessment takes 3 minutes: take the self-assessment (in Spanish).
For most B2B teams, five to seven open stages plus Won and Lost. Fewer than five usually hides the steps where deals stall; more than seven makes reps pick stages out of habit. The number matters less than each stage having an exit criterion you can verify on the record.
Yes. Changing a stage label does not change its internal ID, so history and stage calculated properties are preserved. What can break are reports, views, and workflows that filter on that stage, so check what depends on it before merging or deleting stages.
Based on what HubSpot presented in September 2026, the agent proposes updates from emails, calls, and meetings, and the rep approves them with one click. It depends on every rep's email and calendar being connected and on stages having clear exit criteria.