Free: the GTM BlueprintThe stack, by funding stageThe CRM data model, written downSeven steps, six handoffsRoles, and when to hire themA 90-day plan you can run on MondayThe three numbers that decide itNo PDF, no drip sequenceGet the blueprintFree: the GTM BlueprintThe stack, by funding stageThe CRM data model, written downSeven steps, six handoffsRoles, and when to hire themA 90-day plan you can run on MondayThe three numbers that decide itNo PDF, no drip sequenceGet the blueprint
RevOpsXL
GTM Diagnostic Book the audit

Stage vs status in HubSpot: why your pipeline report lies

Deal stage is where a deal is. A status property is what's true about it. Put the second job into the first field and your weighted pipeline turns into fiction.

In short

In HubSpot, deal stage should only answer how close a deal is to closed, and it carries a forecast probability. What’s true about a deal - stalled, on hold, waiting on us - belongs in a separate status property. Mix them and the pipeline report counts parked deals as nearly won.

On this page

Your HubSpot pipeline report lies because two different questions are fighting over one field. Deal stage is meant to answer one thing: how close is this deal to becoming money. Add stages like 'on hold' or 'waiting on legal' and you have smuggled a status into a field that HubSpot counts as forecast - so the number the board sees is now built partly out of deals that aren't moving.

The fix is not a new report. It is separating the two questions into two fields, once.

Stage is where the deal is. Status is what's true about it.

Two questions, and HubSpot gives you two places to answer them - if you use both.

Deal stage is position: prospecting, qualified, proposal, negotiation, closed. A step on the path to closed-won, and only that. Status is condition: active, stalled, waiting on us, waiting on the customer. What is happening to the deal right now, regardless of how far along it is.

A deal can be sitting in 'negotiation' and completely stalled. Those are two separate facts about one deal. They need two separate fields.

Why the pipeline report lies

Here is the mechanism, because it is the whole point. Every HubSpot deal stage carries a deal probability - a percentage HubSpot uses to weight your pipeline. Proposal might be set to 60 per cent, negotiation to 80. The weighted pipeline your forecast rests on is every deal's amount times its stage probability, added up.

Now park a dead deal in 'negotiation'. HubSpot weights it at 80 per cent. It does not know the customer went quiet three weeks ago, because 'went quiet' is a status, and you never gave the deal one. So it sits in the forecast at eighty cents on the euro, fully weighted, quietly wrong.

Do that across a pipeline and the report is not lying on purpose. It is averaging live deals with parked ones and presenting the total as if all of it were moving. A weighted pipeline is only as honest as the stages feeding it.

The 'on hold' stage is where the number goes to rot

The tell is a pipeline full of parking spots. 'On hold.' 'Nurturing.' 'Waiting on procurement.' They feel tidy - somewhere to move a deal so it is off the active list. But each one is a status wearing a stage's uniform, and each carries a probability into your forecast.

'On hold' at any probability above zero is a deal you have told HubSpot is partly won and told yourself is parked. Both can't be true. Usually the forecast believes the field and you believe your gut, and the two numbers drift apart until nobody trusts the report - which is the real cost, long before anyone miscalls a quarter.

How to set it up right in HubSpot

Keep stages forward-only and few. Each stage is a promise that specific things are true, and every deal in it is genuinely that close to closed. If a stage doesn't move a deal toward money, it is not a stage.

Put condition in its own property. Add a custom 'Deal status' dropdown - active, stalled, waiting on us, waiting on them - and separate fields for next step and close-date confidence. Now 'stalled in negotiation' is one deal described by two honest fields, and you can filter the forecast down to live deals without deleting the parked ones.

The same split runs at the contact level. Lifecycle stage is position; lead status is condition, and HubSpot ships them as two separate properties for exactly that reason. Treat lifecycle stage like a lead status, or a deal stage like a health field, and you have rebuilt the same bug one object up. It is the stage-versus-status problem in named-tool form.

Then put a clock on each stage. A deal that hasn't moved in the time the stage should ever take gets flagged - not deleted, flagged. Stuck should be visible, not invisible.

The forecast was never the problem

You don't have a forecasting problem. You have a field doing two jobs, and the forecast is just where it shows up first.

Split the two questions, give each its own field, and the weighted pipeline stops flattering you. The number gets less exciting and a good deal more true - which is what building the pipeline right buys you, instead of arguing with the report it produces. That is CRM architecture, and it is most of what the work actually is.

Common questions

What is the difference between deal stage and status in HubSpot?

Deal stage is where a deal sits on the path to closed, and it carries a forecast probability. Status is what is true about the deal right now - active, stalled, on hold. Stage is position; status is condition, and they belong in separate fields.

Why is my HubSpot pipeline report inaccurate?

Often because status-type stages like 'on hold' or 'nurturing' live in the pipeline carrying a deal probability. HubSpot weights them into the forecast as if they were live deals, so parked deals inflate the number.

Should 'on hold' be a deal stage in HubSpot?

No. 'On hold' describes a deal's condition, not its distance from closed, so it belongs in a separate status property. As a stage it carries a probability into your weighted pipeline and distorts the forecast.

Most CRM problems are one problem underneath: a system nobody owns. That is the work we do.

See how we work Run the GTM diagnostic

Get the next one

New field notes twice a month. We don’t do newsletters, follow RevOps XL on LinkedIn instead.

Follow on LinkedIn

Sound familiar?

If this is happening in your stack, tell me about it. A senior expert reads these, not a bot - and you’ll get a real answer, whether or not you ever hire us.

← More field notes