The pricing conversation usually starts with a spreadsheet: what do we charge per seat, per call, per resolution? That is the second question. The first is who absorbs the cost of a customer who uses the product ten times harder than the median account. Every AI pricing model is a different answer to that question, and the answer decides your gross margin, your forecast, and how your sales team behaves under pressure.
There is no universally correct model. There is a correct model for your cost curve, your buyers, and how quickly your product changes. The three common shapes are seats, usage, and outcomes. Each one moves risk somewhere. The work is choosing where you can carry it.
The model is a bet on who carries the variance
Inference costs are variable in a way that traditional software costs are not. A SaaS seat costs roughly the same to serve whether the user logs in twice a week or twice an hour. A model call costs money every time, and a long agent run can cost more than a month of seat revenue in an afternoon. That asymmetry is the whole problem.
Three properties decide which model fits. First, how dispersed usage is across accounts: if your top decile consumes fifty times the median, seat pricing is a slow-motion margin problem. Second, how much your unit cost falls as models and hardware improve: if cost per request drops every quarter, a usage price that looks generous today may be comfortable in a year. Third, how observable the outcome is: a resolved support ticket is countable, a better marketing decision is not. Add a fourth: how much procurement power your buyer has. Large buyers will demand caps regardless of the model you prefer.
Seat pricing bets that usage stays modest
Seat pricing is the easiest to sell because it matches how enterprises already budget. Headcount is planned, approved, and audited. A per-seat price produces predictable recurring revenue, a simple invoice, and a sales motion your team already knows. It also makes expansion revenue legible: more users equals more money.
The risk is that seat pricing gives away unlimited consumption for a fixed fee. Your best customers, the ones who integrate the product into daily work, become your worst accounts on margin. A ten-seat account at $45 per seat produces $450 a month whether it makes 400 requests or 40,000. At an assumed $0.05 of variable cost per request, 9,000 requests consume the entire $450 in variable cost before fixed costs are counted.
Seat pricing can work, but only with a real boundary. Either publish a fair-use allowance that everyone can see, or charge for seats plus overage above an included volume. Unlimited is not a pricing model. It is a promise that your product will not be used much, and it fails exactly when the product starts to work.
Usage pricing passes the meter to the buyer
Usage pricing is the closest match to your cost structure. Price per request, per thousand tokens, per agent run, or per minute of compute, and gross margin stays roughly stable as volume grows. The meter also creates an honest conversation about value: a customer who spends more is getting more.
The cost is forecastability on both sides. Buyers hate uncapped variable spend, and finance teams will treat an open-ended meter as a risk to be negotiated down. Expect requests for committed volumes with a discounted rate, a hard spend cap, and alerting before the cap is hit. Those requests are reasonable, and you should design for them rather than resist them.
Usage pricing also puts a spotlight on metering quality. If the invoice cannot be traced to individual events, every dispute becomes a relationship problem. Define the billable unit in the contract, log an auditable record for each unit, state how failed requests are treated, and make the customer's own dashboard match your invoice to the cent. That plumbing is unglamorous and it is the difference between a usage model that scales and one that leaks revenue through credits.
Outcome pricing sells the result, not the access
Outcome pricing charges for what the customer actually wants: a resolved conversation, a processed claim, a qualified meeting, a recovered payment. It is the strongest commercial story because the buyer can compare the price to the cost of the human process it replaces, and the comparison is usually flattering.
It is also the hardest to operate. You need a definition of the outcome that both sides will accept, a measurement method the buyer trusts, and a short enough feedback window that the invoice does not arrive before anyone knows whether the work succeeded. Where those conditions fail, outcome pricing becomes a discount with extra steps: you absorb the cost of every attempt and get paid only when the customer agrees the attempt worked.
The subtle exposure is that your revenue now varies with your own quality. A model upgrade that improves the product can change resolution rates, and a regression can cut revenue twice, once through cost and once through missed billable outcomes. Budget credits for disputed outcomes, cap the share of revenue that depends on a single customer's measurement, and keep the definition narrow enough to test. Outcome pricing works best where the event is machine-observable and the counterfactual is clear.
What enterprise procurement will test
Whatever you choose, the contract will be read by someone whose job is to remove risk. Expect the following, in roughly this order. A spend cap or a committed volume with a true-up at renewal. Price protection for twelve to twenty-four months. Advance notice before you change the underlying model, because quality and cost can move together. A service level tied to latency and availability rather than to answer quality, since quality is hard to arbitrate. Audit rights on metering, plus a reconciliation file. Data residency and retention terms. Termination for convenience with a short notice period.
Two clauses deserve your attention as a seller. First, model-change notice: a customer who built a workflow on one model's behavior needs time to retest, and offering that notice is a cheap way to win trust. Second, outcome definitions: if you sell resolutions, the definition belongs in the contract with worked examples, not in a help-center article. For buyers, the mirror image applies. Ask what happens when the model changes, ask for the metering reconciliation, and ask whether the outcome definition can be edited unilaterally.
A worked example, with assumptions labeled
To make the trade-off concrete, here is a comparison across three usage profiles. Every number is an assumption chosen to keep the arithmetic readable, not a market price. Assume a support assistant with an average account of 2,200 requests a month, a light account at 800, a heavy account at 9,000, variable cost of $0.05 per request, and $3.00 a month of fixed cost per account. Assume the outcome model bills $1.80 per resolved request, that 40% of requests resolve, and that 12% of billed resolutions are credited back after disputes.
| Pricing model | Light account | Typical account | Heavy account |
|---|---|---|---|
| Seat: $450 per account per month | $450 revenue, 90% margin | $450 revenue, 75% margin | $450 revenue, -1% margin |
| Usage: $0.085 per request | $68 revenue, 37% margin | $187 revenue, 40% margin | $765 revenue, 41% margin |
| Outcome: $1.80 per resolution | $507 revenue, 92% margin | $1,394 revenue, 92% margin | $5,702 revenue, 92% margin |
| Cost to serve | $43 | $113 | $453 |
Read the first row closely. Seat pricing looks excellent on light accounts, acceptable on typical ones, and negative on the accounts that love the product most. The margin does not compress gradually. It inverts, and it inverts on the customers you cannot afford to lose. The usage row is boring in the best sense: the margin barely moves, and revenue tracks adoption. The outcome row shows the highest margin, and the number is real, but it depends on a measurement system that both parties accept. The margin is not the constraint in that row. Revenue concentration and definition risk are.
The practical conclusion is that the models are not mutually exclusive. A common structure is a platform fee that covers fixed cost, a seat or usage component that covers predictable volume, and an outcome component that captures upside. Hybrids are harder to explain, so keep the invoice to one page and the logic to one sentence.
What to do next
- Plot usage per account for your last ninety days. If the top decile is more than ten times the median, do not ship pure seat pricing without an allowance.
- Compute cost to serve per request, including retrieval, retries, and evaluation runs, not just tokens. That number sets your floor.
- Pick the model that matches your buyer's budgeting process, then add the one guardrail that model lacks: a fair-use boundary for seats, a cap for usage, or a narrow definition for outcomes.
- Write the metering contract before you write the pricing page. If you cannot reconcile an invoice to events, you cannot defend the price.
- Model a price cut of 30% and a cost increase of 30% at renewal. If either breaks the business, the model is too concentrated.
The pricing decision is a decision about which risk you can manage. Choose the one your operations can carry, and say so plainly in the contract.
