Usage-based Pricing

The simplest way to price anything is to nail it to a number per month. The seller can calculate next quarter's revenue today, and the buyer files one purchase approval. In products where one customer consumes ten or a hundred times what another does, though, that simplicity makes both sides uncomfortable.

Light customers feel overcharged, and they say so. Every renewal conversation includes someone asking why a team that opens the product three times a month pays what a team using it daily pays. At the other end of the range the seller loses money. One account can burn 40 percent of the total storage bill while paying what the lightest customer pays.

A flat fee can't fix both ends at once. Lower the number and the heavy accounts bleed more; raise it and the light ones leave at renewal. Usage-based pricing sidesteps the fork by giving up on a single number and producing a different invoice for every customer. It works the way an electricity bill works: you pay for what the meter recorded.

Pick a unit to count, measure how many of those units occurred during the billing period, and multiply by a rate. The invoice total changes every month.

1. Choose the unit you count. A gigabyte of storage, a thousand exports, one delivered email — it has to be something the customer can hold in their head. Pick the wrong unit and nobody can predict their own invoice. A second of server processing time is the classic mistake: no customer has any idea how many seconds they use.
2. Set the rate and the free allowance. At $0.40 per gigabyte with the first 10 gigabytes free, a team storing 34 gigabytes pays for 24 of them, or $9.60. The free allowance exists to stop you from issuing tiny invoices. Collecting $0.60 and handing $0.25 of it to a payment processor is worse than not billing at all.
3. Build the plumbing that does the measuring. Usage records have to accumulate per customer inside the product and roll up at the end of each period. That number is the invoice, so an error in it turns into refunds and apologies. Build the screen where customers can check that same number.
4. Add the guards that prevent surprises. Show a projected total as the month runs, send an alert when usage passes roughly three times the normal level, and let customers set their own ceiling. Without those, someone who accidentally runs the same job in a loop receives a bill twenty times their usual one, and that single invoice ends the contract.

In practice this almost always sits on top of a subscription, which charges a set amount every period. A base plan at $75 that includes 50 gigabytes of storage, with usage charges applying only above that line, is the common shape. The predictable revenue comes from the base fee while the cost of heavy accounts gets recovered through the overage.

The model fits products where consumption spreads far apart between customers and moves in step with the value each customer gets. Email delivery services are the clearest case. There's no single number that works for both a shop sending a thousand messages a month and a company sending three million, and the heavy sender is earning more from those messages, so a larger bill is easy to accept. Cloud servers, payment processing, map lookups and language model calls all use the same structure. When the seller's own costs scale with consumption — storage and data transfer being the obvious examples — the model passes those costs straight through to the invoice, so a growing set of heavy accounts doesn't push the business into a loss.

Where it doesn't fit is equally clear. When consumption moves independently of the value a customer receives, the model turns into a penalty. Charge a collaborative document tool by the number of documents created and customers will create fewer documents, which is another way of saying they use the product less. Enterprise purchasing is the other obstacle. A company that gets a year's budget approved in advance struggles to sign a contract with no fixed number in it, so the model gets repackaged: commit to an annual volume up front, settle the overage later.

Reading average revenue per user (ARPU) — the average revenue one user brings in — also changes here. The spread is wide enough that a single average hides everything; split the top 10 percent from the rest before the distribution shows up.

"Twelve accounts had usage charges larger than their base fee this month."

The plan no longer matches how people actually use the product, so the tiers need reworking.

"If we go usage-based, I can't forecast next quarter's revenue."

An objection about planning: nothing fixes the number in advance.

"Let's open it with 10 gigabytes free and only charge above that."

Leave the small accounts alone and recover costs only from the heavy ones.

Pagedeck launched with a flat per-team plan, and about a year in the storage bill turned into a problem. Eight of 200 accounts were uploading video and design files, between them consuming close to half of all storage spend. Grace wanted to raise prices for those eight. Sofia said that would lose all eight at renewal.

Mia's proposal was different: include 50 gigabytes in the base plan and charge $0.40 per gigabyte above it. For 192 of the 200 accounts the invoice didn't move at all, and only the eight saw an increase. Because the change was announced two months ahead and the usage screen shipped first, five of the eight deleted files they weren't using and dropped back under 50 gigabytes.

The common assumption is that charging for consumption is always fairer to the customer and that revenue rises on its own as a result. The structure looks fair, so it reads that way. What customers actually experience, though, is an invoice they can't predict. Someone working against a fixed budget avoids uncertainty by using less, and using less means the product never settles into the work. From the seller's side, a quiet month that bills nothing means money that used to arrive for free has disappeared. That's why this model normally ships with a base fee attached and a projected total on screen.

The second mistake is treating it as a pricing change. It looks like editing a rate card, but what it actually requires is plumbing that runs from per-customer usage records through aggregation, invoicing and refunds. Announce the plan without it and someone pulls records by hand each month to assemble the amounts. At 500 accounts billing errors show up monthly, and one wrong invoice damages trust more than an imperfect rate card does.