Usage Based Pricing for SaaS

The failure mode is always the same. A team announces consumption pricing in a launch post, then discovers three weeks later that the event pipeline drops records under load, the invoice preview doesn’t exist, and support has no way to answer the question “why was I charged this?” Pricing is a billing systems project wearing a marketing costume.

Get the metering right and the model does something seat pricing cannot: it expands revenue without a conversation. Get it wrong and you have built a machine that generates disputes.

What actually breaks first: the unit definition

The unit you meter has to be something the customer already believes they consume. That is the whole test. Twilio bills per message because a business already counts messages. Snowflake bills per compute credit because a data team already thinks about warehouse runtime. Nobody was counting “workflow complexity points” before you invented them.

Three properties make a unit work. It correlates with the value the customer gets, it grows as the customer succeeds, and the customer can predict roughly how much of it they will need next quarter. Miss the third and procurement blocks the deal, because a buyer cannot get approval for a number they cannot put in a budget line.

The units that fail in practice are the ones tied to your cost rather than their value. Charging per gigabyte stored when the customer cares about documents processed means every efficiency improvement you ship reduces your revenue. That’s a cost plus instinct, and the value based versus cost plus tradeoff is worth reading before you settle the meter.

Credits or raw units?

Raw units are honest and comparable. Credits are flexible and opaque. Pick based on how many dissimilar actions you need to price.

If you have one meter, price it directly. A thousand API calls costs this much. Buyers can compare you to alternatives, sales can quote without a calculator, and nobody has to explain an exchange rate.

Credits earn their complexity when you have five or six actions with wildly different underlying costs: a document generation, a model call, a data export, a scheduled sync. Credits let you put all of those on one balance and adjust the rate of any single action later without touching the contract. AI features pushed a lot of companies down this road, and the AI feature pricing question is mostly a credits question in disguise.

Model	Buyer clarity	Vendor flexibility	Best for
Raw metered unit	High, directly comparable	Low, repricing needs a contract change	Single dominant action, infrastructure-shaped products
Credits	Low to medium, needs an exchange rate table	High, adjust per-action cost anytime	Many dissimilar actions, AI features with volatile COGS
Tiered buckets	High	Medium	Products where usage clusters into obvious bands
Platform fee plus metered overage	High	High	Most B2B SaaS above $25K ACV

If you do use credits, publish the exchange rate. A credits page that says “contact sales for rates” reads as a trap, and increasingly loses to a competitor who published theirs.

Commit plus overage: the structure that actually forecasts

Here’s the position: pure pay as you go is a trap for B2B products above roughly 25,000 dollars a year. It gives finance nothing to forecast, gives sales nothing to sell, and gives the customer an unbounded liability their CFO will not sign.

Annual commit with drawdown fixes all three. The customer commits to a dollar amount for the year, draws it down as they consume, gets a better realized rate than list, and pays a defined overage rate beyond the commit. You book the commit as contracted revenue. Sales has a number to negotiate. Procurement has a ceiling to approve.

The three parameters that matter:

• Commit discount. Usually 15 to 30 percent off list unit price, scaling with commit size and term. This is what makes the customer commit instead of going hourly.
• Overage rate. Set it 20 to 30 percent above the effective committed rate. Above that, customers dispute. Below it, nobody ever upgrades their commit.
• Rollover policy. Whether unused commit expires, rolls one quarter, or rolls a full year. Expiry maximises revenue and generates the most renewal friction. A one quarter rollover is the common compromise.

Floors matter too. A minimum monthly platform fee stops you supporting an account that costs more to serve than it pays. Datadog, Segment and most infrastructure vendors run a floor for exactly this reason.

A worked example of what overage does to ARPA

Take an account with a 60,000 dollar annual commit at an realized rate of 0.006 dollars per unit, so 10 million committed units. Overage is priced at 0.0075, which is 25 percent above the committed rate.

That is saas-marketing.net arithmetic with the method shown above, not a benchmark. The point it makes is the one that matters for planning: a 20 percent overage volume produces a 25 percent revenue lift on that account, which flows straight into net revenue retention with no sales involvement. The mirror image is also true. The underuse row shows why the commit floor is the only thing standing between you and a bad quarter, because customer demand can fall and your revenue cannot follow it down.

OpenView’s benchmark work found usage based companies reporting median net revenue retention roughly ten points above seat based peers. The mechanism is exactly the table above. What that research does not say, and what vendors quoting it usually omit, is that gross retention is often slightly worse: consumption customers can shrink without churning, and they can also leave more cheaply because there is no seat investment holding them.

Preventing bill shock, which is where the churn comes from

Consumption churn is rarely about the price. It’s about surprise. A finance leader opens an invoice that is 3.4 times last month’s and the vendor relationship becomes adversarial in one email.

What it does to sales comp and the finance close

Two operational costs nobody puts in the business case.

Sales compensation has to pay on committed value, not consumed value. Pay on consumption and reps stop caring after signature, because the money now depends on a customer behaviour they cannot influence. Pay on commit and reps sandbag the commit to make it easy to hit. The workable structure is most of the commission on commit at signature, with a smaller accelerator on year one overage or on the renewal uplift. Land it in writing before the model launches, because renegotiating a comp plan mid year costs you reps.

The finance close gets harder. Revenue is no longer known on day one of the month. You need usage finalised, rated and reconciled before invoicing, which typically adds two to four days to close. Most teams solve this with a metering and billing layer rather than building it: Stripe Billing, Metronome, Orb and Lago all exist for this reason, and the pricing and billing tools comparison covers where each one fits.

The instrumentation you need is not optional. An event pipeline with idempotency, an entitlement service that knows what each account is allowed to do, a usage ledger that is the single source of truth for rated consumption, and invoice preview. Four systems. Budget a quarter of engineering time minimum, more if your product wasn’t built to emit structured events.

Migrating off flat fees without a churn spike

Never flip the whole base at once. The sequence that works: launch the new model for new logos only, run it for two quarters to find the pricing bugs on customers who have no expectation to violate, then move renewals in cohorts.

For each cohort, show a shadow bill for a full quarter. The account sees what they would have paid under the new model alongside what they actually paid. That does two things. It surfaces the accounts who would pay materially more, so you can handle them individually rather than discovering them at renewal, and it removes the feeling of a change being done to them.

Guarantee that year one under the new model costs no more than the current contract. It sounds expensive. It is much cheaper than the alternative, and it converts the conversation from a price rise into a structure change. The accounts who would pay less will tell their peers, which does more for adoption than any announcement post.

Check the readiness list before you commit to a date, and run the internal version of the pricing change readiness checklist with support and finance in the room, not just product. Then rewrite the pricing page properly using a pricing page spec, because a consumption pricing page that does not include a calculator loses to one that does.

Where to start

If you have flat fee pricing today and you are considering the move, do the metering work first and decide the unit second. Instrument the three candidate units, run them silently for a quarter, and look at the distribution across your customer base. A unit whose consumption varies 200x across similar sized accounts is a bad unit, and you can only learn that from data.

Then model it. Take your twenty largest accounts, apply the proposed structure to their actual past twelve months of consumption, and see what happens to revenue and to the outliers. If three accounts would see a bill double, you have a design problem, not a communication problem. The broader context sits in the SaaS pricing strategy hub, and the head to head on seat based versus usage based is the right next read if you are still deciding, alongside the current adoption data.