Benchmark · 10 min read
Why the 3x pipeline coverage rule breaks down, and what to check instead
The 3x pipeline coverage rule only works if every deal in the pipeline is equally likely to close, which it never is. Here is the stage weighted check that replaces it, built on the same exit criteria audit behind our Revenue Forecast Accuracy Handbook.
Key takeaways
- 3x coverage assumes a 33% win rate, applied evenly. Few pipelines convert at one rate across every stage, segment and rep, so the multiplier is already wrong before any data goes stale.
- The real maths is 1 divided by win rate, not a fixed constant. Salesforce's own sales operations blog makes the same point: a 25% win rate needs roughly 4x coverage, not 3x, and a 20% win rate needs roughly 5x.
- A deal's stage label is only as reliable as the exit criteria behind it. The weekly update rate diagnostic from our Revenue Forecast Accuracy Handbook is the cheapest check for whether a stage was earned or just assumed.
- Stage weighted coverage discounts stale deals before they inflate the number. A deal that has not moved in two or more review cycles should count at a fraction of its stage weight, never its full face value.
- A coverage number that keeps climbing is not automatically good news. In our own engagements, a ratio that drifts well past what a team's own win rate implies is usually loose qualification dressed up as safety margin.
What's in this guide
Why does the 3x pipeline coverage rule stop working?
Because it assumes one win rate applies evenly to every deal in the pipeline, when win rate actually varies by stage, segment and how strictly exit criteria were enforced.
The 3x figure did not come from a study of your pipeline. It came from working backwards through a single assumption: if a third of qualified opportunities close, you need three times the target in the pipeline to expect to hit it. That is a reasonable starting point for a business with one product, one segment and one sales motion. Almost nobody fits that description.
Once a team sells into more than one segment, runs more than one deal size, or simply has stage exit criteria that one manager enforces more strictly than another, a flat multiplier stops describing anything real. Why most CRMs become graveyards covers the mechanism: a field that exists in the CRM is not the same as a field anyone actually checks before a deal advances. Pipeline coverage computed on top of that data inherits every one of those gaps, then presents them as a single clean ratio.
The result is a number that feels precise and is not. A board asks for 3x coverage, gets a report that says 3.2x, and reads that as healthy. Nobody in the room can see that a third of the deals inside that figure have not had a qualifying fact added to them in six weeks. The forecast you can defend names this pattern directly: a pipeline that looks identical stage by stage can be in two completely different states of health.
What is the maths behind a coverage target, really?
Required coverage is one divided by your own win rate, so a 20% win rate needs roughly 5x coverage and a 33% win rate needs roughly 3x, not the other way round.
Salesforce's own sales operations blog states the relationship plainly: the 3x figure only holds when a team's win rate is exactly 33% and its sales cycle is exactly a year. Move either number and the required ratio moves with it. A team closing 25% of its qualified opportunities needs roughly 4x coverage. A team closing 20% needs roughly 5x. A team with a six month cycle instead of a twelve month one needs a different number again, because coverage is really a statement about how much pipeline has to exist today to survive the deals that will not close this period.
None of this is exotic. It is the same formula restated for a team's own numbers instead of borrowed from somewhere else. The reason 3x survives as a default anyway is that most teams do not trust their own win rate enough to use it, which is itself a forecasting problem rather than a coverage problem. Gartner's own research on sales forecasting found that fewer than half of sales leaders have high confidence in their organisation's forecast accuracy, which is exactly the condition that makes a borrowed heuristic more comfortable than a calculated one.
That is the first thing to fix, and it is covered in full in the Revenue Forecast Accuracy Handbook: a forecast nobody trusts produces a win rate nobody trusts, and a coverage target built on top of it is a precise looking number resting on a guess.
What does a single coverage multiplier ignore?
It ignores that a deal's stage is a claim rather than a fact, and that claim is only as good as whether the exit criterion behind it was actually enforced before the deal advanced.
A flat multiplier treats every deal sitting in a stage as equally likely to behave like every other deal in that stage. That assumption fails for the same reason the forecast and the pipeline review disagree in the first place. Two managers can run the same five stages with the same written exit criteria, and one holds the line until a buyer has confirmed budget in writing while the other lets a deal advance on a good call. The stage field looks identical in both cases. The underlying likelihood of closing does not.
How to score a revenue signal and the full taxonomy in the Revenue Signal Field Manual make the related point for forecasting generally: evidence should move a deal between categories you already trust, never invent a new one. Coverage needs the same discipline. A deal does not deserve full stage weight just because nobody has moved it out of the stage yet.
What is a stage weighted coverage check?
It multiplies each open deal's value by a conversion weight earned from your own enforcement history, then discounts that weight further the longer a deal has gone quiet.
Instead of applying one multiplier to the whole pipeline, weight each stage by the conversion rate it has actually produced over the last two closed quarters, the same window used for the exit criteria audit, then discount any deal that has gone quiet since its stage last changed. Say a pipeline looks like this part way through a quarter:
| Stage | Face value | Stage weight (last 2 quarters) | Weeks since last update | Weighted value |
|---|---|---|---|---|
| Qualified | £400k | 0.15 | 1 | £60k |
| Proposal | £250k | 0.35 | 2 | £87.5k |
| Proposal (stale) | £150k | 0.35 | 7 | £26k, discounted for staleness |
| Commit | £200k | 0.70 | 1 | £140k |
The face value of that pipeline is £1m. The weighted value is a little over £313k. Required coverage against a target is then calculated against the weighted figure, not the face value, which is the entire point: a single £150k deal sitting untouched for seven weeks in Proposal was contributing its full face value to the old 3x calculation and almost nothing to the real one.
The staleness discount itself can be simple. A deal untouched for one full review cycle keeps its stage weight. Two cycles halves it. Three or more drops it close to zero until something changes, which mirrors the omitted category already defined in the Revenue Forecast Accuracy Handbook's forecast table.
How do you run this check every quarter?
Pull the same two closed quarters used for the exit criteria audit, score each stage's real conversion rate, apply the weekly update rate as a freshness discount, then recompute coverage against your own win rate.
The build order matters more than any single number in it, because each step depends on the one before it being honest first.
- Pull the last two closed quarters. The same window used for the exit criteria audit in the Revenue Forecast Accuracy Handbook, so the two checks stay consistent with each other.
- Score each stage's real conversion rate. Not the rate written in a sales methodology deck, the rate your own closed deals actually produced stage by stage.
- Run the weekly update rate check. The share of open opportunities with a stage, amount or close date change in the last seven days, split by team, exactly as described in the handbook.
- Apply a staleness discount by review cycle. A deal untouched for one cycle keeps its weight, two cycles halves it, three or more drops it near zero.
- Recompute required coverage from your own win rate. One divided by win rate, adjusted for sales cycle length, never borrowed from a generic default.
Run it every quarter, not only after a forecast miss. The value of the check is catching the gap between face value and weighted value while there is still a quarter left to close it, not explaining the gap after the fact.
Can too much pipeline coverage be a bad sign?
Yes. When required coverage runs far above what a team's own win rate implies, it usually means deals are entering the pipeline under loose qualification, not that demand is unusually strong.
A rising coverage number is often read as a growth story. In our own engagements, it is more often a qualification story. If the stage weighted check above shows a win rate implying 4x coverage but the raw pipeline is sitting at 7x or 8x, the gap is rarely extra safety margin. It is usually unqualified volume that a generous entry criterion let into the pipeline in the first place, inflating the denominator everyone is using to feel safe.
The bowtie: why acquisition is half the story makes a related point about the acquisition side of a revenue engine: volume that never had a realistic path to closing is not pipeline, it is noise wearing pipeline's clothes. The stage weighted check catches this earlier than a quarterly miss does, because loosely qualified deals tend to produce exactly the stale, unmoved stage history the freshness discount is built to penalise.
Frequently asked questions
What is a healthy pipeline coverage ratio?
There is no single healthy number, because the right ratio is one divided by a team's own win rate, adjusted for sales cycle length. A 25% win rate implies roughly 4x coverage and a 20% win rate implies roughly 5x, so quoting one fixed multiplier for every team is already the wrong question.
Why does the 3x pipeline coverage rule assume a 33% win rate?
Because 3x is simply 1 divided by 0.33. Salesforce's own sales operations blog sets out the same relationship: the 3x figure only holds exactly when win rate is 33% and the sales cycle is a year, and moves as soon as either number does.
What is a stage weighted coverage check?
It replaces a single multiplier applied to total pipeline value with a calculation that weights each open deal by the real conversion rate its stage has produced over recent closed quarters, then discounts that weight further the longer the deal has gone without a genuine update.
Should pipeline coverage targets differ by segment?
Yes. Different segments carry different win rates and sales cycle lengths, and both terms sit inside the same formula, so an enterprise segment with a longer cycle and a lower win rate needs a different coverage target to a transactional segment with a shorter one, not the same ratio applied across both.
What does unusually high required coverage usually mean?
In our own engagements, a ratio that drifts well past what a team's own win rate implies is more often a sign of loose entry qualification than strong demand. Deals that never had a realistic path to closing inflate the pipeline total without adding anything that will actually convert.
Cited and further reading
- Pipeline coverage · Salesforce
- Gartner Says Less Than 50% of Sales Leaders and Sellers Have High Confidence in Forecasting Accuracy · Gartner, 12 February 2020
- Pipeline Health Management: A Chief Sales Officer's Insurance Plan for Predictable and Consistent Results · Forrester
- H1 2024 B2B Sales Benchmarks · Ebsta, July 2024
Want to run a Revenue Engine Diagnosis on your business?
It's the first call we ever do. No pitch. The output is a written diagnosis you keep, even if we never work together.
Select a time →