Why do commit, best-case, and pipeline forecasts require different closing velocity assumptions?

Three Forecasts, Three Definitions of "Closing Velocity"

The word "velocity" gets used loosely in sales operations, so the first step is to define exactly what each forecast means by it. Closing velocity here means the *probability-weighted conversion rate over a defined time horizon* — not just "will it close" but "will it close inside the window this forecast covers." That time-horizon distinction is what most teams miss, and it is precisely why the three assumptions cannot be identical.

Commit forecast — the bankable number. A commit is a rep's personal pledge: "I will close this, this quarter." The velocity assumption is high because the deals qualify on strict criteria — a confirmed close date inside the quarter, an identified economic buyer, a proposal or order form in the buyer's hands, and no open blockers the rep can name. Because those criteria pre-filter the population, the appropriate velocity is the historical win rate of your last one or two stages, typically 85–95%. The time window is short and fixed: the current quarter. A commit deal that "will close, but probably next quarter" does not belong in commit at all — its velocity *within this window* is effectively zero, even if its lifetime win probability is 90%.

Best-case forecast — the credible ceiling. Best-case is not "everything I have"; it is "everything that could plausibly close this quarter if momentum holds and nothing slips." It includes the commit set plus a disciplined slice of proposal- and evaluation-stage deals where there is real signal: multi-threaded buyer contact, a documented business case, and an active evaluation timeline. The velocity assumption drops to roughly 50–75% because these deals still carry unresolved risk — pricing, legal, competitive, or budget-timing. The window is still the current quarter, but the population is larger and less certain, so the blended conversion rate falls.

Pipeline forecast — the capacity number. Pipeline counts every open opportunity and applies each stage's historical conversion rate. Early-stage deals get weighted at 10–30%; mid-stage at 30–60%; late-stage at 70–90%. The velocity assumption is the *entire curve*, and the window stretches across the sales cycle — often two to four quarters. Pipeline is not trying to predict this quarter's revenue; it is measuring whether you have enough raw opportunity in the system to make future quarters possible given your normal conversion math. That is a fundamentally different question, and it demands a fundamentally different velocity model.

The trap is treating these as three views of the *same* deals at three confidence levels. They are not. Commit and best-case share population overlap but differ in window discipline; pipeline is a superset with an entirely different time horizon. Each forecast's velocity assumption is calibrated to *its own population and its own window* — change either, and the correct velocity changes with it.

Why a Single Velocity Assumption Breaks Every Forecast

It is tempting for a young sales org to pick one "close rate" — say, 40% — and apply it everywhere for simplicity. This breaks in both directions, and the breakage is instructive because it shows precisely why the three assumptions must diverge.

Apply pipeline velocity (low) to commit, and you under-forecast bankable revenue. Suppose you have $1.2M in genuine commit deals — signed order forms out, buyers confirming, close dates set — and you weight them at a blanket 40%. You would forecast $480K and tell the board you will land less than half of what is actually going to close. The first quarter you do this, you crush your own credibility from the *low* side: you land $1.1M against a $480K call, and the board learns your forecast is noise. Worse, you may under-hire, under-provision, or under-invest because your reported number understates reality.

Apply commit velocity (high) to pipeline, and you over-forecast wildly. Now weight your entire $2.5M pipeline — including cold discovery deals that historically close at 12% — at 90%. You would forecast $2.25M and walk into a board meeting promising nearly the full pipeline. When early-stage deals convert at their real rate, you miss by 60%+. This is the classic "hockey-stick pipeline that never materializes" failure, and it is the single fastest way to lose a CRO's job. The board stops trusting *any* number you give them, including the commit that was actually solid.

The mathematical core. Blended conversion is a weighted average, and the weights are the stage populations. If your populations are lumpy — a lot of early-stage volume, a thin late-stage — a single average velocity systematically misprices both ends. The only way to price each population correctly is to *segment by maturity and apply the maturity-appropriate velocity*, which is exactly what the three-forecast structure does. Commit isolates the high-velocity tail; pipeline captures the full distribution; best-case draws a principled line in between.

There is also a governance reason. A board needs three distinct decisions supported: (1) *cash and covenant* decisions ride on commit — this must be conservative and near-certain; (2) *stretch and incentive* decisions ride on best-case — this shows what's possible without being fantasy; (3) *investment and hiring* decisions ride on pipeline — this shows whether capacity exists to justify spend. Collapsing to one velocity collapses three decisions into one blurry number, and every one of those decisions gets worse.

The Psychology That Skews Each Forecast's Velocity

