Pricing models and their blast radius

The pricing unit is a schema

A pricing decision is usually made in a room with no engineers in it, written down as a page on a website, and handed over as a configuration task. Then it turns out that the unit chosen in that room has to be measured exactly, at high volume, in a way that survives retries and late-arriving events; reconciled monthly against a revenue ledger; explained to a customer disputing an invoice; forecast a quarter ahead; and preserved unchanged for every account signed under it, forever. That is not configuration. It is a data model with unusually harsh correctness requirements, and it is load-bearing for the entire company.

Four properties decide whether a unit is buildable, and they are worth checking before the price is announced rather than after. Can it be measured exactly? Not approximately, exactly, in a way two systems will agree on. Can the customer predict it before they commit? If not, a finance team at any serious company will struggle to approve it. Does it move with your cost? If cost varies by three orders of magnitude and price does not, you have a margin distribution rather than a margin. Does it move with their value? A unit that grows while the customer's benefit does not is a renewal conversation you will lose.

Almost no unit satisfies all four. Seats are predictable and easy to measure and track cost poorly for anything with heavy per-user compute. Tokens track cost closely and are almost impossible for a buyer to forecast before they start. The design work is choosing which property to sacrifice deliberately, and then building something to compensate for the sacrifice.

Unit	Fits when	What it forces you to build	How it fails
Per seat	Usage per person is stable and the product is a workspace	Identity, seat assignment, true-up logic	Heavy users subsidised by light ones; shared logins
Per unit of work document, run, ticket, extraction	The unit matches something the customer already counts	Exact-once metering, a definition of a failed unit	Arguments about whether a retry counts
Per token or compute-second	Cost genuinely varies per call and buyers are technical	Metering, spend caps, budget alerts, cost attribution	Unpredictable for the buyer; hard to approve in advance
Tiered subscription	Usage clusters into a few bands	Overage handling, upgrade prompts, band definitions	Every customer sits just under a boundary
Prepaid credits	You need commitment up front and variable consumption after	Balance ledger, expiry policy, revenue recognition	Breakage disputes; credits as a second currency to support
Outcome-based	The outcome is jointly observable and attributable	An agreed measurement system both sides trust	Attribution arguments; you are paid for their execution too

Cost-following units, and the margin distribution nobody looks at

For anything running inference, cost per customer is not a number, it is a distribution with a long tail. Two accounts on the same plan can differ by orders of magnitude in what they consume, because one sends short prompts against a small corpus and the other pastes in hundred-page documents and calls it in a loop. Charge both the same monthly seat price and average gross margin will look fine while a quarter of the accounts are unprofitable.

So plot it before defending the pricing. Gross margin per account, sorted, as a distribution rather than a mean. Then look at the bottom decile and ask whether those accounts are strategic, seasonal, or simply mispriced. The answer is usually mixed and the mix is the useful part.

Three ordinary repairs, in increasing order of disruption. Add a usage allowance to the subscription with metered overage above it, which keeps predictability for most customers and stops the tail from being free. Add a fair-use ceiling with a defined consequence you are willing to enforce, which is only worth writing if you will actually enforce it. Or move the unit itself, which is the largest change on this page and should be a deliberate project rather than an adjustment.

Metering is a ledger, not a counter

The most common architecture we are asked to repair is an incremented counter in a table. It is simple, it is fast, and it cannot answer the question that matters when a customer calls: what exactly did we charge for, and when did each of those things happen.

Build it as an append-only event stream instead. Every billable event is a row with an event id, an account, a timestamp for when it happened, a timestamp for when it was recorded, the quantity, the unit, and enough context to explain it. Nothing is updated in place. Aggregates are derived and can be recomputed from the events at any time, which is the property that makes a correction possible without a spreadsheet and an apology.

Idempotency is not optional. The pipeline will deliver some events twice, because at-least-once delivery is what distributed systems give you. A unique constraint on the event id turns a duplicate into a no-op. Without it, a retry storm during an incident becomes a billing incident on top of the original one, and those are remembered longer.

Keep both timestamps. Event time and ingestion time answer different questions, and a bill computed on ingestion time will silently move usage into the wrong month whenever a queue backs up over a period boundary. Decide the cut-off policy explicitly: how long after a period closes will you still accept events for it, and what happens to something that arrives after that.

Decide what a failure costs. If a request errors, a job is cancelled, or a model returns nothing useful, is it billable? There is a defensible answer either way, but there has to be one, it has to be in the documentation, and the metering code has to implement the same one the documentation states. This single question generates more support load than the rest of billing combined.

The three numbers that have to agree

Every usage-priced business ends up with three counts of the same thing: what the product's own telemetry says, what the billing system charged, and what the finance ledger recognises. They will diverge. The question is whether you find out from a reconciliation job or from a customer.

Name one of them authoritative — almost always the billable event stream — and derive the others from it rather than computing them independently. Then run a scheduled reconciliation that compares them per account per period and raises anything outside a tight tolerance. A daily job that reports zero for months is worth every hour it took, because the first time it is not zero, it is small.

Two allowances make it survivable. Expect analytics telemetry to disagree slightly with billing, because the former is sampled and the latter must not be; document the expected direction and size of the gap so nobody investigates it monthly. And build a correction path in advance: a way to issue a credit or a rebill that leaves an audit trail, rather than editing an aggregate. The first time a bug overcharges a customer, having that path already built is the difference between an apology and an incident.

Predictability is a feature, and buyers pay for it

