Counting blocked pipeline once: why per-request ARR double counts
How much pipeline is blocked by missing features?
Add up the deal behind each feature request and one deal shows up three times. How to count blocked pipeline so each deal counts once.
The number that is too big
Ask for blocked pipeline and the usual answer is a spreadsheet of feature requests, each carrying the value of every deal that asked for it. Sum the column and a deal is counted once for every request it carries.
A deal that waits on three features appears three times. The total looks alarming, and it is wrong.
One deal, three promises
In the sample ledger, Northwind Freight's platform deal is worth $96,000, and three promises block it. Count per request and that deal adds $288,000. Count per deal and it adds $96,000, which is what Northwind would sign for.
Only blocking promises carry money
A promise can be attached to a deal without blocking it. Britelane's $12,000 seats deal has C-097, Audit log export, attached, but nobody marked it as blocking, so the $12,000 stays out of the total.
Deals read from mail count only after a person confirms them. The sample's $50,000 Vantage Labs deal for an EU team was read from a thread and nobody has confirmed it, so it stays out too.
The honest total
Count each open deal once, and only where a blocking promise blocks it. The sample ledger comes to $182,000 across four deals: Acme Health $40,000, Northwind Freight $96,000, Vantage Labs $28,000 and Corvid Analytics $18,000.
Every total in CommitOps sums the same way, so the ledger, Gaps and the Monday review agree. A row still shows every open deal its promise touches, for reading. Only the totals count once. How to mark a promise as blocking is in Blocking deals.
Every company, person and figure in the examples belongs to the invented demo company in the sample ledger.