The reason velocity assumptions drift toward being *too optimistic* is not primarily mathematical — it is behavioral. Each forecast type is vulnerable to a different, well-documented cognitive bias, and a disciplined RevOps function builds specific counter-measures for each.

Commit and the escalation-of-commitment / planning-fallacy trap. By the time a rep commits a deal, they have invested weeks of demos, discovery, and relationship-building. That sunk investment triggers escalation of commitment — the tendency to over-value an outcome you have already poured effort into — and the planning fallacy, the well-established human tendency to underestimate how long the remaining steps will take. The practical effect: reps systematically compress the last-mile timeline. Legal review, procurement queues, security questionnaires, and signature routing routinely add two to six weeks that the rep did not model. The counter-measure is a *commit gate* with objective, verifiable criteria — order form delivered, mutual close plan signed, procurement contact named — rather than "I have a good feeling." When commit requires evidence instead of confidence, the velocity assumption you attach to it (85–95%) actually holds up.

Best-case and optimism bias. Best-case deals are exactly the ones where wishful thinking does the most damage, because they are close enough to feel real but far enough that the risks aren't yet surfaced. Reps imagine the win, and the imagining feels like evidence. The result is that best-case populations balloon with deals that "felt hot last week." The counter-measure is a *hard inclusion rule*: a deal only enters best-case if it has multi-threaded contact (more than one buyer-side stakeholder engaged), a documented reason to buy *now*, and an active next step on the calendar. Everything else stays in pipeline, weighted at its stage rate. This keeps best-case's velocity assumption (50–75%) honest instead of aspirational.

Pipeline and availability / confirmation bias. When a manager scans a large pipeline, the mind latches onto the memorable recent conversations and quietly ignores the statistical reality that most early-stage deals never close. Confirmation bias then filters the review toward evidence that the pipeline is healthy. The counter-measure here is the most mechanical: pipeline velocity must come from *historical stage-conversion data*, not from anyone's read of the deals. If your Discovery stage has converted at 14% over the last four quarters, Discovery deals get weighted at 14% — full stop, regardless of how good this quarter's discovery deals "feel."

The unifying discipline is calibration: every quarter, pull each rep's forecast calls from 90 days prior and compare them to actual outcomes. If a rep's commit deals landed at 70% against a 90% assumption, their personal commit velocity gets adjusted down, and you coach the gap. Calibration turns velocity assumptions from opinions into measured, self-correcting parameters — and it is the single highest-leverage practice separating forecasts that hold from forecasts that don't.

Stage Definitions Determine Whether Your Velocity Assumptions Mean Anything

You cannot set trustworthy velocity assumptions on top of untrustworthy stage definitions. This is the most underappreciated dependency in the entire discussion: the *quality of your stage definitions* sets a ceiling on how accurate any velocity assumption can possibly be.

Immature, subjective stages destroy velocity accuracy. Many organizations define stages by feeling — "Qualification" means the rep thinks it's qualified, "Negotiation" means a good conversation happened. Under those definitions, a single stage label spans wildly different realities. A deal marked "Negotiation" might mean legal has redlined the contract (2–4 weeks to close) or might mean the rep had one encouraging call about price (3–6 months, or never). When you apply one velocity assumption to that stage, you are averaging incompatible scenarios, and the average predicts neither. Commit, best-case, and pipeline all inherit this noise, and no amount of clever weighting fixes it.

Mature, behavior-based stages compress the variance. Objective stages tie each transition to a *verifiable buyer action*, not a rep impression:

• Qualified — the buyer has confirmed budget, decision authority, a defined need, and a timeline in a documented meeting (BANT or an equivalent framework), and those notes exist in the CRM.
• Proposal — a formal written proposal has been delivered, the buyer has confirmed receipt, and a review date is on the calendar.
• Negotiation — the buyer has provided written feedback on terms, and at least one negotiation session is scheduled.
• Commit — an order form or contract is in the buyer's hands with a mutually agreed close date and no open blockers.

When each stage has a narrow band of possible outcomes, the historical conversion rate for that stage becomes a meaningful, low-variance number — which is exactly what a velocity assumption needs to be. Teams that move from subjective to objective stage definitions typically see materially less variance in close-time *within* each stage, which is what makes the difference between forecasts that predict and forecasts that merely describe hope.

The practical audit. Before you tune any velocity number, audit what actually lives in each stage. If your "Commit" bucket contains deals still in verbal-agreement phase with no paper out, your commit velocity assumption should be dialed down 15–25% until the definition tightens — or better, those deals should be reclassified to best-case where they belong. The sequencing matters: fix stage definitions first, then set velocity assumptions. Doing it in the other order tunes parameters on top of noise.

Deal Size and Complexity Are Velocity Multipliers, Not Footnotes

