How do you forecast revenue in a usage-based pricing model in 2027?

The quarter that taught a RevOps team the difference

Picture a mid-market data platform selling on consumption. Sixty-two enterprise accounts, all on annual commitments, all billed by compute-hour and rows processed. Sales closed a strong Q1: eight new logos, one of them a seven-figure annual commitment. The board deck showed bookings up sharply and the forecast for Q2 followed the bookings line, because that was the only line the CRM knew how to draw. Salesforce had opportunity amounts, close dates, and stages. It had nothing that described what any of those customers were actually going to run.

Q2 landed twenty-something percent under the forecast, and the post-mortem was uncomfortable because nothing had gone wrong in sales. Nobody churned. Nobody renegotiated. The seven-figure logo signed in March did not begin production workloads until late June — they spent the intervening eleven weeks on security review, a data migration, and an internal pilot that consumed roughly the compute of a single mid-tier account. Meanwhile four existing customers had quietly shifted a batch of nightly jobs to a cheaper internal process and cut their consumption by a third, and because those accounts were mid-commitment, nothing in the CRM changed at all. No stage moved. No renewal date approached. No rep logged a note. The revenue simply did not show up.

That is the shape of the problem, and it is worth sitting with because it explains why the fix is structural rather than a matter of better rep discipline. In seat-based SaaS, the gap between a signed contract and recognized revenue is small and predictable: you sign 200 seats, you invoice 200 seats, you recognize ratably, and the only real risk is a renewal twelve months out that you can see coming. In consumption, the gap between the contract and the revenue is the customer's entire engineering roadmap — their migration timelines, their traffic seasonality, their architecture decisions, their cost-optimization sprints. None of that lives in a sales system, and none of it is visible to the person who has been asked to produce the forecast.

The team's diagnosis was correct and worth generalizing: their forecast was measuring the wrong event. A closed-won deal is the moment a customer acquires the *right* to consume. Revenue is the moment they consume. Between those two events sits a lag that can run from days to two full quarters, and a variance that no pipeline-stage weighting will ever capture. Once you accept that, the rebuild is obvious in outline even if it is a lot of work in practice — you stop forecasting the sales event and start forecasting the consumption event, which means the primary data source shifts from the CRM to the product.

The broader pattern shows up anywhere revenue is metered rather than subscribed. Cloud infrastructure has lived with it for fifteen years. Payments companies forecast off transaction volume, not merchant count. Telecom and CPaaS forecast off message and minute volume. The AI wave — products billed by tokens, inference calls, agent runs, or GPU-seconds — has pulled a large number of previously seat-based companies into exactly this problem in a very short window, often with a RevOps function that was built entirely around a bookings-to-ARR pipeline. Utilities have been doing metered forecasting for a century and are, unglamorously, a better mental model for this than most SaaS benchmarks.

How the mechanism actually works

The working model is a three-layer bottoms-up build, aggregated per account and then rolled up. Each layer has a different driver, a different volatility profile, and a different owner, which is precisely why collapsing them into one blended number destroys the information you need.

Layer one: committed drawdown. For every account with a committed minimum, you are not forecasting *whether* the commitment converts to revenue — under most consumption contracts, unused commitment is either forfeited or partially rolled, so the contractual floor is close to certain over the full term. What you are forecasting is *when* it converts, which determines the period each dollar lands in. The mechanism is a burn schedule: contracted commitment, elapsed contract months, consumed-to-date, implied remaining monthly run rate. An account nine months into a twelve-month commitment that has consumed 55% of it will either accelerate sharply, negotiate a rollover, or leave money on the table — and each of those outcomes puts revenue in a different quarter.

Layer two: on-demand above commit. This is the volatile layer and the one that generates both your upside and your misses. It is driven by the customer's own workload growth, and the only honest way to forecast it is from the account's recent consumption trajectory, adjusted for known events — a product launch you have been told about, a seasonal peak you have observed in prior years, a migration with a date attached. Trailing-window trend extrapolation is the base method; the judgment layer is knowing which accounts have a specific catalyst that makes the trend wrong.

Layer three: new-account ramp. Newly signed accounts have no usage history, so they cannot be trend-forecast. They must be cohort-forecast: what did structurally similar accounts consume in months one, two, three? Segment those cohorts by something that actually predicts ramp speed — implementation complexity, whether the customer is migrating an existing workload or building something new, and deal size. A customer moving an existing production pipeline ramps quickly because the workload already exists. A customer building something new ramps on their engineering timeline, which is nearly always slower than the account executive believes.

The data plumbing under this is where RevOps actually earns its keep, and it is less exotic than vendor marketing suggests. You need consumption events tagged with an account identifier that matches your CRM account ID — this sounds trivial and is routinely the single hardest part, because product engineering instrumented usage for operational monitoring, not for revenue attribution, and the identifiers do not line up. You need those events landing in a warehouse alongside contract terms and billing records. And you need the joined result to be queryable by finance without a ticket to the data team, because a forecast that requires an engineer to refresh is a forecast that gets refreshed late.