Pure consumption pricing is honest and it loses deals. Not because the total is too high, but because a buyer with a budget cannot sign a number that does not exist yet. The objection is rarely stated that plainly; it arrives as delay.

The instruments that fix it are well understood and mostly cheap to build. A committed spend with a discount converts an unknown into a known and gives you a forecastable base. A hard budget cap, with a documented behaviour when it is reached, lets a buyer bound the downside. Alerts at fractions of the budget give them a chance to act. A published cost estimator that takes their real inputs and returns a range does more for an enterprise sale than most of what the marketing site says.

One warning about credits, which are attractive because they take cash early. They create a second currency with its own expiry rules, its own balance ledger, its own disputes, and their own revenue-recognition treatment. If the reason for adopting them is that consumption pricing feels unpredictable, a committed spend with an overage rate gets most of the benefit with a fraction of the machinery.

Elasticity is mostly not estimable from your own history

Somebody will eventually ask what happens to volume if the price moves ten percent, and it is a reasonable question with an unsatisfying answer.

The prices in your history were not set at random. They moved when a competitor launched, when a discount policy changed, when the sales team pushed on a quarter end, when a big customer negotiated. Every one of those events also affected demand directly. Regressing quantity on price across that history estimates a mixture of the price effect and everything that caused the price to change, and the sign can come out backwards: prices rose during the periods demand was strongest, so the naive estimate says raising prices increases sales.

What can be done honestly, in rough order of strength. Randomise price at the point of offer for new customers only, which is clean and raises fairness questions you should answer deliberately before running it. Vary price across regions or segments where a real boundary already exists and comparison is unlikely. Test the fence rather than the level — what is included in a tier, where the boundary sits, whether a feature is bundled — which usually moves revenue more than the number does and is far less sensitive to run. Or ask directly, using a structured pricing survey, and treat the result as an ordering of options rather than a demand curve, because stated willingness to pay is systematically optimistic.

What is not honest is a confident elasticity number pulled from observational history and used to justify a change to every account. If someone shows you one, ask what caused the price variation in the data. The answer is usually the same thing that caused the demand variation.

Grandfathering has a half-life, and it is longer than you think

Every pricing change leaves accounts on the old model. Each legacy plan is a permanent code path in metering, billing, reporting and support, and it will outlive the person who negotiated it.

Two habits keep this survivable. Put a plan version on every account from the first day of the first plan, so a plan is a versioned object rather than a set of columns that get edited. And write the migration policy at the same time as the new price, not two years later: how long the old plan is honoured, what triggers a move, and what the customer is offered in exchange. Migrations that come with something — a higher allowance, a feature, a fixed period at a blended rate — complete. Migrations that are only an increase generate escalations.

Accept as well that some accounts will never move, and decide whether that is acceptable now rather than discovering it during a due-diligence process. The honest question is not how to avoid legacy plans; it is how many distinct ones the company can afford to operate at once.

List price is fiction if the median discount is thirty percent

The number on the website is the start of a negotiation in most business-to-business sales. What matters operationally is the realised price: what customers actually paid, per unit, after discounts, credits, promotions and negotiated terms.

Compute that distribution and look at its shape. A wide spread usually means the price is being set by whoever is in the room rather than by policy, and it makes revenue forecasting far harder than it needs to be because the same signed logo is worth different amounts depending on which representative closed it. The repair is not to forbid discounting. It is to define the ladder — what a discount is exchanged for, who can approve each level, and what is given in return, such as a longer term or a case study — and then to report realised price alongside list price so nobody is planning from a number that no customer pays.

The mistakes we are called in to fix

• Usage stored as an incremented counter, so a dispute cannot be answered without a reconstruction
• No idempotency on billable events, turning one retry storm into a billing incident
• Billing on ingestion time, so a delayed queue moves revenue into the wrong month
• No stated policy on failed or cancelled work, with code and documentation quietly disagreeing
• A flat price over a cost that varies a thousandfold, and nobody plotting margin per account
• Usage visible only on the invoice, thirty days after anyone could have acted on it
• An elasticity estimate from observational history, used to justify a change across the whole base
• Plans edited in place rather than versioned, so no one can say what an account was actually sold

A six-week pass before a pricing change ships

Step four is the one that prevents the bad week. Replaying real usage under the proposed model, per account, tells you exactly who gets a larger bill and by how much, which converts an argument about strategy into a list of named conversations. It also surfaces the accounts whose bill drops by half, which is a different and equally important finding.

Before the price goes live

• The unit can be measured exactly and two systems agree on the count
• Billable events are append-only, idempotent, and carry event and ingestion time
• The policy for failed, cancelled and retried work is written and implemented identically
• Gross margin per account has been plotted as a distribution
• A year of real usage has been replayed under the new model, per account
• Customers can see current usage in the product and in the API response
• Budget caps and alerts exist, with documented behaviour at the limit
• Reconciliation runs on a schedule between telemetry, billing and the ledger
• A correction path exists that leaves an audit trail rather than editing an aggregate
• Plans are versioned objects, and the migration policy is written before launch

Bottom line

The number on the pricing page is the cheapest part of pricing to change and the part that gets all the attention. The unit underneath it is the expensive part: it decides what has to be metered, what has to reconcile, what a support conversation looks like, how forecastable the revenue is, and how much legacy the company carries five years from now. Choose the unit with the engineers in the room, build the meter as a ledger, replay a year of real usage before committing, and give customers a way to see and bound their own spend. Those four make almost every later pricing decision reversible, which is the only property that really matters in a market where the cost side keeps moving.

Frequently asked questions