What is pipeline velocity?

What it means

Pipeline velocity compresses four separate sales metrics into one number with a unit: revenue per day. That unit is the whole reason the metric is worth computing. A win rate on its own cannot be traded against a cycle length, and an opportunity count cannot be traded against an average deal size. Once all four live in the same expression, they can be compared, and the question "what should we work on next quarter" has an arithmetic answer.

It is best understood as a throughput measure borrowed from manufacturing. A factory line has work in progress, a yield rate, a unit value and a cycle time, and its output per day is a function of all four. A sales pipeline is the same object with worse instrumentation. Velocity is the output rate of that line, and like any throughput measure it improves most when you attack the bottleneck rather than the input volume.

The metric is deliberately blunt. It uses averages, it assumes the current pipeline resembles the historical one, and it says nothing about any individual deal. That bluntness is a feature when it is used for direction-setting and a defect when it is used as a forecast.

The formula, written out

PV = (N x A x W) / L

• PV: pipeline velocity, in currency per day.
• N: the number of qualified open opportunities in the pipeline at the measurement point. "Qualified" must name a stage, and stale opportunities must be excluded.
• A: average deal value, computed over deals won in the trailing period, in the same segment as the opportunities you counted.
• W: win rate as a decimal, measured on deals that reached the same qualifying stage. 27% is 0.27.
• L: average sales cycle length in days, from the qualifying stage entry to close.

The numerator, N x A x W, is the risk-adjusted value of the open pipeline. Dividing by L spreads that value across the days it takes to realise. Multiply the result by the number of days in a period to get an expected contribution for that period, which is where the metric touches planning.

One consistency rule governs all four variables: they must describe the same population. If N counts every open deal but W is measured only on enterprise deals, the formula still produces a number, and the number is fiction.

A worked example, end to end

A B2B software team measures on the first day of the quarter. The pipeline holds 84 qualified open opportunities. Over the trailing 90 days, won deals averaged 6,400, the win rate from the qualified stage was 27%, and the average cycle from qualification to close was 46 days.

84 x 6,400 = 537,600 (total open pipeline value)

537,600 x 0.27 = 145,152 (risk-adjusted value)

145,152 / 46 = 3,155.48 per day

Over a 90-day quarter that is 3,155.48 x 90 = 283,993, which is the number to hold against the quarterly target. If the target is 340,000, the pipeline as it stands is roughly 56,000 short, and the four levers in the formula are the only places that gap can come from.

Now the sensitivity analysis, which is where the metric earns its keep. Improve each input by a realistic single-quarter amount and recompute:

• Eight more opportunities (84 to 92): 3,456 per day, +9.5%.
• Ten percent larger deals (6,400 to 7,040): 3,471 per day, +10.0%.
• Four more points of win rate (27% to 31%): 3,623 per day, +14.8%.
• Eight days off the cycle (46 to 38): 3,820 per day, +21.1%.

Cycle length wins, and it wins for a structural reason: it is the only variable in the denominator. Every other input scales velocity proportionally, while a reduction in L scales it more than proportionally. There is a second-order effect too, since reps who close in 38 days rather than 46 free capacity to start more deals, which raises N as well.

Three ways the number goes wrong

Counting zombie opportunities in N. Of the 84 open deals, 23 have had no inbound or outbound activity in 60 days. Their close dates have been pushed twice. Recomputing with N = 61: 61 x 6,400 x 0.27 / 46 = 2,291.55 per day, a 27.4% reduction, and a quarterly expectation of 206,240 instead of 283,993. The 77,753 difference is the cost of a pipeline hygiene problem, and it is the most common single reason a velocity number and a real quarter disagree. Define staleness by last activity timestamp, never by expected close date, because close dates are edited by the people being measured and activity timestamps are not.

Measuring the cycle only on won deals. This one is a definitional choice rather than an outright error, but it has to be declared. In the same dataset, 61 won deals averaged 46 days while 164 lost deals averaged 57 days, because a losing deal usually dies slowly. Averaged over all 225 closed deals the cycle is (61 x 46 + 164 x 57) / 225 = 54.0 days, which yields 2,688 per day instead of 3,155, a 15% difference from one unstated assumption. Use won-deal cycle length if you are asking "how fast does revenue arrive", use all-closed if you are asking "how long is a rep occupied", and put the choice in the chart title.

Blending segments into one number. Split the same 84 opportunities into 68 small-business deals (average 3,100, 30% win, 22-day cycle) and 16 enterprise deals (average 20,425, 14% win, 148-day cycle):

