Pipeline Velocity Has Four Levers and Ops Only Owns One of Them

A VP once asked my team to lift pipeline velocity 20% by quarter-end, so reps did the obvious thing: they created opportunities. About 30% more of them in three weeks. The velocity tile on the dashboard jumped that same afternoon, everyone clapped, and the number was a lie the instant it printed. Bookings did not move for a full quarter, win rate sagged from 24% to 20% as the junk aged, and by the time the new opps reached a decision the cycle had stretched from 75 days to 85. We had moved the one input that recalculates instantly and left the two that actually convert to revenue untouched.

That is the trap in pipeline velocity: it is the most complete metric in the stack and the easiest to game, because three of its four levers show up on the dashboard the moment you touch them and the fourth takes a full sales cycle to tell the truth. The formula is honest. The way people read it is not.

The formula, then the part everyone skips

Pipeline velocity is dollars of pipeline that convert to revenue per day. The standard form:

velocity = (# qualified opps × win rate × average deal size) ÷ sales cycle length

Put in the numbers from a real mid-market motion: 200 qualified open opps, a 24% win rate, a $45k average deal, a 75-day cycle. That is 200 × 0.24 × $45,000, which is $2.16M of expected won revenue, divided across 75 days. The engine is throwing off about $28,800 of closed revenue per day. Multiply by the days in a quarter and you have a bookings forecast that came from the shape of the funnel rather than from rep commit optimism.

Operate it yourself. Move any one slider and watch the daily number recompute.

Here is the claim most velocity write-ups get wrong. They rank the levers by “impact” as if some are stronger than others. On pure calculus they are almost identical. Velocity is a product divided by a term, so a 20% improvement in the opp count, the win rate, or the deal size each multiplies the result by 1.20. Same lift, every time. Elasticity of one. The three numerator levers are interchangeable on paper, and no amount of dashboard color changes that.

The cycle length is the only lever that behaves differently in the math, and it behaves better. Because it sits in the denominator, cutting it by 20% does not multiply velocity by 0.80. It divides by 0.80, which is a multiply by 1.25. A 20% cut to the cycle beats a 20% lift to any numerator lever, and the gap widens the harder you push. That reciprocal is the first real reason cycle length is the lever to reach for, and it is pure arithmetic, not opinion.

Why “add more opps” is the lever that lies

Toggle that chart to “In the wild” and the story inverts. Add 20% more opportunities the lazy way and velocity does not climb 20%. It falls. Here is the arithmetic behind the second bar: those 40 extra opps were not held to the same qualification bar, so the blended win rate drops from 24% to 20%, and the weaker deals sit longer, dragging the cycle from 75 to 85 days. Run it: 240 × 0.20 × $45,000 ÷ 85 comes out near $25,400 a day, which is 12% below where you started. The dashboard showed a win the afternoon the opps were created and hid the loss that took a quarter to surface.

Two things make the opp-count lever the most dangerous of the four.

The first is a lag the formula pretends does not exist. The # qualified opps term is a stock of deals already in flight. Every deal in it has been aging toward a close date. A brand-new opp created today is not the same asset as one that entered last month, but the formula counts them at par. So when you inflate the numerator with fresh pipeline, the velocity tile jumps instantly while the actual revenue that opp can produce is a full cycle away. On a 75-day motion you are booking a number today against work that pays out in March. The tile and the bank account disagree for one whole cycle.

The second is coupling. The four levers are not independent variables you can turn like knobs on a mixing board. Volume added without a qualification gate lowers win rate and lengthens cycle at the same time, because junk deals fail slowly. Push average deal size by chasing larger buyers and the cycle stretches and the win rate falls, because enterprise deals are harder and slower. The only lever that tends to improve its neighbors when you pull it correctly is the cycle, and that is the second real reason to reach for it.

Cutting the cycle does something the formula cannot show

The reciprocal lift is only half of what a shorter cycle buys you. The formula treats cycle length as a divisor and stops there. It misses the capacity multiplier sitting one level up.

A rep who runs a 75-day cycle can start roughly five deal-cycles a year in a given slot. Cut the cycle to 60 days and that same slot runs six. That is 20% more shots on goal from the identical headcount, and it never appears in the velocity equation because the equation holds the opp count fixed. So a cycle cut pays twice: once through the reciprocal in the denominator, and again through throughput that lets the numerator grow without hiring. No other lever gives you the second payment. Raising win rate does not create more selling slots. Raising deal size usually consumes more of them.

This is why I stopped treating the four levers as equals and started treating cycle length as the lever ops actually owns. Win rate is mostly a function of talent, product, and qualification discipline, which are sales and enablement problems. Deal size is a packaging and segmentation problem that lives with pricing and marketing. Opp count is a demand-gen problem. Cycle length is the one lever that moves with configuration: stage exit criteria, dead-deal removal, routing latency, approval turnaround, and the fields that force a deal to prove it deserves to advance. Every one of those is a thing ops builds, not a thing ops asks a rep to try harder at.

Pull the four inputs before you argue about them

Most velocity debates run on vibes because nobody has the four numbers in front of them. Get them from the CRM first. The rates and the deal size come from the last 365 days of closed opportunities; strip renewals so you are measuring the new-business engine, not the book auto-renewing.

SELECT IsWon,
       COUNT(Id)   deals,
       AVG(Amount) avg_amount
FROM Opportunity
WHERE IsClosed = true
  AND CloseDate = LAST_N_DAYS:365
  AND Type != 'Renewal'
GROUP BY IsWon

That gives you win rate (won deals divided by total closed) and average deal size (the avg_amount on the won row). SOQL cannot subtract two dates in an aggregate, so cycle length needs the raw dates exported and differenced in whatever you use downstream. Pull won deals with both timestamps and take the median of CloseDate minus CreatedDate; the median, because a couple of 400-day monsters will drag the mean and lie to you.

SELECT Id, CreatedDate, CloseDate, Amount
FROM Opportunity
WHERE IsWon = true
  AND CloseDate = LAST_N_DAYS:365
  AND Type != 'Renewal'
ORDER BY CloseDate DESC

The numerator stock is separate: it is open, qualified pipeline as it stands right now, not a trailing count. Define “qualified” as whatever your stage model calls past the top, and count it.

SELECT COUNT(Id) open_qualified
FROM Opportunity
WHERE IsClosed = false
  AND StageName NOT IN ('Prospecting', 'Discovery')

Now you have all four, and you can compute velocity per segment. Do it per segment, always. A blended company velocity averages a 30-day SMB motion against a 180-day enterprise motion and describes neither, the same way a blended coverage ratio hides the reps who are actually starving. If you only remember one modeling rule from this piece, it is that velocity is a segment-level metric that lies the moment you roll it up.

The one number to put next to velocity

Reporting velocity alone repeats the original mistake, because a single number cannot show which lever moved it. Put a decomposition next to it. When velocity changes week over week, show the reader which of the four inputs did the work: opp count up 8%, win rate flat, deal size flat, cycle up 4 days. That instantly tells you the velocity “gain” was volume, not health, and volume that will cost you a quarter later when it fails to convert.

The decomposition also settles the recurring argument about whether a velocity dip is a problem. A dip driven by a longer cycle is an operations problem you can fix this quarter with exit criteria and dead-deal cleanup. A dip driven by a falling win rate is a sales-effectiveness problem you cannot config your way out of. A dip driven by shrinking deal size is a packaging or segment-mix problem for pricing. Same symptom on the tile, three different owners, and the decomposition is what routes the fix to the right desk instead of dumping it all on “the funnel.”

What I would build Monday

You do not need a velocity program. You need the four inputs stored once, a segment split, and the discipline to reach for the cycle lever instead of the opp-count lever every time the number is soft.

The velocity formula is not the problem. It is the cleanest single expression of a GTM engine anyone has written down, and I would rather manage on it than on any coverage ratio. The problem is that it invites you to pull the loudest lever, the one that redraws the dashboard before it redraws the bank account. Ops does not own most of the levers in that equation. It owns the cycle, and the cycle is the one worth owning, because cutting it is the only move that lifts the number in the math and buys you capacity the math cannot see. Pull that lever, decompose the rest, and let the people who own win rate and deal size answer for those on their own line.