Consumption Forecasting for Usage-Based Revenue

Consumption forecasting predicts how much customers will use and turns that usage into expected revenue, giving Finance a clearer view of what each account may produce after the contract is signed.

It has become more important as SaaS, AI, and cloud companies move toward usage-based pricing, where customers pay according to consumption rather than a fixed monthly fee. Metronome and Greyhound Capital surveyed 100 SaaS companies in January 2025 and found that 85% were already using some form of the model.

The challenge is that a signed contract no longer tells Finance exactly what an account will produce. Usage can rise, slow down, burn through a commitment, or move into overages.

Consumption forecasting connects that changing usage with pricing and contract terms, giving teams a clearer view of how much revenue is likely to appear and when.

What is consumption forecasting?

Consumption forecasting predicts how much customers will use and turns that usage into expected revenue, giving Finance a clearer view of what each account may produce after the contract is signed.

The unit depends on the product. It could be API calls, credits, storage, transactions, compute hours, or something else entirely. What matters is how that usage changes over time. Is the customer ramping faster than expected? Staying flat? Burning through its commit early? Barely using what it bought?

Usage tells you the pace, not the dollars. One customer may still be working through prepaid credits, while another hits an overage at the same level of activity. The contract decides how that usage becomes part of the broader revenue forecast.

Usage forecasting predicts the units. Consumption forecasting shows what those units are worth, when the revenue is likely to appear, and whether the account is moving toward expansion or risk.

Why consumption forecasting matters in a usage-based model

A signed contract tells Finance what the customer agreed to buy. It does not tell them how the account will behave once the product is live.

That distinction matters in a usage-based business. One customer may burn through its commit faster than expected and move into overages. Another may sign the same contract, ramp slowly, and finish the year well below plan.

The booked value can look identical while the revenue path moves in opposite directions.

Consumption forecasting brings that post-sale behavior into the forecast. It shows whether usage is building, flattening, or falling, and whether the account is moving toward overage revenue, expansion, or renewal risk.

Finance gets a better view of where revenue is heading. RevOps can see what is driving the change. Sales and Customer Success get time to act before slow adoption or rising demand turns into a surprise at the end of the quarter.

Why traditional forecasting breaks in a consumption model

Traditional forecasting is built around the opportunity. The rep gives a stage, amount, close date, and commit. Once the deal closes, the forecast mostly treats the revenue as settled.

That assumption falls apart when revenue depends on usage. The contract may be signed, but the number can still move every week. A customer can ramp faster than expected, leave credits unused, or cross into overages without a new opportunity ever appearing in the CRM.

Finance may still be looking at booked value while the real movement is happening in product usage, billing data, adoption, and contract drawdown.

That is why a forecast built mainly on CRM stages and rep commits misses what happens after closed-won. It can tell you what sold. It cannot reliably tell you what will be consumed.

The biggest challenges in consumption forecasting

The hard part is rarely the formula. It is getting product usage, contracts, billing, and Finance into the same revenue view.

Usage may sit in the warehouse. Contract terms live in the CRM. Billing has the actual charges. Finance may still be reconciling everything in a spreadsheet.

The numbers can also mean different things to different teams. Product may report credits issued. Customer Success may track active usage. Finance only cares about what can be billed or recognized. Those numbers are related, but they are not interchangeable.

Then the contract logic gets involved. A prepaid balance, volume discount, or overage rate can change what the same usage is worth from one customer to another.

Timing is the other problem. Usage can move quickly, while the forecast is often reviewed monthly. By the time the change is visible, the account may already be well above plan or quietly falling behind.

A trustworthy forecast depends on one agreed definition of usage, contract terms that match billing, and updates frequent enough to catch movement before it becomes a quarter-end explanation.

What data goes into a consumption forecast

You do not need every data source in the company. You need the ones that actually change the number.

Start with committed revenue. Minimum commits. Prepaid credits. Contract floors. That is the baseline and usually the most predictable part of the model.

Then look at usage run rates. Trailing 7-day, 30-day, and 90-day views at the account level and cohort level. If an account is ramping faster than expected, slowing down, or staying flat, that matters right away.

Then look at cohort behavior. New customers do not behave like mature ones. Early-stage accounts need different assumptions than accounts with a year of history. Ramp matters. Time to value matters. Plateau points matter.

