When flat pricing leaves money on the table
Flat subscription pricing is simple to sell and easy to forecast. It has one weakness: every customer on a plan pays the same, however much value they take out. In most products, usage is far from even. A small share of accounts drives a large share of activity, and those accounts often pay the same as the ones that barely log in.
That gap is where usage based pricing earns its place. It does not have to replace your plans. In most SaaS products the practical first step is a hybrid: keep the subscription, add an allowance, and charge for usage above it.
Monetisation flags this opportunity when your usage data shows a long tail of heavy accounts on flat plans, or when infrastructure cost per account rises with usage while price does not.
The three common models
| Model | How the bill is set | Suits | Watch out for |
|---|---|---|---|
| Pure pay as you go | Price per unit, no base fee | Developer tools, APIs, infrastructure | Unpredictable revenue and bills, low commitment |
| Plan with overages | Base fee includes an allowance, extra units charged | Most SaaS with a volume metric | Allowance set too high or too low |
| Hybrid seat plus usage | Price per seat plus usage above an allowance | Team tools where both people and volume matter | Bills that are hard for buyers to predict |
Most products adding usage to an existing subscription choose the second or third model, because existing customers keep a familiar base price.
Choosing the metric
A good usage metric has four qualities:
- It tracks value. If the customer gets more from the product, the metric rises.
- It is predictable. A buyer can estimate next month's bill within a reasonable range.
- It is measurable. You record it reliably and can show it in the product.
- It is hard to game. Customers cannot easily cut the metric without cutting value.
Examples that often work: API calls, documents processed, messages sent, records synced, minutes of media processed, monthly active contacts. Examples that often fail: logins, page views inside the app, or anything customers see as a penalty for engagement.
A worked example with overages
Take a hypothetical API product with 200 accounts on a 99 USD per month plan with no usage limit. Usage over the last six months looks like this:
| Usage band (calls per month) | Accounts | Average calls |
|---|---|---|
| Under 5,000 | 150 | 2,000 |
| 5,000 to 10,000 | 35 | 7,500 |
| Over 10,000 | 15 | 30,000 |
The proposal: keep the 99 USD plan, include 10,000 calls, and charge 5 USD per additional 1,000 calls. Only the 15 heavy accounts are affected.
| Line | Calculation | Monthly amount |
|---|---|---|
| Overage per heavy account | 20,000 extra calls x 5 USD per 1,000 | 100 USD |
| Overage revenue if all 15 stay | 15 accounts x 100 USD | 1,500 USD |
| Expected case, 2 heavy accounts leave | 13 x 100 USD overage, minus 2 x 99 USD lost base fee | about 1,100 USD |
Under the low case, where 5 of the 15 heavy accounts leave, the net gain is 10 x 100 USD minus 5 x 99 USD, about 505 USD. Under the high case, where none leave, it is 1,500 USD. That spread is exactly what the opportunity card shows: a range, a confidence level and the assumption written out. These are estimates, not a guarantee of results; the method is explained on how estimates work.
A hybrid seat plus usage example
For a team tool, a hybrid can be fairer than seats alone. Suppose a workflow product charges 30 USD per seat. A ten-person team pays 300 USD per month, whether it processes 500 documents or 50,000.
A hybrid might be 25 USD per seat including 1,000 documents per seat, then 2 USD per extra 100 documents. The ten-person team processing 5,000 documents pays 250 USD, a little less than today. The same team processing 30,000 documents pays 250 USD plus 400 USD of overage, 650 USD in total. Light teams pay slightly less, heavy teams pay in line with their volume.
How Monetisation estimates the opportunity
Usage data comes from a read-only connection to your product database, or from usage events uploaded as CSV. Stripe, connected with a restricted read-only key, provides plans, prices and churn. Monetisation then:
- Builds the usage distribution per account and per plan
- Finds the share of usage driven by the top accounts
- Tests several allowance levels and overage prices against that distribution
- Applies an assumed churn among affected accounts, using your own churn history as a guide
- Shows the result as a low, expected and high monthly range with the method
If you want to see the whole pricing picture, our page on pricing optimization software covers plan mix and price levels. API businesses can read the API monetisation use case.
Rolling it out and measuring
Monetisation is read-only and never changes prices or subscriptions. You create the overage price in your own billing, and Monetisation records the change as a dated intervention and compares revenue, expansion and churn against the baseline trend. Results end in a verdict: win, flat, loss or not enough data.
Practical rollout choices that reduce risk:
- New customers first. Apply the new plan to sign-ups for a period before touching existing accounts.
- Notice and a dashboard. Give existing customers notice and a usage view so the first overage is not a surprise.
- Caps and alerts. Let customers set a spending cap or receive alerts at 80 percent of the allowance.
- Annual commitments. Offer a discounted prepaid allowance for heavy users; see annual plan pricing for the discount arithmetic.
Common mistakes
- Allowance set from averages. An average hides the shape of usage. Set the allowance from the distribution so most accounts stay inside it.
- Overage price with no anchor. If the unit price above the allowance is far higher than the effective price inside it, customers feel penalised. Keep the two in a sensible relation.
- No visibility for customers. A usage meter in the product and an email before the allowance runs out prevent surprise bills and support tickets.
- Changing everyone at once. Rolling out to new customers first gives you a clean measurement and lowers the risk.
Where to start
Run a sample audit from the homepage to see the first three opportunities for your product in about a minute. To get the usage analysis from your own data, connect Stripe and your product database on any plan. Growth includes 10 connected sources and Scale includes 30. See pricing for the details.
Questions
What is usage based pricing in SaaS?
It is a pricing model where the bill depends on consumption of a measurable unit, such as API calls, messages, storage or processed records, instead of a fixed fee alone. It can be pure pay as you go or combined with a base subscription.
What is an overage charge?
An overage is a price per unit above the allowance included in a plan. A plan might include 10,000 calls a month and charge a set amount for each additional 1,000.
Is usage based pricing better than per seat pricing?
Neither is better in general. Per seat pricing suits tools whose value grows with the number of people using them. Usage pricing suits tools whose value grows with volume. A hybrid of both is common when value depends on each.
How do I choose a usage metric?
Pick a unit customers understand, that tracks the value they get, that you can measure reliably, and that they can predict. If customers cannot estimate their bill, they hesitate to buy.
Will usage pricing increase churn?
It can for heavy users who were getting a bargain on a flat plan. That is why any estimate should include an assumed churn among those accounts, and why grandfathering or a gradual change is common.
See what your own site is leaving on the table
A sample audit reads your public pages and returns the first three opportunities with estimates and methods. About a minute, no card.