Pricing AI Products: Seats, Usage, or Outcomes
Compare five ways to price AI products, including seats, usage, credits, and outcomes, against customer value and the cost to serve.
A flat charge can leave heavy users costing more to serve than their revenue covers when AI costs vary sharply by account.
AI features can create this gap inside a per-seat product. The same seat fee can cover very different amounts of model use and compute cost. The charge metric therefore affects both product adoption and gross margin.
Where per-seat pricing can strain margins
AI features can reduce gross margins because model calls incur compute costs.1 The unit economics of AI features covers the cost side; this article focuses on how to charge when marginal costs exist.
A seat collects the same fee whether its user triggers ten model calls a month or ten thousand, so revenue and cost can stop moving together. Lighter users may subsidize heavier users. Compare those costs across your own accounts before deciding whether a different charge model would help.
Bessemer describes usage-, output-, and outcome-based models as common options for AI-native companies.2 Seats can still fit products where AI assists human work. When the model performs more of the work, a metric tied to usage or a measurable customer outcome may map more closely to value and cost.
Access, usage, or outcomes. Each charges for something different. Check both what the customer values and what it costs you to deliver.
The five models, compared
Bessemer sorts AI charge metrics into three families: consumption (per API call, per token), workflow-based, and outcome-based (per successful outcome)2. On the ground, products ship five recognizable variants.
| Model | Buyer predictability | Margin protection | Buyer comprehension | Best for |
|---|---|---|---|---|
| Per-token | Depends on token volume | Can track token costs closely | Low unless the buyer is technical | LLM APIs, developer products3 |
| Per-query / per-action | Medium | Medium; complex tasks compress it | High | Discrete jobs: per image generated, per document summarized3 |
| Credits | Depends on allowances and task rates | Depends on credit prices and task costs | Medium | Mixed workloads where tasks vary widely in cost3 |
| Seat + usage hybrid | High on the base, variable on top | Medium-high | High | Platform fee plus consumption; teams uncertain about usage patterns23 |
| Outcome-based | Depends on outcome volume | Variable; unsuccessful work still costs money | Depends on a clear outcome definition | Measurable, attributable outcomes; hardest to operationalize3 |
Three rows deserve a closer look.
Per-query pricing abstracts tokens into a unit the user can count: an image generated, a document summarized3. The buyer can estimate a bill from expected task volume, but margins may compress when usage skews toward complex tasks that burn more compute per unit than you priced for3.
Credits let customers buy an allowance and spend it at published task rates. For example, a basic image might cost 1 credit and a high-res video 50. Margin still depends on whether those rates cover the work required. The unit stays stable for the buyer even as your underlying cost differs by task type.
Outcome-based pricing charges for an agreed result. It needs a clear definition of success and a way to decide when your product earned the fee. Costs can vary even when the outcome price stays fixed.2
Choose a unit the buyer can estimate. Token billing may fit developers buying model access. Other customers may find tasks, credits, or outcomes easier to budget for. If your customer cannot estimate next month's bill before using the feature, you have priced in your unit instead of theirs. Translate to a unit they recognize: queries, credits, or outcomes.
The trade as you move toward outcomes
Moving from consumption toward outcome-based pricing involves a trade-off between value alignment and cost predictability.2 Under an outcome model, revenue depends on results the provider may only partly control.
Consumption pricing can also hinder adoption. Bessemer reports that Leena AI moved away from consumption pricing after customers limited use to control costs.2 The risk is that customers use the product less to avoid a higher bill, reducing the value they receive.
Outcome pricing can reduce concern about paying for unsuccessful attempts, but the total bill still depends on how many billable outcomes occur. You need a measurable outcome (a resolved ticket, a filed claim, a collected invoice) and an attribution story for it. If the AI drafted the response and a human rewrote half of it, who earned the fee? Agree on that answer before billing.
Bessemer highlights legal products such as EvenUp and Legora as examples where hybrid pricing can connect charges to measurable work or outcomes.2 The same logic underpins agent pricing: agents that take over a defined piece of work get priced against the cost savings or the human-equivalent output, because that ROI is tangible enough to put on an invoice2.
The outcome checklist before the first invoice. Define the outcome in terms the customer already reports on. Agree on attribution for mixed human-AI work before launch, not after the first dispute. If either remains unclear, consider charging for a defined task while you learn how to measure the outcome.
How to choose for your feature
Four questions sort most cases:
- Is the outcome measurable and attributable? If the customer already tracks the result in their own reporting, outcome-based pricing is on the table. If not, it is off.
- Does the buyer understand the unit? Engineers can budget in tokens. A support lead budgets in tickets. Price in the unit the budget owner thinks in.
- Can you meter it reliably? Usage billing needs production-grade metering, with disputes, refunds, and edge cases handled. Check that metering handles missing events, duplicates, and corrections before using it for invoices.
- Does usage track value? When the tenth query is worth as much as the first, usage pricing aligns well. When value front-loads (the first answer matters, the rest are refinements), a per-query meter punishes exploration.
If you cannot answer all four with confidence, consider a hybrid. A base subscription can cover predictable costs and budgeting needs, while a usage or outcome component can scale with costs or value. Test the model against the product's actual usage distribution before relying on it.
Whatever you choose also changes the shape of your revenue. Seat revenue varies with customer count, seats, pricing, and retention. Usage and outcome components turn MRR into a range that moves with adoption, seasonality, and how successful your customers are. Before committing, model your current MRR against a scenario where 20-30% of revenue shifts to a variable component, and check what the swing does to your growth picture:
The charge metric also feeds your unit economics downstream. A model that lifts ARPU on heavy users changes LTV, which changes how much you can afford to spend acquiring them; the full chain is in CAC and LTV mastery.
Migrating a seat-priced product
Adding AI charges to a seat-priced product requires a transition plan for customers accustomed to the current bill.
Show the meter before you bill on it. Ship usage visibility (a dashboard showing each account's AI consumption) before introducing a usage charge, with enough time for customers to understand their consumption. Customers learn their number while it costs nothing, and you learn the real distribution. Discuss the change early with accounts facing the largest increases.
Start with new customers. Introduce the usage or hybrid plan for new signups while existing customers stay on current terms. This is the same test-with-new-customers discipline from the pricing strategy guide, and the transition guidance there can help you plan notice, existing-customer terms, and annual offers.
Set a clear allowance. Use measured consumption to decide what the base plan includes and when extra charges apply. Check which accounts would be affected.
Watch usage trends. If usage drops after a pricing change, investigate whether customers are limiting use because of cost uncertainty, even when their total bill has not changed.2 Consider usage alongside churn, support requests, and customer feedback.
Check pricing and costs together. A pricing change may improve margins, but the result depends on usage, customer response, and delivery costs. Review the cost assumptions covered in the unit economics of AI features alongside the proposed price.
FAQ
Why are AI companies moving away from per-seat pricing? A flat seat fee may not cover heavy AI usage. Usage or outcome charges can better match some products' costs or value, while seats can still fit products that assist human work. Compare the options using your own accounts and costs.
When does outcome-based pricing work for AI products? When the outcome is measurable in terms the customer already reports on, and attribution for mixed human-AI work is agreed before launch. It does not guarantee higher margins: attempts that fail to produce a billable outcome still cost money.
What is credit-based pricing for AI features? The customer buys a budget of credits and each task draws against it at a rate you set: a basic image might cost 1 credit, a high-res video 50. Credits keep the unit stable for the buyer while letting you reflect the real compute cost of each task type.
Should I ever price in tokens? Token pricing can fit an LLM API or developer product when buyers can estimate token use. For other customers, consider a unit closer to their work, such as queries, credits, or outcomes.
How do I move an existing product from seats to usage pricing? Show usage dashboards before billing on them, introduce the new model for new customers first, and keep existing customers grandfathered while you watch conversion and usage. The change-management mechanics are in the pricing strategy guide.