Usage-based pricing: The unit you meter picks your roadmap

Pick the unit you charge for and you have made two decisions, one of them silently.

The first is the obvious one: revenue now moves with consumption instead of with contract renewals. The second is that you have chosen which product improvements you are allowed to be enthusiastic about. Charge per seat and efficiency features cost you money. Charge per API call and batching requests is a revenue reduction. Charge per row stored and helping customers clean up their data becomes an act of charity.

Nobody writes that trade-off down, and then it shows up two years later as a roadmap argument nobody can win, because the pricing model is on one side of it.

What is usage-based pricing?

Usage-based pricing charges for consumption of a metered unit (calls, messages, compute, storage, active users) rather than for access. Also called consumption or pay-as-you-go pricing. Its appeal is real and worth stating plainly: customers can start at almost nothing, spend grows as they get more value, and expansion needs no contract amendment and no salesperson, which is why it pairs naturally with adoption that begins without permission.

What separates it from the alternatives is who has to decide before revenue grows. Every other model waits for a person to make a decision. Per-seat waits for a manager to add a colleague. Tiered waits for someone to click upgrade. Flat waits for a renegotiation that has to land on somebody’s calendar. Usage-based waits for nobody: the customer’s traffic grows overnight and your revenue grows with it, while everyone involved is asleep. That is its appeal. Further down this page it is also the whole of its problem.

The pattern’s home territory is infrastructure and communications, where the unit is obvious and the customer already thinks in it: messages sent, hosts monitored, compute consumed, tokens processed. Twilio publishes a rate of $0.0083 per SMS in the US and describes the model in exactly these terms, promising customers they will “only pay for what you use” without “contracts, capacity planning, and rigid price models.”¹ Datadog, Snowflake and the model providers all price on comparable logic, because consumption is a genuine proxy for value received.

Choosing the value metric

The unit you charge for is usually called the value metric: the thing a customer buys more of as they get more out of you. Three properties matter, and a metric missing any of them causes a predictable specific problem.

The customer can predict it. If they cannot estimate next month’s bill within a reasonable range, the model is a source of anxiety, not fairness, and anxiety is what makes finance teams block adoption.

It rises with their success, not their effort. Metering something a customer does more of when things are going badly is the worst available choice: charging per support ticket, per error, per retry. Metering something they do more of when winning is the whole idea, and it is the same question as choosing where a free tier’s limit should sit.

Gaming it should cost them value. A metric customers can reduce without giving anything up is one they will reduce. If a cheaper usage pattern is also a worse outcome for them, the incentives hold; if it is merely more fiddly, you have created a game and they will win it.

One structural trick removes a lot of this anxiety before it starts: separate the cheap resting state from the expensive active one, and meter only the active part. Data warehouses are the standard example, pricing storage at a low rate per unit held and charging materially more for the compute that runs a query. Customers stop worrying about the cost of keeping things and only think about the cost of doing things, which is also the only part that correlates with value.

Seats are the exception worth testing mechanically, because the three properties above are all judgment calls and this one is not. Rob Walling’s rule: charge per seat only if two people at the same company see different things when they log in. If they see the same screen they will share a login, and no enforcement you build will be cheaper than the pricing mistake underneath it.²

The forecasting problem, and why pure models do not survive

The honest cost of usage-based pricing is that nobody knows what anything will cost.

It is worse than it looks, because the headline rate is rarely the whole rate. Twilio’s own US SMS pricing adds carrier fees of roughly $0.0025 to $0.007 per message on top of the $0.0083, which can approach doubling the advertised price depending on the carrier.¹ Nobody is being deceptive; the pass-through is real and disclosed. But a customer who budgeted from the headline number is wrong, and being wrong about a bill is what makes finance teams distrust the model.

So the customer cannot budget confidently. Procurement cannot approve a number that does not exist. Your own finance team cannot forecast revenue, which matters more than it sounds: variable revenue is valued lower and harder to plan around than the same amount of contracted revenue.