You also need account context. Lower usage is not just a revenue issue. It can be the first sign of a renewal problem. Expansion signals matter too. More workloads. More projects. Higher concurrency. Growing data volumes. Those are not just product metrics. They are forecast inputs.

And then there is seasonality. Year-end budget flush. Summer slowdowns. Product-specific demand patterns. External factors and seasonal changes can materially shift consumption, which is why serious forecast models include them instead of treating them like surprises.

A practical consumption forecasting example

Say a customer buys 12 million credits for the year.

The first few months are slow while the product is being rolled out. Then a second team starts using it and consumption jumps. By month six, the customer has already used 7 million credits.

The contract has not changed, but Finance can no longer assume the original revenue plan still holds. The account may run out of credits before renewal and move into overages. Or the jump may be tied to one project and disappear next month.

That is the judgment the forecast needs to make.

Projecting the latest month forward could overstate revenue. Ignoring the increase could understate it. The better approach is to compare the new usage with the customer’s earlier ramp, remaining credit balance, rollout plans, and overage terms.

From there, the team can decide whether to raise the forecast, start an expansion conversation, or wait until the higher usage becomes a real pattern.

Common methods teams use to forecast consumption revenue

There is no single method that fixes this. Most teams end up using a mix. Not because they love complexity. Because usage-based revenue does not behave nicely enough to fit into one model.

Revenue buckets

This is usually the first thing that helps.

• Committed revenue

• Expected consumption

• Upside or overage revenue

• Revenue at risk

That does not make the forecast perfect. But it does make it more honest.

Cohort-based forecasting

New customers do not behave like mature ones. Some ramp fast. Some ramp slowly. Some never really get going. If you apply the same assumption to all of them, the model starts lying pretty quickly.

Run-rate forecasting

This is the part most teams lean on first because it is simple. Take recent usage. Look at the trend. Project it forward. That works better than guessing. But it also has limits. If the account is ramping, slowing, or behaving strangely, a straight run-rate view can give you false confidence.

Scenario planning

This matters more than people think. A usage-based business usually should not be forecast as one clean number. It should be forecast as a range.

• Base case

• High usage case

• Low usage case

The mistake is just adding or subtracting 10% and calling that a scenario. A real scenario changes the assumptions underneath. Ramp speed. Expansion. Contraction. Seasonality. Sometimes margin too, if higher usage also changes cost.

Statistical or AI models

Some teams go here once the basics are working. That can help. But it is not the place to start. If the usage data is messy, the pricing logic is inconsistent, or billing does not tie out cleanly, a more advanced model just gives you a more complicated wrong answer.

A practical process for building the forecast

Start by splitting the revenue. 

What is committed. What is likely from current usage. What is upside. What is at risk. That alone usually improves the conversation because it makes the model more honest.

Then build assumptions by cohort. Do not model every account the same way. New customers need different assumptions than mature ones. Enterprise accounts usually need different assumptions than SMB. Volatile accounts need different assumptions than stable ones.

Then add seasonality. If usage always spikes at quarter end, put that in the model. If summer is soft, put that in too. Do not keep rediscovering the same pattern every quarter and acting surprised.

Then reforecast faster. A quarterly rhythm is often too slow for a usage-based business. Monthly rolling forecasts with weekly updates usually fit better because the business itself is moving faster.

Most of all, stop forcing fake precision. If the variable part of the business is genuinely variable, do not pretend you can call it down to the dollar. A range the team believes is more useful than a precise number nobody trusts.

How MaxIQ helps teams build a better consumption forecast

Most companies already have the data. The problem is that it lives in different places.

Product usage sits in the warehouse. Contract terms live in the CRM. Billing shows what was charged. Customer Success usually knows why an account slowed down, expanded, or never ramped in the first place. Finance is left trying to piece it together after the number has already moved.

MaxIQ brings that account context into ForcastIQ, so teams can see which accounts are changing the forecast and what is driving the movement.

A drop in usage does not always mean the same thing. It could be seasonality, a delayed rollout, a finished project, or the first sign of renewal risk. The same applies to a sudden spike. It may be real expansion, or it may be activity that will disappear next month.

That context makes the revenue forecast easier to trust. Finance and RevOps can see where the number is moving. Sales and Customer Success can act before an overage, slowdown, or expansion opportunity becomes obvious at the end of the quarter.

The point is not another usage dashboard. It is knowing what customer behavior is likely to mean for revenue next.