Usage based pricing: charging for what customers actually consume

Usage based pricing charges customers according to how much they consume — messages sent, storage used, transactions processed, hours booked — rather than a flat subscription. Its appeal is fairness in both directions: small customers pay little and can start easily, large ones pay more as they grow, and revenue expands without a renegotiation.

The costs are real too. Revenue becomes harder to forecast, invoices become harder to predict and therefore harder to approve, and a customer who receives an unexpectedly large bill does not experience it as fair pricing. Most of the work in usage pricing is in managing those two problems rather than in setting the rate.

What to decide before launching it

• The metric: what you count. It must be something the customer can see, understand, and connect to the value they get. Counting something internal to your architecture is the classic mistake.
• The unit and the rounding — per message, per thousand, per gigabyte-month — and how partial units are treated.
• Whether there is a base fee. A small platform fee plus usage smooths revenue and covers the cost of simply having a customer.
• Included allowance: usage bundled into the base before charges begin.
• Tiers or volume discounts, and whether they apply retroactively to all usage or only above each threshold. These produce very different bills.
• Caps or spending limits, so a runaway integration cannot produce an invoice nobody can pay.
• The billing period and when usage is measured — in arrears is normal, and it means you invoice after the value was delivered.
• What happens at the limit: hard stop, soft overage, or notification. Decide before a customer hits it.

Give customers visibility into their usage before the invoice arrives, not with it. A bill that is 40% higher than last month is a support ticket at best and a cancellation at worst — the same amount is accepted without complaint when the customer watched it accumulate. Predictability matters more to buyers than the absolute level, which is why spending caps and mid-period alerts are retention features rather than niceties.

Making it work operationally

1. Pick a metric the customer already thinks in. If you have to explain the unit before explaining the price, choose a different unit.
2. Meter it accurately and keep the raw records. Any dispute is settled by your ability to show what was counted and when.
3. Publish the rate and an example calculation. "Contact us" pricing on a usage model destroys the main advantage, which is that a small customer can start without a conversation.
4. Set a default spending cap for new customers, and let them raise it deliberately.
5. Notify at thresholds — half, three quarters, at the cap — through a channel people actually read.
6. Show the usage breakdown on the invoice: quantity, rate, period, and any allowance applied. An unexplained total gets queried every time.
7. Forecast with a range rather than a number, and track the variance for a few months until you know your own seasonality.
8. Review annually which customers are on which pattern — usage pricing tends to produce a small number of very large accounts, which is a concentration risk worth naming.

Hybrid is usually the answer

Pure usage pricing is rare in practice because it leaves both sides exposed: you cannot forecast, and the customer cannot budget. The common resolution is a base subscription that includes a meaningful allowance, with usage charges above it. That gives you predictable revenue for the floor, gives the customer a bill they can approve without thinking most months, and preserves the expansion that made usage pricing attractive. If you are choosing a model from scratch, start there rather than at either extreme.

In Ettex, the invoices carry the detail: Ettex Invoices handles line items with quantities, rates, multiple tax rates and discounts, notes and terms fields where the usage period and any allowance belong, sequential auto-numbering with your own prefix, and statuses from draft through paid — which is what makes a usage line checkable rather than a bare total. The usage records and the monthly calculation sit in Ettex Sheets with formulas and a per-customer breakdown, threshold notices go out through Ettex Mail with reusable text and scheduled send, the revenue lands in Ettex Books, and the contract that sets the rate is signed through Ettex Signature.

The boundary, stated plainly: Ettex does not meter usage and does not do usage-based billing. There is no metering, no rating engine, no automatic aggregation of events into an invoice, no spending caps, no threshold alerts and no proration. You measure usage in your own product, calculate the charges, and issue an invoice. For automated metered billing at volume, that is a dedicated software category — and this article is about the decisions you make before choosing one.

How usage pricing goes wrong

• A metric the customer cannot see or does not connect to value.
• No spending cap, producing an invoice that cannot be paid and a relationship that cannot be saved.
• No visibility until the bill arrives.
• Invoices showing a total without the quantity, rate and period behind it.
• Tiers whose retroactivity is undefined, so nobody can predict the bill at a threshold.
• Raw usage records not retained, leaving disputes unanswerable.
• Pure usage with no base fee, leaving revenue unforecastable and small accounts unprofitable to serve.
• Revenue concentration in a few heavy users, unnoticed until one of them leaves.

Usage based pricing works when the customer can see the meter. Choose a unit they already think in, set a default cap, notify before the invoice, and show quantity and rate on the bill — and give yourself a base fee to forecast from.