Stage vs status in HubSpot: why your pipeline report lies

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 to split the two questions into two fields, once. A new report won't do it.

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

The mechanism 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 and 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, so the weighted number 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.' '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. That keeps stuck deals visible instead of hidden.

The forecast was never the problem

What looks like a forecasting problem is a field doing two jobs, and the forecast is 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 is.

Common questions