Three pricing models compete for a product built on top of a model: per seat, per usage, and per outcome. Per seat is the easiest to sell and the fastest to break, because an AI feature carries a 50-60 percent gross margin against the 80-90 percent a traditional SaaS product enjoys, and because roughly 5 percent of users can generate 80 percent of the inference bill. More than 60 percent of AI SaaS companies have already landed on a hybrid: a base subscription, an included allowance that covers about 80 percent of customers, and overage priced at no less than twice marginal cost.
Why per-seat pricing breaks the moment a model is in the loop
Per-seat pricing rests on an assumption that held for fifteen years: the marginal cost of one more user is close to zero. A seat costs storage, a little compute, and support. That assumption dies the moment every click sends tokens to a model. Now the heaviest user in the account is also the most expensive one, and the price you charge does not know that.
The gap shows up in the gross margin line. A classic SaaS product runs at 80-90 percent. A product whose core loop calls a model typically lands at 50-60 percent once inference, retrieval, evaluation and the retry budget are counted. That is not a rounding error. It is a different business, with different funding needs and a different valuation multiple, and pricing is the only lever that closes it. We laid out the full cost structure in what an AI feature really costs.
Worse, the cost is not spread evenly. Usage concentrates in a thin tail. In most products a small minority of users runs the long documents, the deep research jobs, and the loops that call the model eight times before returning an answer. Under per-seat pricing that minority is priced exactly the same as the user who logs in twice a month.
A check you can run this week. Take last month of usage. Sort accounts by inference cost per seat and split them into deciles. Compute gross margin for each decile at your current list price. If the bottom two deciles are negative, or the top decile carries the entire margin of the product, per-seat pricing is already subsidising your worst customers with your best ones. Most teams that run this for the first time are surprised by the size of the spread.
The three models, side by side
Each model is right somewhere. The question is what you are actually selling and what the buyer believes they are paying for.
| Dimension | Per seat | Per usage | Per outcome |
|---|---|---|---|
| What the customer buys | Access for a named person | Volume of work performed | A result that happened |
| Margin risk | High. Cost floats, price does not | Low. Price tracks cost | Medium to high. Depends on your resolution rate |
| Predictability for the buyer | Excellent | Poor without an allowance and alerts | Medium. Depends on their own volume |
| Ease of forecasting for you | Excellent | Medium | Poor in year one |
| Procurement friction | Lowest. Everyone knows the shape | Medium. Finance asks for a cap | Highest. Needs an agreed definition of success |
| Incentive it creates | Buy fewer seats, share logins | Use less of the product | Aligned, if the metric is honest |
| Best fit | Assistive features inside an existing product | Platform and API products, document and media processing | Support deflection, collections, qualified lead generation |
Read the last two rows together. Pure usage pricing has a real defect that rarely gets said out loud: it teaches your customer to use your product less. If you are still in the adoption phase, that is the most expensive incentive you can buy.
The hybrid structure that actually wins
More than 60 percent of AI SaaS companies now price on a hybrid. It is not a compromise, it is the only structure that gives the buyer predictability and gives you a cost ceiling at the same time. Four components, and each one has a number attached.
| Component | What it does | How to set it |
|---|---|---|
| Base subscription | Covers fixed cost and anchors the value conversation | Price it against the outcome, not against the token bill. This is the part that has to survive a competitive comparison |
| Included allowance | Removes bill anxiety for the majority | Size it so roughly 80 percent of accounts never touch the ceiling. Read it off the usage distribution, not off the average |
| Overage rate | Protects margin in the tail | No less than twice marginal cost. If it is below that, the tail eats the deal |
| Threshold alerts | Prevents the surprise invoice that kills renewals | Notify at 80 percent of allowance, in product and by email, with a one-click upgrade path |
The allowance is the component teams get wrong most often, because they size it off the average instead of the distribution. The average is dragged upward by the heavy tail, so an allowance set at the average leaves a third of your customers hitting overage in month one and writing to support. Size it at roughly the eightieth percentile and the shape of the complaint changes completely.
Four tests for a good billing unit
Whatever you meter has to pass all four. A unit that fails even one will produce arguments with customers every month.
The customer understands it without a diagram. Documents processed, tickets resolved, calls transcribed, candidates screened. Tokens fail this test. No buyer outside engineering has an intuition for what a token is or how many their team will use, and units that cannot be estimated in advance cannot be approved by procurement.
It moves with the value they receive. If the customer gets twice the value, the meter should read roughly twice as much. If the meter can climb while value stays flat, you have built a unit that punishes people for your own inefficiency.
It correlates with your cost. Not perfectly, but directionally. If a single unit can cost you five cents or five dollars depending on inputs you cannot see, either segment the unit into tiers or move the variance into the overage rate.
You can count it and defend the count. The number has to be visible to the customer in near real time, reconstructible after the fact, and identical to the number on the invoice. A meter the customer cannot audit will be disputed the first month it goes up.
The failure mode to avoid. Do not meter retries, internal evaluation passes, or your own orchestration overhead. If your agent calls the model six times to answer one question, that is your architecture decision, not the customer purchase. Charge for the question. Then go and reduce the six calls, which is a margin project rather than a pricing one.
When outcome pricing is real, and when it is theatre
Outcome pricing is the most attractive story in the category and the hardest to operate. It only works when four things are true at once.
First, the outcome is measurable without argument. A resolved support ticket that did not reopen within seventy-two hours is measurable. Improved productivity is not. Second, you can attribute it. If three systems touched the deal, outcome pricing will turn into an attribution dispute at every renewal. Third, your success rate is stable enough to forecast. Autonomous resolution rates start conservatively at 40-50 percent for retrieval-based bots, climb 10-20 points with agentic behaviour, and another 20-30 points once the system can actually take action rather than only answer. Until you know where you sit on that curve, outcome pricing is a bet on your own roadmap. Fourth, the unit economics still work at your success rate, not the one on the slide.
The comparison that makes it worth the trouble: AI resolution of a support interaction is commonly published at 0.50 to 2.00 dollars, and lands nearer 5 dollars all-in once infrastructure and human escalation are counted, against 6 to 12 dollars for a human-handled contact. That spread is wide enough to price against directly. Gartner expects agentic systems to autonomously resolve 80 percent of common service issues by 2029, with a 30 percent reduction in operating cost. Where the spread is that clear, outcome pricing is the honest structure. Where it is not, it is marketing.
Changing your pricing without burning the customer base
Most teams reading this already have pricing in market that no longer fits. Four rules make the migration survivable.
Grandfather generously and for a fixed period. Twelve months at the old terms costs you less than one public complaint from a reference account. Put an end date on it so it does not become permanent.
Show the new invoice before you charge it. Run both models in parallel for a full billing cycle and show each account what they would have paid. Accounts that would pay less become your proof points. Accounts that would pay considerably more need a conversation before the invoice, not after it.
Move one variable at a time. Introducing a usage component and raising the base price and adding a new tier in the same release makes it impossible to know which change caused the churn.
Publish the meter before you publish the price. Ship the usage dashboard a quarter early, so that by the time you meter, every customer already recognises the number and trusts it. Pricing changes fail on trust in the number far more often than on the number itself.
The point of all of this is the same point behind the unit model of a digital business: a price that is not connected to a cost structure is a guess. Once the model is in the product, the cost structure moves every week, and pricing has to be built to move with it. If you are defining a new AI feature right now, set the pricing unit at the same time as you set the acceptance criteria — they are the same conversation.
If you want help fitting a pricing model to your own cost structure, that is part of what we do in our financial and growth planning work.
Frequently asked questions
Should I price an AI feature per seat or per usage?
Neither on its own. More than 60 percent of AI SaaS companies use a hybrid: a base subscription that anchors value, an included allowance sized so about 80 percent of accounts never exceed it, and an overage rate set at no less than twice marginal cost. Pure per-seat pricing exposes you to a tail where roughly 5 percent of users drive 80 percent of inference cost. Pure usage pricing gives the customer an incentive to use the product less, which is fatal during adoption.
What gross margin should I expect on a product built on a model?
Typically 50-60 percent, against 80-90 percent for traditional SaaS, once inference, retrieval, evaluation and retries are counted. Plan the pricing, the fundraising and the valuation conversation around that number rather than around the SaaS benchmark. Caching, batching and model routing can move it materially, but they do not close the gap to classic SaaS on their own.
How do I size the included allowance?
From the usage distribution, not the average. The average is inflated by the heavy tail, so an allowance set at the average pushes a large minority of accounts into overage immediately. Set it at roughly the eightieth percentile of monthly usage, alert at 80 percent of the allowance, and give a one-click upgrade path in the alert.
Is outcome-based pricing worth it?
Only when four conditions hold together: the outcome is measurable without argument, you can attribute it to your system, your success rate is stable enough to forecast, and the economics work at your real success rate rather than the projected one. Support deflection usually qualifies, because AI resolution at 0.50 to 2.00 dollars published, or nearer 5 dollars all-in, sits against 6 to 12 dollars for a human contact. Productivity claims usually do not.
Should I meter tokens directly?
No. Tokens fail the most important test of a billing unit, which is that the customer can estimate their spend in advance. Meter something a buyer already understands — documents processed, tickets resolved, calls transcribed — and absorb token variance inside your own margin and your overage rate. Never bill for retries or internal evaluation passes; those are your architecture, not the customer purchase.