• SMB: 68 x 3,100 x 0.30 / 22 = 2,874.5 per day
• Enterprise: 16 x 20,425 x 0.14 / 148 = 309.1 per day

The two sum to 3,183.6 per day, which is within one percent of the blended 3,155. The total is fine and the composition is invisible: 90.3% of the velocity comes from the small-business pipeline, while the enterprise pipeline consumes a disproportionate share of rep hours for 9.7% of the output. A manager looking only at the blended number would work on "the" sales cycle without noticing there are two of them, one at 22 days and one at 148.

How velocity is actually derived from CRM data

Everything comes from the deal table plus its stage-transition log:

• N: count of deals where status = open, the current stage is at or past the qualifying stage, and the most recent activity timestamp is inside the staleness window.
• A: mean of amount over deals with status = won and closed_at inside the trailing window. Use the amount at close, not the amount at creation, or every deal that was created as a placeholder and sized later will drag the average toward zero.
• W: won deals divided by all closed deals that reached the qualifying stage. Deals still open are in neither side.
• L: mean of closed_at - stage_entered_at(qualifying stage).

The edge cases that bite:

• A deal that skips a stage. Deals do not walk politely through every stage. If a deal jumps from stage 2 to stage 4, there is no stage_entered_at row for stage 3. Any per-stage duration computed as entered(next) - entered(this) silently drops those deals from the denominator, and since skipped stages happen most often on fast deals, the surviving average is biased toward slow ones. Compute stage durations only over deals that have both timestamps, and report how many were excluded.
• Reopened deals. A deal closed lost in February and reopened in April has two closure events. Averaging over all closure rows counts it twice and shortens the apparent cycle. Decide once: either take the final closure per deal, or treat the reopen as a new deal with its own creation date.
• Amount changes mid-cycle. Deals are resized during negotiation. Store amount history, and be explicit about whether A reads the value at close or the current value on open deals. Mixing them makes pipeline value and average deal value disagree.
• Day boundaries and timezones. Cycle length in whole days depends on where midnight is. A workspace whose users are in Istanbul and whose database is in UTC will report cycle lengths that differ by one day on roughly an eighth of deals. Compute in one timezone and say which.
• Deals with no qualifying-stage entry. Deals created directly in a late stage, common for renewals and partner-sourced business, have no entry timestamp at all. Exclude them or backfill from created_at, but do not let them default to zero days.

Why it matters

Velocity is the only common sales metric that makes trade-offs visible. Every quarterly plan is really a choice about where to spend a limited amount of change, and without a single unit those choices get made on the basis of which team argues most persuasively. Once you can say that eight days off the cycle is worth more than eight more opportunities, the planning conversation is about evidence.

It is also an early-warning instrument. Bookings are a lagging indicator by exactly one sales cycle, so a pipeline that started degrading in January shows up in April's revenue. Velocity moves immediately, because it reads open pipeline rather than closed revenue. A velocity drop with a stable win rate points at pipeline generation; a velocity drop with a stable opportunity count points at the cycle or the win rate.

Common mistakes

• Recomputing it weekly. With a 46-day cycle, weekly velocity is mostly noise, and teams that react to noise make things worse.
• Using pipeline value instead of qualified count. Multiplying pipeline value by win rate and dividing by cycle length double-counts deal size if you also use average deal value.
• Letting reps see it as a target. Velocity has an obvious exploit: close small deals fast. If it becomes a quota input, the enterprise pipeline will quietly be abandoned.
• Ignoring seasonality. A 90-day trailing window that spans a holiday period reports a cycle length inflated by calendar rather than by performance.
• Never cleaning the pipeline. Every stale deal is a permanent upward bias, and the bias grows every month nobody closes anything out.

Related concepts

• Sales pipeline: the object velocity measures the throughput of.
• SQL: the qualifying gate that defines which opportunities count in N.
• MQL: the upstream volume that feeds the opportunity count.
• Lead routing: slow routing adds days to L before a rep has done anything.
• First response time: the first, and usually the cheapest, days to remove from the cycle.
• Conversion funnel: the stage-by-stage view behind the win rate.

How Pinlyx handles it

Pinlyx records a stage-transition row for every deal movement, including skips, so cycle length and per-stage duration can be computed from real entry timestamps rather than inferred from the stage order. Amounts keep their history, staleness is measured from the last real activity on the record rather than from the close date, and velocity can be broken out per pipeline so a self-serve motion and an enterprise motion never end up averaged into a single number that describes neither.