Which is why mature consumption businesses tend to end up selling something that looks a lot like a contract. Commitments in exchange for a discount, prepaid credits, capacity reservations, volume tiers with a floor. These are not compromises of the model. They are what it looks like once it matures, and they reintroduce exactly the predictability that pure pay-as-you-go removed, for both sides.

There is also a set of cheap mechanisms that treat the anxiety directly instead of pricing around it. Alerts at fractions of expected spend (half, three quarters, nearly there) so the bill is never a surprise. A spending cap the customer can set themselves. Its main value may be that it exists rather than that it gets used, because a ceiling is often what makes the model approvable at all. And testing what hitting the cap feels like, since that experience is designed by nobody in most consumption businesses. If the first time a customer learns their number is when the invoice lands, the model has already cost you their trust.

The practical lesson is not to resist the commitment mechanisms but to plan for them. A product that has pure consumption pricing and no commitment mechanism has an enterprise ceiling it will hit without warning, usually in a deal it was expected to win.

When metering works against you

Predictability is where consumer-facing customers get hurt. A business whose own traffic is unpredictable inherits your variability and resents it, and the resentment lands at renewal even if the total was fair.

Hybrid is the normal answer

Framing this as a choice between seats and consumption is a false binary, and a great deal of software pricing is neither.

The common shape is a platform fee for access plus metered consumption on top: predictable revenue for you, a predictable floor for the customer, and upside that tracks their growth. Another is seats for the collaboration layer and usage for the machine-heavy part, which prices the two things by what actually drives cost.

What matters is that each component is doing an identifiable job. If you cannot say what the platform fee is for, customers will ask, and the answer “it is how we make the revenue predictable” is not one they will accept.

The number subscription businesses never have to watch

Consumption revenue contracts continuously instead of at renewal, which changes what you monitor.

1. Net revenue retention, decomposed into seats, usage, tier and price. The whole promise of this model is that consumption grows on its own. If your expansion is actually coming from price increases or added seats, you have per-seat pricing with a meter attached.
2. What share of accounts consume less this month than last? In a consumption business, contraction is continuous rather than an event at renewal, and it is invisible unless you look for it specifically. This is the closest thing to an early-warning system you get.
3. How accurately can a customer predict their own bill? Ask a few. If the answers are wide, you have a churn risk that will present as a pricing complaint.
4. What share of revenue is committed versus purely variable? Rising is usually maturity rather than a retreat, and it is the number that determines how a buyer values the business.

Published figures on how many companies use consumption pricing circulate widely and come from vendor-sponsored surveys with limited method disclosure; direction of travel is safe to assume, specific percentages are not.¹

Say the unit out loud

1. Say your unit in one word. If you cannot, customers cannot either, and “credits” does not count: an invented currency hides the price from the person paying it and is the usual way a consumption model becomes unapprovable.
2. Read your metric backwards. What would a customer do to halve the bill, and would you be glad if they did?
3. Plot usage against retention. If heavy users churn at the same rate as light ones, you are charging for activity, not value, and the metric needs replacing. This is the operational version of the correlation question, and the query is a morning’s work.
4. Ask five customers to predict next month’s invoice. The spread in their answers is your forecasting problem, quantified, and it takes an afternoon.
5. Set up spend alerts and a customer-settable cap, then hit the cap yourself and see what happens.
6. Instrument month-over-month contraction at the account level. In consumption pricing this is churn, arriving quietly.
7. Design your commitment mechanism before you need it, because you will need it in the first enterprise deal, and improvising it under deal pressure produces terms you keep forever.
8. Separate the components of a hybrid and be able to say what each is for.

Pricing decides what one account is worth. How an account gets larger runs on something else entirely, and in most B2B software it has almost nothing to do with the price and everything to do with the fact that the second purchase is made by a different person, with different concerns, who was never in the product. Land and expand is where product-led growth stops being purely product-led.

Updated August 2026