Pipeline coverage, adjusted for data you can trust
Coverage is a ratio of two numbers, and only one of them ever gets checked. This shows the figure your dashboard reports and the figure left once pipeline you cannot forecast on is removed.
- What this is
- Your coverage ratio against target, then the same ratio recalculated on the pipeline value that has both a usable close date and an owner — plus what the gap between the two is made of.
- Who it is for
- Anyone setting or defending a coverage number in a forecast review, and anyone whose dashboard says the pipeline is healthy while the quarter says otherwise.
Free, no email required, no sign-up. Anything you type into a tool on this page stays in your browser and is never sent anywhere. The visit itself is counted by Google Analytics, as on every page of this site.
On your dashboard
4.00×
Adjusted for pipeline you can forecast on
2.20×
Thin coverage
45% of the pipeline behind the headline number cannot be forecast on.
- 45% of open pipeline value sits on deals that fail at least one of the two tests — no close date you would forecast on, no owner, or both. It counts toward the headline ratio and toward nothing else.
- Closed-lost is not being used, so your win rate has no denominator and any conversion assumption behind this coverage target is unverifiable.
Nothing you type here is sent anywhere. The calculation runs in your browser and is not stored.
Why the headline number is usually wrong
Coverage is pipeline divided by target. The target is scrutinised heavily. The pipeline figure is taken at face value, because it comes out of the CRM and the CRM is the system of record.
But a deal with a close date stamped by a migration is not in your period — it is in whatever period the import happened to land in. A deal with no owner is in nobody's forecast and shows as unassigned in every per-rep report. Both still count toward the headline ratio, which is how a business arrives at 4× coverage and misses the quarter without anyone having lied.
The adjustment here is deliberately blunt: recalculate coverage on the pipeline value that survives both tests, and show both numbers side by side. The gap between them is the interesting part.
Getting honest inputs
Take the second number off one report rather than assembling it from parts. Filter open deals to those with an owner and a close date you would forecast on, and read the total value. It is tempting to take the percentage with an owner and the percentage with a good close date and multiply them, and it is wrong: that arithmetic is only correct if the two problems fall on different deals, and they do not. Neglected deals are neglected in every column at once, so multiplying charges the same deals twice and can halve a figure that was fine.
Use value rather than deal count for the same reason. Coverage is a ratio of money, and the deals that lost their close date to an import are rarely of average size.
The close-date judgement is the part that needs a person rather than a query. Sort open deals by close date and look for clusters — a batch sharing an identical timestamp came from an import, not from a rep’s assessment. Treat those as unusable regardless of how recent they look.
Closed-lost is a yes or no about practice rather than data. If deals that die are left open or quietly deleted, your win rate has no denominator, and the conversion assumption behind whatever coverage multiple you are targeting cannot be checked.
What this will not tell you
- It does not connect to HubSpot. You supply the numbers, which means the output is only as honest as your assessment of the close-date column.
- The adjustment is deliberately simple — it recalculates one ratio against the pipeline value that survives both tests. It is a sanity check on the headline figure, not a forecast model, and it will not tell you which deals to work.
- Coverage says nothing about whether the pipeline is winnable. Three times target of poorly qualified pipeline is worse than two times of real pipeline.
The work behind this
Questions people ask about this
What is a healthy pipeline coverage ratio?
Three to four times target is the usual guidance, and it assumes the pipeline behind it is real. Coverage is only meaningful if the deals counted have both a close date you would forecast on and an owner working them — otherwise you are multiplying a target by a number that describes your CRM hygiene rather than your pipeline.
Why adjust pipeline coverage for data quality?
Because coverage is a ratio of two numbers and only one of them is checked. A pipeline where half the open deals carry a close date stamped by a migration is not forecastable pipeline, however it totals. On one portal roughly 8,800 deals shared a close date set inside a single sixteen-second import window, which makes every trend and velocity measurement built on that field meaningless.
Where do I get these numbers in HubSpot?
One deal report, run twice. First filtered to open deals with a close date inside the period — that total is your open pipeline value. Then the same report with two more filters, Deal owner is known and the close dates you would actually forecast on — that total is the second number. Reading it off one report is the point: if you instead take the percentage with an owner and the percentage with a usable close date and multiply them, you double-count the deals that fail both, and neglected deals are almost always neglected in every column at once.
Why does closed-lost matter for coverage?
Coverage targets are derived from a conversion assumption, and conversion needs a denominator. If deals that die are left open or deleted rather than moved to closed-lost, your win rate is unverifiable and so is the coverage multiple you set against it.
Does this send my numbers anywhere?
No. The calculation runs entirely in your browser, nothing you type is transmitted or stored, and there is no email gate. The page visit itself is counted by Google Analytics, as on every page of this site.
If the adjusted number is a long way below the headline, the problem is not forecasting — it is what the CRM is allowed to record. That is what an audit is for.
RevOps Diagnostic Audit