How to Build a Usage-Based Revenue Forecast

Consumption pricing breaks the assumption that most forecast models rest on. A subscription forecast asks when a contract will be signed. A usage forecast has to ask what customers will actually do after signing, which is a behavioral question rather than a contractual one. The build works, but the components are different.

What makes usage revenue harder to forecast?

Revenue is decided after the sale rather than at it.

With a subscription, the contract sets the number and the forecasting problem is timing. With consumption, the contract sets a floor and a rate, then the customer determines everything above the floor. Two accounts signing identical agreements on the same day can produce wildly different revenue over the following year.

That shifts the data you need. Contract terms remain necessary for the floor, and consumption telemetry becomes the primary input for everything else. A forecast built only on contract values will systematically miss the portion of revenue that actually varies.

What are the components of the model?

Five lines, each with a different method. The minimum line is the only certain one, and treating it as the forecast is the most common mistake. Companies with heavy consumption exposure can find that half their revenue sits above the floor, which means half the forecast comes from behavior rather than from contracts.

Keep the components separate in the output. When the number moves, you need to know whether existing accounts consumed less or fewer new accounts signed, because those failures belong to different teams.

How do you forecast overage?

Per account, from the trailing three-month consumption trend, never in aggregate.

Overage concentrates. A small number of accounts growing quickly produce most of it, and averaging across the base hides them completely. The aggregate approach produces a smooth line that misses in both directions, since it dilutes the accounts that are surging and inflates the ones that are flat.

Build the calculation account by account. Take trailing three-month consumption, fit a simple trend, project it across the forecast period, and compare the projection to the commitment. The difference above the commitment is the overage line for that account. Sum only after each account has been calculated.

Cap the projections. An account that tripled consumption in two months is unlikely to triple again, and an uncapped trend line will produce a number that embarrasses you at the forecast call. A ceiling based on the highest sustained growth rate observed in your mature accounts keeps the model honest.

How do you model new accounts ramping?

Build an average ramp curve from historical accounts, indexed to month one consumption.

New consumption customers rarely start at their steady-state level. They onboard, they migrate workloads, and they reach a plateau some months later. Measure that curve from accounts that signed twelve or more months ago, indexed so accounts of different sizes can be compared.

The ramp curve then converts a new bookings forecast into a revenue forecast. A deal closing in month one of the quarter contributes very differently than the same deal closing in month three, which is a distinction that subscription models can ignore and consumption models cannot.

Segment the curve if your data supports it. Enterprise migrations ramp slowly and land high. Self-serve accounts often reach steady state within weeks. One blended curve applied to both will misstate the timing of most of your revenue. The cohort mechanics behind this are the same ones covered in the net revenue retention glossary entry.

Which leading indicators predict consumption changes?

Trailing usage trend first, then workload or active user counts, then support engagement.

Usage trend is the primary signal and the most direct. Active user or workload counts usually move before consumption does, which buys time to intervene before the revenue number moves.

Support engagement is the third signal and the least intuitive, because the relationship is not linear. In ORM customer data, accounts with no support cases at all are at risk, since nobody is using the product deeply enough to hit a problem. Accounts with seven or more cases in a year are also at risk. Accounts with three to five cases, usually lower severity, churn least often, because they are engaged and getting help.

Feed those flags into the contraction line as named accounts rather than as a blended risk percentage. A contraction forecast that lists twelve specific accounts can be acted on. One that applies a 4 percent risk haircut to the base cannot.

How do you report a usage forecast?

As a monthly reconciling waterfall, with each component visible.

Build the output as beginning revenue, churned customer revenue, churned product revenue, product decreases, new customer revenue, new product revenue, product increases, and ending revenue. Beginning revenue for each month equals ending revenue from the prior month, which forces the model to reconcile against itself.

That structure answers the question executives actually ask, which is what changed and why. A single total hides whether a strong month came from new logos or from three existing accounts expanding, and those two outcomes carry entirely different implications for the next quarter. Compare the output against your booked forecast using the discipline in how to forecast revenue, and grade it with the measures in the forecast accuracy glossary entry.