SaaS usage based pricing: choose a metric customers can predict
- Aug 22
- 4 min read
Updated: Aug 29
Introduction
Charging by usage aligns what customers pay with what they get, grows revenue as accounts grow, and lowers the barrier for small buyers.
It also introduces an unwelcome property: customers cannot predict their bill. How much that matters depends almost entirely on which metric you choose, which is the decision this whole subject turns on.
1. SaaS usage based pricing lives or dies on the metric
Three conditions, and the metric has to satisfy all of them.
It must increase as the customer gets more value, so paying more feels proportionate. It must be predictable enough for the customer to budget. And it must be something they control.
Metrics failing the third condition cause the most damage: charging on something driven by external factors means a customer's bill rises for reasons they cannot influence, which is the fastest route to churn.
2. Do not charge for the behaviour you want to encourage
The most common structural error, and it is easy to make.
Charging per user discourages adding the colleagues who make the product stick. Charging per project discourages the second project. Charging per report discourages the habit that demonstrates value.
Pick a metric that grows with the customer's success rather than with their engagement. Volume processed, revenue handled, or records stored usually work better than actions taken.
3. Make the bill predictable
Unpredictability is the main objection buyers raise, and it can be designed out.
Offer usage tiers with defined bands rather than pure metered pricing, publish a calculator, show projected charges in the product before the period ends, and alert customers as they approach a threshold.
Surprise bills produce refund requests, disputes and cancellations, and the damage exceeds the revenue. A customer who was warned and chose to exceed the limit is a different customer from one who discovers it afterwards.
4. Combine a base fee with usage
Pure metered pricing is volatile for you as well as for the customer.
A platform fee covering access plus usage charges above an included allowance gives you predictable baseline revenue and gives the customer a floor they understand.
It also protects against the customer who uses almost nothing but still consumes support and infrastructure — pure usage pricing means the lightest accounts pay nothing while still costing you.
5. Decide what happens at the limit
The policy question that determines whether this model damages relationships.
Options: block further usage, allow overage at a published rate, or upgrade the plan automatically. Each is defensible; none can be improvised at the moment a customer hits the ceiling.
For anything business-critical, blocking is usually wrong — a customer whose operations stop because they exceeded a threshold will remember that permanently. Overage at a stated rate, with a warning beforehand, is generally the safer default.
6. Expect the revenue pattern to change
Usage pricing changes the shape of the business, not just the price list.
Revenue becomes seasonal if your customers are seasonal. It falls when customers have a bad quarter, which means your revenue is correlated with their trading conditions rather than insulated from it.
Forecasting also becomes harder, and the finance implications are real. This is manageable and it should be a deliberate choice rather than a discovery.
7. Grandfather existing customers when you change it
Migrating from seat-based or flat pricing to usage-based will make some customers worse off.
Identify them before announcing, and decide what to do: keep them on existing terms, cap their increase, or phase it over renewals. Give long notice and explain the reasoning.
The credibility cost of a poorly handled pricing migration exceeds the revenue gained. Customers who feel repriced without warning tell other people, and in a small market that is expensive.
8. Model it against your actual account distribution
Before committing, run the proposed pricing across your existing customer base.
Calculate what each account would pay under the new model against what they pay now. You are looking for total revenue, how many accounts pay materially more or less, and whether the largest accounts are now paying an amount they will contest.
Do the same for your smallest accounts. Usage pricing that makes the entry point almost free changes who signs up, and often who you end up supporting.
Conclusion
Everything depends on the metric: it must rise with customer value, be predictable, be within their control, and never penalise the behaviour that makes the product stick.
Make bills predictable with tiers, calculators and threshold alerts, combine a base fee with an included allowance, decide the overage policy in advance and avoid hard blocking of critical work, accept that revenue becomes correlated with customers' trading, grandfather existing customers through any migration, and model the change across your real account distribution first.
.png)



Comments