Was your forecast right, before each deal closed?
Forecast accuracy asks one question the tools themselves cannot answer: was the forecast right at the time it was made? Every figure is read from the deal’s change history, as the fields stood before the deal was decided, because your tool rewrites probability and close date at the moment a deal closes. If what you want is the behaviour of the close-date field itself rather than the forecast it produced, read Is each field being used for what it is for? instead.
Before you start
Open Analysis, choose your tool, and click Forecast accuracy. The first read calls your tool for each closed deal’s history, and the screen says so: “Reading what each closed deal’s forecast said before it closed. The first read takes up to a minute.”
Why today’s values are useless here
A tool sets probability to 100% or 0%, and the close date to the real one, the moment a deal closes. Judging those fields as they stand today would make every forecast ever made look perfect. Nothing on this page reads a current value.
Which deals are judged, and which are left out
Only closed deals — won or lost. An open deal has no outcome to judge a call against.
A deal that was open for less than 14 days is left out altogether, because it was never forecast: it was logged after it was decided. The count is on the fourth tile at the top of the tab, labelled Logged after the fact, so a book full of after-the-fact deals is visible before you read a single percentage. The other three tiles are Closed deals judged, Won and Lost.
Below 30 judged deals nothing is claimed at all. The headline says so in as many words: it takes at least 30 before a percentage means anything.
How far back each field is read
The forecast category is read as it stood 14 days before the deal was decided. The close date is read as it stood 30 days before. The stage is read differently: a deal counts towards a stage if its history shows it at that stage at any point before it closed, which is the rule the stage table below rests on. The two windows are why a deal has to have lived 14 days to be judged at all, and 30 days to be judged on close-date slip.
Are your stage probabilities true?
The table headed Each stage: what the pipeline says, and what happened puts the probability configured on each stage beside the rate deals that reached it really closed at. Its columns are Stage, Pipeline says, Has been and Closed deals, with a tag in the last column reading says more than it delivers or says less than it delivers.
- A stage counts a closed deal as having reached it when the deal was recorded at that stage at any point before it closed — whether it moved forwards from there or was lost from there. It is not the stage the deal ended in.
- A verdict appears only with at least 30 closed deals behind that stage, and only where your tool holds a configured probability for it. Below that the row still shows, with no tag.
- A stage is called optimistic only when the configured probability sits more than five points above the top of the 95% range for the real win rate. A stage that is merely a little high is left alone.
- Closed stages are not judged. A stage whose meaning is “won” or “lost” has no forecast in it.
Where a stage is optimistic, the finding gives you the replacement figures from your own closed deals and names the screen to set them on: in HubSpot, Settings › Objects › Deals › Pipelines and the stage’s Deal probability; in Salesforce, Setup › Object Manager › Opportunity › Fields › Stage and each value’s Probability.
Take care
The weighted pipeline your board sees is every open deal’s amount multiplied by these percentages. A stage overstated by twenty points inflates that number by design, every month, before a single rep has been optimistic. Quote the “has been” figure with the deal count beside it — “28%, on the 94 closed deals that reached Proposal” — not the percentage alone.
Did a Commit close?
The panel headed What each forecast call turned into lists every value your forecast category held 14 days before each deal was decided, with what those deals became. It appears only where your workspace has a forecast category field for MarqIQ to read.
One of those values is then singled out as a finding when it fails: the commit-style value, recognised from its own wording rather than from a fixed list. Two conditions have to be met, and both catch workspaces out.
- At least 30 closed deals must have carried that value 14 days out. The 30 is on the bucket, not on the tool: a workspace with 200 closed deals and 18 Commits gets no finding.
- The top of the 95% range for its win rate must sit below 80%. A commit that holds is never reported as a problem, which is the right way round.
Where it does fail, the finding splits the misses by owner. A rep is named only with five or more deals in that category — as someone whose commits hold when they won 80% or more, and as someone whose commits miss when they are more than 15 points below the rate for that category as a whole. The advice then starts from the people who are already right, rather than from a definition invented here: write down what they require before they use the word, make that the definition, and review the others against it.
How far do close dates slip?
Measured on won deals only, and only those that lived at least 30 days. For each one the close date is read as it stood a month before the deal actually closed, and compared with the day it really closed.
- The section needs at least 30 such deals. Below that no slip figure is shown.
- A finding is raised when 30% or more of them closed more than a month after the date forecast for them, and becomes a fault at 50%.
- The finding gives the typical slip in days, and the share that closed within a week of the forecast date. Both are printed with the deal count they rest on.
The fix points at Field discipline, which names the open deals whose close date has already been pushed three times or more, and who pushed them. That is where a slipping forecast is caught while it can still be changed.
Probabilities set that your tool is not using
Pipedrive lets a pipeline switch its deal-probability weighting off while the ladder of percentages stays in place. Where that is true, one finding names every pipeline it applies to — not one card each — and says that every weighted total in the pipeline view is unweighted while those numbers sit there looking maintained. The stages are still judged against what really closed, because they are what the team wrote down.
This finding never leads the headline. A stage that closes at a third of what it promises always outranks a setting that is merely switched off.
What each figure is measured on
- Every rate on the tab is over closed deals with readable history, never over open deals. The method at the foot of the page prints the count read and, where your store is larger than the read, says it was an even sample of the closed deals in your tool.
- The stage table’s denominator is the deals that reached that stage, which differs per row. Two rows on the same table can rest on 30 deals and 400.
- The commit figure’s denominator is the deals that carried the commit value 14 days out, not all closed deals. The finding prints both that count and your overall win rate so the two can be compared.
- The slip figure’s denominator is won deals that lived at least 30 days and carry close-date history. Lost deals are not in it.
Where it stays blank, and why
| Situation | What you see |
|---|---|
| Marketo, Zoho CRM, Dynamics 365, Pardot (MCAE), Mailchimp, Marketing Cloud, Adobe Campaign, Adobe Journey Optimizer | The tab is muted and says MarqIQ cannot read that tool’s forecast fields yet. On Marketo it is more than that: deals live in the CRM Marketo syncs with, so connect that CRM and the forecast is judged there |
| No deals synced from the tool | The same Not set up yet card as the row below, headed “<Tool> does a forecast on deals, and you have not set it up yet.”, followed by the stage-probability steps for your tool. It talks about deals throughout — the headline, the property to fill, the steps — but never says that none have synced |
| Deals synced, no probability or forecast field filled | A Not set up yet card with the setup for your tool — what it is called there, where it lives, which edition it needs, and how to confirm it is working |
| Fewer than 30 judged deals | The tiles and the headline, and no percentage. Nothing is claimed |
| No forecast category field | The stage table and the slip figure, and no commit panel |
The card cannot tell a missing sync from a missing probability
Those two rows produce the same card, word for word. It is written from what your tool can do, so the line about no deals having synced yet is not carried onto it, and you are shown setup steps for stage probabilities you may already have set. Check the deal count before you open your pipeline settings: the Executive Read on the same tool prints how many deals are in scope, and a zero there points at the sync.
How far this has been tested
HubSpot is verified on a live portal. Salesforce reads Opportunity History, which every org keeps for stage, amount and close date without any setup, but has not been run against a live org. Pipedrive reads its own per-deal changelog.
What it will not do
- It changes nothing in your tool, and sets no probability for you.
- It quotes no industry benchmark. Every comparison is against your own closed deals.
- It does not judge open deals. A deal that has not closed has no answer yet.
- It never names a rep on fewer than five deals in a category.
If it did not work
The tab says nothing is claimed yet
Why: Fewer than 30 closed deals have enough history behind them. Deals that lived under 14 days are excluded before that count is taken.
Fix: Clear the Created filter to widen the population, then click Read the latest from your tool. Check the Logged after the fact tile: where it holds most of your book, deals are being created after they are decided, and that is the finding to act on first.
The card says you have not set up forecasting, and you know you have
Why: That card also stands in for “no deals have synced from this tool”. The wording is identical in both cases, and it never mentions the sync.
Fix: Check that deals have arrived before you change anything in your tool. Open the Executive Read on the same tool: it prints how many deals are in scope. With none there, the sync is what to fix, and your stage probabilities are beside the point. With deals there, the card is asking for a probability or forecast field on them, and its steps are the right ones.
Every stage row shows a blank in Pipeline says
Why: Your pipeline carries no configured probability on its stages, so there is nothing to hold against what happened.
Fix: Set a probability per stage in your tool, taking each figure from the Has been column on this same table. On Pipedrive, check the pipeline’s Deal probability toggle as well — a pipeline can hold probabilities with the weighting switched off.
There is no commit panel
Why: Either your workspace has no forecast category field, or fewer than 30 closed deals carried a commit-style value 14 days before they were decided.
Fix: Confirm the field exists and is set on open deals rather than at the close. Where it exists and is thin, widen the Created range: the 30 is counted inside the period you picked.
The commit rate looks fine and you know commits miss
Why: A commit set in the last fortnight before a close is not read. The value is taken as it stood 14 days out, so a category changed to Commit a week before signing never enters this figure.
Fix: Read the panel rather than the finding: it lists every category value with what its deals became. A Commit bucket that is small against your win count usually means the category is being set late.
The win rate here differs from the one on the Executive Read
Why: They answer different questions. This page counts closed deals with readable history that lived long enough to be forecast; the Executive Read counts every deal created in the range.
Fix: Compare the two denominators before the two percentages. Each screen prints its own, and Two screens show different numbers for the same thing covers the rest of these pairs.
A stage shows a win rate far above the whole pipeline’s
Why: Every closed deal that was ever in that stage counts towards it, including deals that passed straight through on their way to a win. A late stage therefore reads high by construction.
Fix: Read the ladder from the bottom up, not row by row. The gap worth acting on is between the configured probability and the “has been” figure on the same row, never between two rows.
Next steps
Related articles
Was this article helpful?