Even with clean stages, a second factor forces velocity assumptions to differ: not every deal at the same stage moves at the same speed. Deal size and complexity are multipliers on time-to-close, and ignoring them is a common source of forecast misses — especially in the commit and best-case tiers where the time *window* is fixed and short.

The size effect is non-linear. Larger deals do not simply take proportionally longer; they take *disproportionately* longer. A $50K deal might close in 2–3 months while a $500K deal in the same company takes 6–12 months — roughly a 3–4× time increase for a 10× jump in value. The reason is structural: bigger deals pull in more stakeholders, trigger formal procurement, require security and legal review, and often need executive or board sign-off. For a commit forecast this is decisive. A large deal "in negotiation" may still carry four to eight weeks of procurement and legal friction, meaning its true velocity *inside the current quarter* is far lower than a small deal at the identical stage. Attaching the same commit velocity to both overstates the large deal's near-term conversion.

Complexity compounds size. Number of decision-makers, integration and implementation requirements, regulatory or compliance review, and competitive intensity each add time independent of dollar value. A one-stakeholder, no-integration deal might close 30 days from proposal; a five-plus-stakeholder deal with custom implementation and a compliance gate can run 180+ days from the same stage. Best-case forecasts for complex deals should therefore assume meaningfully longer timelines — and often should *not* count a complex deal as best-case-this-quarter at all, even when its stage label suggests it is close.

Illustrative velocity bands by tier (calibrate to your own data — these are directional, not universal):

• Small (<$25K): pipeline 1–3 months, best-case 2–6 weeks, commit 1–3 weeks.
• Mid-market ($25K–$100K): pipeline 3–6 months, best-case 1–3 months, commit 3–8 weeks.
• Enterprise ($100K+): pipeline 6–12 months, best-case 3–6 months, commit 6–12 weeks.

The weighted-pipeline distortion. Standard weighted pipeline (e.g., 10% at Discovery, 30% at Demo, 60% at Proposal) assumes uniform velocity across sizes. In reality large deals accumulate in later stages *because they move slowly*, so a flat weighting over-counts their near-term contribution while under-modeling their timeline. The fix is to *segment by deal tier* and apply tier-specific velocity: run a large-deal forecast track separately, assume enterprise commits take 2–3× longer than SMB commits, and consider a complexity score (1–5) that adjusts the assumed window proportionally. A simple CRM rule — e.g., a $200K deal with three-plus stakeholders auto-flags as "Complex Enterprise, 90-day commit window," while a $15K single-buyer deal defaults to a 21-day window — stops reps from stapling optimistic small-deal velocity onto large, slow-moving opportunities.

Building the Three-Layer Forecast: A Step-by-Step Method

Here is a concrete, repeatable process that operationalizes everything above. It produces three numbers from one dataset, each with its own correctly-calibrated velocity assumption.

Step 1 — Pull four quarters of closed-deal history and compute stage conversion rates. For each stage, calculate what percentage of deals that *entered* that stage eventually closed won, and the median time from that stage to close. Segment by deal tier (small / mid / enterprise) because, as covered above, velocity is tier-dependent. This history is the empirical backbone of every velocity assumption — you are replacing opinion with measured rates.

Step 2 — Define objective, evidence-based stage gates and enforce them. Nail down what verifiable buyer action is required to enter each stage, and audit current open deals against those gates. Reclassify anything sitting in a stage it doesn't qualify for. This is the step most teams skip, and skipping it silently corrupts everything downstream.

Step 3 — Build the pipeline forecast. Apply each stage's historical conversion rate (from Step 1) to the open deals in that stage, segmented by tier, over a two-to-four-quarter horizon. Sum the probability-weighted values. This is your capacity number. Do not adjust it for optimism — it is supposed to be the cold statistical view.

Step 4 — Build the best-case forecast. Start from proposal-stage-and-later deals that pass the hard inclusion rule (multi-threaded contact, documented reason to buy now, active next step). Apply mid-to-late blended velocity (roughly 50–75%) over the current-quarter window, adjusted for size and complexity so slow enterprise deals aren't force-fit into the quarter. Add the commit set. This is your credible ceiling.

Step 5 — Build the commit forecast. Include only deals that clear the commit gate (paper out, close date set, no open blockers, tier-appropriate window). Apply late-stage velocity (85–95%). This is your bankable floor.

Step 6 — Reconcile and sanity-check the spread. Commit < best-case < pipeline should always hold, and the *gaps* should be intelligible. If commit and best-case are nearly identical, best-case is too conservative or your commit gate is too loose. If pipeline dwarfs best-case by 5×, you have a lot of early-stage volume that won't help this quarter — a coverage signal, not a revenue signal.

