Sales forecasts are usually inaccurate for structural reasons rather than because salespeople are optimistic. Across 500-plus HubSpot CRM implementations, the same six causes recur: pipeline stages without documented entry and exit criteria, probability weightings nobody validated against closed-won history, lifecycle stages managed inside the deal pipeline, multi-year and multi-currency deals stored as a single amount, forecast-critical fields left unpopulated, and a manual spreadsheet running in parallel to the CRM.
Each is a configuration and definition problem, not a sales discipline problem. That matters because it changes who fixes it and in what order.
Diagnostic table: six causes of forecast failure
| Cause | What it looks like | How to check it |
|---|---|---|
| Undefined stage criteria | Two deals in the same stage have very different close probability | Ask three reps what "Proposal Sent" requires. Compare answers |
| Unvalidated weightings | Forecast is consistently out by a similar margin each quarter | Export closed deals, calculate actual win rate per stage, compare to CRM probability |
| Lifecycle stages inside the pipeline | Conversion rate has looked stable and low for years | Check whether lifecycle stage and deal stage are the same mechanism |
| Single-amount multi-year deals | Current-year forecast inflated, or out-years missing entirely | Look for separate Year 1, Year 2, Year 3, ARR and TCV fields |
| Missing forecast-critical fields | Regional or business-unit splits do not reconcile | Report on fill rate for entity, region, owner and associated company |
| Parallel spreadsheet | Someone maintains a commercial workbook by hand each month | Ask which number leadership quotes in a board meeting |
Reporting accuracy is not business accuracy
A CRM reports what was entered into it. A dashboard can be entirely correct about the data it holds and still give an inaccurate picture of the pipeline. Precision is not accuracy: a forecast of R10 million is no more trustworthy for being calculated to the nearest rand.
This distinction becomes concrete when reporting depends on partly populated fields. On one managed IT services engagement, regional forecast reporting was blocked by a single field identifying which business entity a deal belonged to. The field existed and the dashboards rendered, but inconsistent population made the regional split unusable, and alternative company-level fields had to be found before the reporting could be trusted.
The same applies to deals sitting in the pipeline with no owner and no associated contact. They contribute to the pipeline total and cannot be attributed, chased or coached on.
Property sprawl compounds it. One enterprise portal carried 11 duplicate properties spread across objects that had to be consolidated into single authoritative fields, alongside formatting inconsistencies across more than 98,000 records and a set of properties with a zero fill rate that were archived. A zero-fill-rate property looks legitimate in a dropdown and returns an empty answer to anyone who reports on it in good faith.
What to check: fill rate on every field your forecast segments by, and the count of deals with no owner or no associated company.
1. Pipeline stages need documented entry and exit criteria
Stage names without rules mean each rep applies their own interpretation. One salesperson moves a deal to a late stage when a proposal is sent; another waits for confirmed commercial approval. Both deals look identical in the report.
On an enterprise security services engagement, an eight-stage pipeline was built with documented entry and exit criteria for every stage, implemented through workflow automation so the CRM enforced them rather than relying on recall. Each stage answered one question: what must be true for a deal to be here?
Effective criteria describe a change in the buyer's position, not an action the salesperson completed. Sending a proposal is an activity. Confirmed budget, a named decision maker and an agreed implementation date are evidence.
What to check: whether each stage has a written definition, and whether the CRM enforces it or simply records it.
2. Probability weightings need validating against your own history
Most pipelines carry probability percentages inherited from whoever configured the CRM, then reported on for years without testing.
On a managed IT services engagement, the forecast was running a 25% weighting at proposal creation when the business's own closed-won history supported 20%. A five-point error at a high-volume stage is the difference between a forecast leadership can plan headcount against and one they cannot.
The validation test takes about half a day. Export at least four quarters of closed deals, or eight where the sales cycle runs beyond 90 days, calculate the percentage that reached each stage and went on to close won, and compare that against the probability the CRM applies at that stage.
What to check: actual win rate per stage versus configured probability per stage.
3. Lifecycle stages belong outside the deal pipeline
Where lifecycle stage and deal stage run through the same mechanism, every cold and unqualified lead sits inside the pipeline calculation and depresses conversion.
On a procurement consultancy implementation covering UK, US and South African operations, separating the two was among the highest-value changes made. Lifecycle stages tracked the contact journey; the deal pipeline tracked commercial opportunities with probability redefined at each stage. The team could then see genuine stage-to-stage conversion and locate where deals stalled, rather than working from a blended figure polluted by leads that were never commercially real.
The handover between marketing and sales is worth automating at the same point. On the enterprise security services engagement, reaching MQL triggered sales owner selection, which generated a task plus email and Slack notifications asking the owner to accept or reject the lead. Rejection required a reason, which produced lead acceptance and rejection data that had never existed and a documented feedback loop to marketing.
What to check: if your lead-to-close conversion rate has looked stable and low for several years, this is usually why.
4. Multi-year and multi-currency deals cannot be single amounts
A three-year contract is four numbers: total contract value, annual contract value, revenue recognised in the current year, and a renewal event in the future. Stored as one deal amount, it either inflates the current year with unearned revenue or loses the outer years entirely.
On an enterprise software engagement where finance required year-by-year revenue recognition, deals were segmented into yearly components with the amount reflecting annual value while total contract value stayed intact on the line items. It was not accepted as a working model until it had been tested against a batch of 48 purchase-order deals with line items entered manually.
On another engagement, definitions came before configuration. ARR, ACV, TCV and MRR were each defined explicitly, including the treatment of one-time fees, onboarding fees and non-recurring revenue, and the calculation logic for contracts with variable pricing across contract years. Every dashboard and workflow downstream inherits those definitions, which is why changing them later means rebuilding.
Currency is the same class of decision. On a managed IT services engagement reporting in both US dollars and rands, dashboards were built on static hedged rates rather than live conversion. A forecast that moves because the exchange rate moved cannot be compared month to month and makes sales performance look like a function of the currency market.
What to check: whether ARR, ACV, TCV and MRR exist as signed-off written definitions, and whether your reporting rate is fixed or live.
5. Forecast categories should follow the stage, not the rep
Forecast categories such as pipeline, best case and commit are useful, but a category selected from a dropdown records an opinion rather than a position.
On the enterprise security services engagement, the mapping between deal stage and forecast category was agreed with the client's finance team, documented, and built as workflow automation so the category followed the stage. The judgement moved into the design of the system, where it can be reviewed, rather than sitting with whoever last opened the record.
Close dates need the same treatment through visibility rather than instruction. On the procurement consultancy engagement, the deal dashboard showed how long each deal had sat in its current stage alongside the next scheduled activity. A deal that has not moved in ninety days is a more useful prompt than a close date that has quietly been rolled forward.
What to check: whether forecast category is automated from stage, and whether time-in-stage is visible on the deal record.
6. A manual workbook means you have two forecasting systems
Where someone maintains a commercial workbook by hand each month, the CRM is the number being discounted.
On the procurement consultancy engagement, replacing that workbook with dashboards for both UK and US operations was a stated project objective. The goal was not the dashboard. It was moving the business to relying on the CRM for sales data end to end, so there was one number under discussion instead of two.
That only holds once the five causes above are addressed. Building the dashboard first produces a more sophisticated presentation of the same unreliable number, which is also why increasing the frequency of pipeline reviews rarely helps. More meetings on unreliable data create more opportunities to debate unreliable data.
Integration surfaces problems that were previously invisible. On the managed IT services engagement, deal amounts had to be refreshed through a workflow once line items synced, product bucket mappings needed correcting before regional reporting was accurate, and negative line item entries traced back to a training issue rather than a system fault.
What to check: which spreadsheets still exist, who maintains them, and what they contain that the CRM does not.
The order to fix this in
Sequence matters more than effort. Each step depends on the one before it.
- Document stage entry and exit criteria and enforce them in workflow. Nothing downstream works until "what stage is this deal in" has a defensible answer.
- Validate probability weightings against four or more quarters of your own closed-won history. Roughly half a day of work.
- Separate lifecycle stages from pipeline stages so conversion measures commercial reality.
- Define the revenue model in writing covering ARR, ACV, TCV, MRR, multi-year treatment and currency policy, and have finance sign it off before configuring anything.
- Make forecast-critical fields required and controlled, and clear unowned and unassociated deals.
- Build the reporting layer, automate stage-to-forecast-category mapping, and retire the spreadsheet deliberately.
Why MO Agency for Revenue Operations?
MO Agency designs revenue systems for enterprise and growth-led companies, covering CRM architecture, data governance, process design, automation, integration, reporting and forecasting, with HubSpot as the central operational system.
A forecasting problem can sit in pipeline architecture, data governance, ownership, automation or integration, and often in several at once. MO's methodology is Diagnose. Design. Deliver., which means mapping the existing revenue system before recommending what changes.
A perfectly predictable pipeline is not realistic. A revenue system that gives leadership a consistent view of what is actually happening is.
A forecast is only as reliable as the data and definitions beneath it. See what revenue operations is, why your CRM data cannot be trusted, and how we run it as a revenue operations service.
Frequently asked questions
Why is my sales forecast always wrong?
Most commonly because pipeline stages have no documented entry criteria, probability weightings were never validated against actual close rates, or the fields the forecast segments by are inconsistently populated. All three produce a dashboard that is correct about its data and wrong about the business.
How do I know if our pipeline probability weightings are wrong?
Export at least four quarters of closed deals, calculate the proportion that reached each stage and went on to close won, then compare that to the probability the CRM applies at that stage. Where the two differ, the forecast is running on an estimate rather than evidence.
How should multi-year contracts be recorded in a CRM?
As separate reportable values: Year 1, Year 2 and Year 3 value, current ARR, and total contract value across the full term. A single deal amount either inflates the current-year forecast or loses the out-years. Test any structure against real purchase orders before finance relies on it.
Should we use live or fixed exchange rates for forecast reporting?
Fixed. Static hedged, budget or period-average rates keep period-on-period comparison meaningful. Live conversion makes the pipeline move for reasons unrelated to sales performance.
Can RevOps help if we already use HubSpot?
Yes. Having HubSpot does not mean the surrounding revenue operation is structured correctly. Inconsistent processes, weak data governance, disconnected systems and reporting that does not match how the business operates all persist regardless of platform.
What should we fix first if leadership doesn't trust the forecast?
Stage entry and exit criteria, enforced in workflow. Until a deal's stage has a defensible definition, validating weightings, measuring conversion and building dashboards all sit on an unreliable foundation.
Build a revenue operation you can trust
A sales forecast is only as reliable as the system behind it. Where stages are undefined, weightings unvalidated, revenue definitions unwritten and a spreadsheet runs alongside the CRM, no forecasting model compensates.
The fix is not another dashboard or another pipeline review. It is stage criteria, validated weightings, a signed-off revenue model and controlled fields, in that order.
If you don't trust your sales forecast, it may be time to look at the revenue operation behind it. Explore MO Agency's Revenue Operations services.
