Why backward stage moves are a hidden forecast leak
Every pipeline stage has an associated probability — Discovery might be 20%, Negotiation 60%, Contract Sent 80%. The forecast math multiplies Amount × Probability for each open deal.
When a deal moves backward — say from Negotiation back to Discovery — the probability drops, but the Amount × Probability math only reflects that drop in the new (lower) stage. What it doesn't reflect: this deal has now demonstrated, by going backward, that it's a higher-risk deal than its new stage suggests. A deal that naturally sits in Discovery has a 20% probability. A deal that bounced back to Discovery has demonstrably lower than 20% — historically these convert at half the rate.
The same logic applies to reopened-after-closed deals. A deal closed-lost three months ago, reopened by the rep last week, isn't really in Discovery — it's a recovery attempt with conversion odds well below the stage average.
The fix is twofold: (1) find these deals so the manager knows, and (2) flag them in the forecast so the weighted number reflects their actual probability, not the stage's nominal one.
What two patterns the property history actually shows
Two patterns to detect:
- Stage regression: deal's stage history shows a move from a later stage to an earlier one.
- Reopened after closed: deal currently in an open stage was previously in
Closed WonorClosed Lost.
Both require reading the deal stage's property history, not the current value.
Why pipeline-specific stage ordering complicates the rule
Stage ordering varies across pipelines. If you have multiple pipelines (sales, partnerships, renewals), each has its own stage order. The "regression" check has to know which pipeline it's in, and the order can't be assumed.
The reopened-after-closed case has its own quirks. HubSpot's standard practice is to not reopen closed deals — instead create a new deal record. But many teams ignore that and reopen anyway because it preserves the activity history, which is convenient for context. Detecting reopens then requires looking for Closed Won or Closed Lost anywhere in the deal's history combined with a current open stage. That's not a one-filter answer; it's a property-history scan.
The other friction: legitimate stage regressions exist. A deal was prematurely advanced to Negotiation, the rep walked it back to Discovery to do proper qualification — that's good sales hygiene, not a problem. The rule generates false positives that need human review. Worth running monthly as a manager triage list, not worth firing alerts on every regression.
The manual HubSpot recipe
One custom property + one workflow per pipeline + one saved view. Operations Hub Pro+ required for the stage-order comparison.
- Create the custom propertySettings → Properties → Deals → Create property. Name:
stage_regressed. Type: Single checkbox. Default value: false. - Build the regression-detection workflowWorkflows → Create → Deal-based. Trigger:
Deal stagechanged. The workflow needs to know stage ordering — Operations Hub Pro+ exposes this as a property. - Branch: new stage's pipeline order < previous stage's orderIf/then branch: new stage order < previous stage order. This requires the stage-order comparison, which is Operations Hub Pro+ only.
- Action: set stage_regressed to trueIf branch matched, set
stage_regressed = true. Optional: also append the regression date to a custom propertystage_regressed_atfor time-series analysis. - Build the saved viewSales → Deals → Create view. Filter:
stage_regressed = trueANDDeal stage is not closed won/lost. Save as 'Deals — Stage regressed'. - Run a separate workflow per pipelineIf you have multiple pipelines (sales, partnerships, renewals), each has its own stage order. The regression check has to know which pipeline it's in. Build one workflow per pipeline.
What Bloated does instead
Backward stage moves AND reopens, weighted in the forecast for what they really are.
Bloated walks each deal's full stage history server-side, catching both regressed-from-late-to-early and reopened-after-closed patterns. Regressed deals weighted lower in forecast probability — a Discovery deal that *bounced back* to Discovery shouldn't have the same probability as a fresh Discovery deal. The forecast number reflects reality, not the stage's nominal probability.
dealstage (history) · HubSpot deal property