Step 7 — Calibrate next quarter. After the quarter closes, compare each forecast to actuals and each rep's calls to their outcomes. Adjust velocity assumptions and re-coach the gaps. Over three to four cycles, this loop is what turns the whole system from guesswork into a measured instrument.

Worked example. Suppose after running the method you have Commit = $1.2M, Best-case = $1.8M, Pipeline = $2.5M. The board reads three clean signals: $1.2M is bankable (plan cash and covenants against it), $600K of additional upside is available if the qualified proposal-stage deals execute (structure incentives around it), and $1.3M of pipeline beyond commit exists to feed the next quarter or two (decide hiring and investment against it). One dataset, three velocity assumptions, three decisions — none of which a single blended number could have supported.

FAQ

What is the difference between commit, best-case, and pipeline forecasts?

Commit is the set of deals you are highly confident will close *this quarter*, gated on objective evidence (paper out, close date set, no blockers), and it uses a high velocity assumption of roughly 85–95%. Best-case is commit plus a disciplined slice of qualified proposal- and evaluation-stage deals that could realistically close this quarter, using a moderate 50–75% velocity. Pipeline is every open opportunity weighted by its stage's historical conversion rate across a two-to-four-quarter horizon. They differ in population, time window, and therefore in the velocity math each one uses.

Why can't I use the same closing velocity for all three forecasts?

Because each forecast covers a different population of deals over a different time window, and closing velocity is a property of deal maturity, not a constant. Applying pipeline's low velocity to commit under-forecasts bankable revenue and makes you look overly conservative; applying commit's high velocity to pipeline over-forecasts and produces the "hockey-stick pipeline that never lands" that destroys board trust. A single average systematically misprices both the high-certainty tail and the low-certainty bulk.

How do I determine the right closing velocity for each forecast?

Pull at least four quarters of closed-deal history and compute the actual win rate and time-to-close for each stage, segmented by deal size. Use late-stage rates (often 80–95%) for commit, mid-stage blended rates (roughly 50–75%) for best-case, and the full stage-conversion curve (10–30% early, rising to 70–90% late) for pipeline. Then recalibrate every quarter against actuals rather than trusting the original numbers indefinitely.

Does deal size change the velocity assumption even at the same stage?

Yes. Larger and more complex deals take disproportionately longer to close because they involve more stakeholders, procurement, and legal or compliance review. A large deal "in negotiation" can still carry weeks of procurement friction, so its near-term velocity inside the current quarter is lower than a small deal at the identical stage. Segment your forecast by deal tier and apply longer windows to enterprise and high-complexity deals rather than one uniform assumption.

What happens if my stage definitions are subjective?

Then your velocity assumptions are built on noise. If "Negotiation" can mean anything from "legal has redlined the contract" to "we had a nice call about price," the historical conversion rate for that stage averages incompatible scenarios and predicts neither. Fix stage definitions first — tie each transition to a verifiable buyer action — and only then tune velocity assumptions. Doing it in the reverse order tunes parameters on top of randomness.

How often should I revisit these velocity assumptions?

At least quarterly, and after any major change to your market, pricing, sales motion, or team. Run a calibration pass every quarter: compare each forecast tier to actual results and each rep's calls to their outcomes, then adjust the velocity assumptions and coach the gaps. Rely on your own historical data over generic industry averages, because your conversion curve reflects your specific product, buyers, and sales process.

Sources

• Salesforce — Sales forecasting methods and best practices: https://www.salesforce.com/resources/articles/sales-forecasting/
• HubSpot — Sales forecasting methods and how to build a forecast: https://blog.hubspot.com/sales/sales-forecasting
• Gong — Research and resources on deal execution and forecast accuracy: https://www.gong.io/resources/
• Harvard Business Review — Sales and forecasting management topic hub: https://hbr.org/topic/subject/sales-and-marketing
• Gartner — Sales leadership research, including forecasting and pipeline management: https://www.gartner.com/en/sales
• Forrester — B2B sales and revenue operations research: https://www.forrester.com/

Related on PULSE

• [What is the difference between commit, best-case, and upside forecasts?](/knowledge/q12728)
• [How do you tell if a deal stage is too early to commit to forecast (commit vs best-case vs pipeline)?](/knowledge/q236)
• [How do post-close analytics identify which forecast assumptions were right and which were wrong?](/knowledge/q308)
• [How should a CRO structure renewal forecasts differently from new-business pipeline to predict cash retention?](/knowledge/q1170)
• [How can RevOps in 2027 prevent AI from over-hyping pipeline and misleading forecasts?](/knowledge/q16498)