The tooling categories are stable enough to name: a warehouse (Snowflake, BigQuery, Databricks) as the join point; a metering and billing layer (Metronome, Orb, m3ter, or Stripe's usage-based billing) that owns the authoritative consumed-and-remaining-commit numbers; reverse ETL (Hightouch, Census) if you want usage aggregates visible inside the CRM where CS and sales already work; product analytics (Amplitude, Mixpanel, or a homegrown event pipeline) for the behavioral leading indicators; and a forecasting surface, which can be a BI model or a purpose-built revenue tool. Clari and BoostUp have both moved toward consumption views. Pocus and Endgame sit in the product-led-signal category and surface account usage health to go-to-market teams. What matters is not which vendors you pick but that the metering system and the forecast agree on what "consumed" means — a surprising number of forecast disputes turn out to be definitional arguments about whether a metric is measured at request time, at completion, or at invoice.

One structural warning: do not let the billing system and the analytics pipeline compute usage independently. Pick one as authoritative for revenue — almost always the billing platform, because that is what the customer gets invoiced against — and treat the analytics pipeline as the leading-indicator and diagnostic layer. Two systems producing two slightly different usage numbers will consume more meeting hours than any forecasting problem you are trying to solve.

Real numbers, ranges, and benchmarks

Be careful with benchmarks in this space; consumption behavior varies enormously by product category, and a number that is healthy for a data warehouse is alarming for a messaging API. Use the following as diagnostic thresholds you calibrate against your own history, not as targets.

Commit burn rate is the workhorse metric: consumed-to-date divided by committed amount, compared against elapsed fraction of the term. The ratio of those two is what you watch. An account at month six of twelve that has burned roughly half its commitment is tracking to plan. An account at month six that has burned 75–80% is an expansion conversation you should be having now, not at renewal — they will exhaust the commitment early and either buy more or land on on-demand rates, and how that conversation goes determines whether you capture the expansion or hand them a surprise invoice that damages the renewal. An account at month six under 30% is a renewal risk that will present as a downgrade request, and the time to intervene is immediately, not in month eleven.

Ramp curves for new accounts are the most useful thing you can build from your own data and the least transferable from anyone else's. Pull every account that signed in the last eight quarters, normalize their consumption to percentage-of-eventual-steady-state by month since contract start, and segment. You will typically find two or three distinct curve shapes: fast migrators who hit meaningful consumption within the first month or two, and greenfield builders whose consumption stays near zero for a full quarter and then steps up sharply when their project ships. Forecasting both with a single blended average is a reliable way to be wrong in both directions simultaneously. Once you have the curves, a newly signed account gets forecast by curve assignment, and the account executive's job at handoff is to tell you which curve — a question they can usually answer accurately because they know whether the customer is migrating or building.

Trailing-window trend for on-demand. A trailing 90-day window with more weight on recent weeks is a reasonable default for products with steady workloads; shorten it toward 30 days for products where customers change behavior fast, lengthen it toward 180 for infrastructure with long, stable production workloads. Whatever window you pick, backtest it: run the model on last year's data and measure how far off it was, month by month. That backtest gives you the confidence interval you should be publishing, and it is far more credible to a CFO than an asserted range.

Concentration. Consumption businesses are usually more concentrated than their seat-based equivalents, because the same customer count spans an enormous range of workload sizes. It is common for a small fraction of accounts to drive the majority of consumption revenue. Measure yours precisely, because it determines your entire operating cadence: if fifteen accounts drive most of the number, those fifteen get individually reviewed by a human every week and the rest get a statistical model. Do not spend equal forecasting effort on accounts with unequal revenue.

Net revenue retention functions differently here and is worth calling out as an adjacent metric that changes meaning under consumption pricing. In seat-based SaaS, NRR moves in discrete steps when someone signs an expansion order form. In consumption, NRR moves continuously and silently, which makes it a much better real-time health signal — but also means a bad month shows up in NRR immediately rather than at renewal. Track it monthly on a trailing-twelve basis and treat sharp movement as a forecast input, not just a board metric.

Variance decomposition. The single most valuable number after a quarter closes is not the total miss — it is the miss broken down by layer. Was the drawdown layer off, meaning existing customers consumed their commitments differently than modeled? Was the on-demand layer off, meaning workloads grew or shrank unexpectedly? Was the ramp layer off, meaning new accounts started slower or faster than the cohort curve predicted? Each points at a different owner and a different fix. Teams that decompose variance improve their forecast accuracy quarter over quarter; teams that only track the headline miss argue about it and change nothing.

Trade-offs, alternatives, and where each approach breaks

There is no single correct forecasting method here, and the honest framing is a set of trade-offs between accuracy, effort, and explainability.

Bottoms-up per-account modeling is the most accurate and the most expensive. It requires clean account-level usage data, someone to maintain the model, and enough accounts-under-review discipline that the human adjustments actually reflect knowledge rather than optimism. It breaks when you have thousands of small accounts, because per-account review does not scale and the effort per dollar collapses.

Top-down cohort or statistical modeling — take last period's revenue, apply retention and expansion rates by cohort, add new-business ramp — is cheap, scales infinitely, and is remarkably good in aggregate for long-tail businesses. It breaks precisely where concentration is high, because a single large account changing behavior moves the number more than any cohort average can capture. The practical answer for most companies is not to choose: run bottoms-up on the concentrated head, top-down on the tail, and sum them.

Rep-submitted forecast deserves a specific caution. Sales reps have genuine, valuable information — they know about the customer's upcoming launch, the procurement freeze, the competing vendor evaluation. What they do not have is visibility into aggregate consumption behavior, and asking them to submit a consumption number produces a number anchored on their quota rather than on usage. Use reps as an input channel for catalysts and known events, not as the forecast source. That is a real change to how the forecast meeting runs and it is worth being explicit about it, because reps whose forecast is overridden by a usage model will reasonably ask what their submitted number is for.

Single point estimate versus range. A consumption forecast delivered as one number implies a precision the underlying process does not have, and it will be wrong every quarter, which erodes trust in the whole function. Delivering a committed floor plus a banded on-demand range is more honest and, counterintuitively, more useful to finance, because it tells them which portion to plan against and which portion to treat as upside. The cost is organizational: some boards and some CFOs want one number and will push back. The conversation is easier if you bring the backtest showing what your historical error actually was.

Contract structure as a forecasting lever. This is the adjacent angle most teams underuse. How you price and contract directly determines how forecastable you are. Larger committed minimums with rollover provisions make the floor higher and the forecast steadier, at the cost of longer sales cycles and more discounting pressure. Pure pay-as-you-go maximizes adoption and minimizes forecastability. Hybrid structures — a platform fee plus consumption, or a seat component plus metered overage — split the difference and are increasingly common for exactly this reason. If leadership wants a more predictable forecast, part of the answer lives in the pricing committee, not in the forecasting model. That is a conversation RevOps should be initiating rather than absorbing.

Common pitfalls and how to avoid them

Recognizing the commitment on day one. The most common and most damaging error. A signed annual commitment is not twelve months of guaranteed monthly revenue starting immediately; it is a floor over a term with an unknown consumption shape underneath. Model the shape. If your finance team is recognizing ratably while your customers are consuming lumpily, your recognized revenue and your cash and your usage will tell three different stories and every close will be a reconciliation exercise.

Account identifiers that do not join. Product events keyed on an internal workspace ID, billing keyed on a customer ID, CRM keyed on an account ID, and no maintained mapping between them — particularly across parent-child structures where one enterprise customer has fourteen workspaces under three subsidiaries. Fix this first and fix it properly, with an owned mapping table and a monitored reconciliation job that alerts when usage arrives for an account the mapping does not recognize. Every downstream sophistication is worthless if the join is wrong.

Silent contraction. In seat-based SaaS, a customer reducing spend has to tell you. In consumption, they just run less, and unless something is watching the usage curve, nobody notices until the invoice or the renewal. Build the alert: a sustained drop against an account's own trailing baseline, sized to be meaningful for that account rather than a flat global threshold, routed to a named human. The point is not the alert — it is that someone is accountable for responding to it within days.

Forecasting in dollars when you should forecast in units. If your product's unit price changes — a rate cut, a new tier, a committed-volume discount, or in AI products a model price drop that can be substantial — a dollar-denominated usage trend silently conflates volume change with price change. Forecast the units (calls, tokens, compute-hours, messages), then apply the price schedule. This also makes the pricing team's decisions visible in the forecast, which is where they belong.

Missing the seasonality that belongs to your customers, not to you. Consumption inherits the customer's business cycle. Retail-heavy accounts spike in Q4 and go quiet in January. Education-heavy accounts follow the academic calendar. Financial services accounts move around period close. Your aggregate seasonality is a weighted blend of your customers' seasonalities, and if your customer mix shifts, your seasonality shifts with it. A model fit on last year's mix quietly degrades as the mix changes; refit annually and check whether segment weights moved.

Letting the forecast own the intervention. A forecast that predicts a shortfall and stops there is an expensive report. The value comes from routing each signal to an action: slow drawdown to a CS-led adoption plan, an early-exhaustion burn to an expansion conversation with commercial terms ready, a stalled new-account ramp to an onboarding escalation. The forecasting cadence and the account-action cadence should be the same meeting, with the same attendees — RevOps, finance, CS, sales leadership, and someone from product or data who can answer why a usage number moved.

Over-tooling before the fundamentals work. It is genuinely tempting to buy a forecasting platform first. Resist it until you have a trustworthy account-to-usage join, an authoritative source for consumed-and-remaining-commit, and a backtested baseline model. A spreadsheet built on clean data beats a platform built on a broken join, and the platform will not fix the join for you.

Reforecasting too rarely. Monthly is the reasonable floor for the full model, with weekly review of the concentrated head accounts. Quarterly-only reforecasting means you learn about a consumption shift six to ten weeks after it started, which is usually too late to do anything about it and reliably too late to warn the board.

Related questions

Does usage-based pricing make revenue less predictable overall?

Short term, yes — quarter-to-quarter variance rises. Longer term, consumption revenue often tracks customer value more tightly, so retention improves and the aggregate becomes more stable. The predictability cost is mostly a measurement and instrumentation problem, and it shrinks as the data layer matures.

How do you forecast a brand-new consumption product with no history?

Use the customer's own workload as the estimate. Ask what volume they process today on whatever they use now, size it against your metering unit, and validate during onboarding. Widen your confidence bands and reforecast every two weeks until real usage data accumulates.

Who should own the consumption forecast — finance, sales, or RevOps?

RevOps typically owns the model and data pipeline, finance co-owns the output because recognized revenue depends on actual usage, and sales owns catalyst intelligence about upcoming customer events. A single owner without the other two in the room produces a forecast nobody trusts.

How does this change compensation and quota design?

Crediting reps on committed contract value keeps quotas simple but decouples pay from revenue. Crediting on consumption aligns them but delays payout and adds volatility. Many teams split it — commit-based credit at signing, consumption-based accelerators later — which requires the same usage data the forecast runs on.

What breaks first when a seat-based company adds a consumption SKU?

The CRM's ARR field. It has one number and no concept of variable spend, so reporting immediately diverges from billing. Decide early whether ARR means annualized recent consumption or committed value, document it, and make every dashboard use the same definition.

FAQ

What is the single biggest mistake in usage-based revenue forecasting?

Treating closed-won contract value as revenue. The contract grants capacity; revenue happens when the customer consumes. The gap between those two events can run from days to two quarters, and it varies by customer, which means a bookings-driven forecast is not conservative or aggressive — it is simply measuring a different event than the one you are trying to predict.

How do you model committed minimums versus on-demand overage?

Separately, always. Model commitments as a drawdown schedule and forecast the timing of consumption, not whether it happens. Model on-demand from each account's trailing consumption trend with a wider confidence band. Present the result as a committed floor plus a ranged on-demand band rather than one blended number that hides which half is at risk.

Which leading indicators actually predict next period's consumption?

Commit burn rate relative to elapsed term, growth in active workloads or usage volume, and adoption depth — how many distinct features or workload types an account runs. Breadth of adoption tends to predict durability better than raw volume, since a single-workload account can drop to zero the moment that one workload moves.

What data infrastructure is genuinely required?

A warehouse where product-usage events join to CRM account records and billing data, with a maintained identity mapping between product, billing, and CRM identifiers. A metering or billing platform should be authoritative for consumed and remaining commitment. Reverse ETL is useful for pushing usage back into the CRM where go-to-market teams work, but it is not the foundation.

How often should the forecast be updated?

Monthly for the full model, weekly for the concentrated head accounts that drive most revenue. Consumption moves continuously, so a quarterly-only cycle means discovering shifts six to ten weeks late. Pair the bottoms-up build with a top-down retention-based check each month and investigate any material divergence between them.

How do you forecast accounts with no usage history at all?

Cohort curves built from your own historical accounts, segmented by whether the customer is migrating an existing workload or building something new. Migrators ramp fast; greenfield builders stay near zero until their project ships. Assign each new account to a curve at handoff and reforecast as actual usage arrives.

Sources

• https://www.snowflake.com/investors/
• https://investors.datadoghq.com/
• https://investors.twilio.com/
• https://openviewpartners.com/usage-based-pricing/
• https://www.bvp.com/atlas/state-of-the-cloud
• https://docs.metronome.com/
• https://docs.withorb.com/
• https://docs.stripe.com/billing/subscriptions/usage-based
• https://www.clari.com/
• https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/welcome.html

Related on PULSE

• [How Do I Run RevOps for a Usage-Based or Consumption Pricing Model in 2027?](/knowledge/q16211)
• [How do you build a usage-based pricing model in 2027?](/knowledge/q12905)
• [How do you reconcile usage-based consumption with CRM ARR fields after a pricing model change?](/knowledge/q10446)
• [How do you model expansion rate for usage-based pricing on Pipedrive without another point solution?](/knowledge/q10095)
• [How do you model CAC for usage-based pricing when you have no upfront contract value?](/knowledge/q419)