Usage-Based vs Outcome-Based Pricing for AI
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Usage-based pricing charges for what a customer consumes: tokens, API calls, minutes of audio, documents processed. Outcome-based pricing charges for what the customer gets: a ticket resolved, a meeting booked, a claim recovered. Both break from the per-seat habit of classic software, and both are being tried by AI companies because a seat no longer tracks the value or the cost of an AI product.
The two get lumped together as "new AI pricing," but they put risk in opposite places. Under usage pricing, the buyer carries the risk that the product won't work well, because they pay for the consumption either way. Under outcome pricing, the seller carries it, because no result means no invoice. That one difference drives almost every other design decision.
This is the hub for the pricing section of this collection. It defines both models, places them on a spectrum, covers how outcomes get defined and attributed, and ends with the contract mechanics that keep either model from blowing up. The sibling articles go deeper on credit-based pricing, per-seat pricing in the AI era, AI agent pricing models, and hybrid pricing.
Why AI pushes vendors off per-seat pricing
Per-seat pricing worked because most business software made people more productive, so more people meant more value and more revenue. It was also easy to budget. Bain & Company's October 2025 analysis of per-seat pricing makes the case that AI weakens both halves of that logic, along two dimensions: the value it delivers and the cost structure it imposes.
On value, many AI features and agents work in the background with little or no human involvement. If a customer needs fewer people to run the software, headcount stops being a sensible meter. And one seat can now deliver far more value, or value unrelated to seats at all.
On cost, Bain points out that model inference, fine-tuning, and AI-specific R&D all carry real expense, and that vendors need to monetize AI features in a way that more than covers what usage costs them. A seat price is flat. Inference cost isn't. So a heavy user on a flat plan can cost more than they pay.
Bain's own conclusion is more careful than the slogan "seats are dead." It calls that an overstatement and says the sentiment is not completely off base. We cover where seats still make sense in per-seat pricing in the AI era.
Usage-based pricing, defined precisely
Usage-based pricing ties the price to a measured unit of consumption. The unit is something the vendor can count and the buyer can see: a token, an API call, a transcribed minute, a generated image, a processed page, a GB of storage. Charges scale with the count, usually with volume tiers or committed amounts. The general concept predates AI, and our guide to usage-based pricing covers it from the SaaS side.
For AI, usage pricing has three real strengths.
- It tracks your cost. If each call costs you compute, charging per call keeps revenue and cost moving together, which protects gross margin.
- It's easy to start. A buyer can try the product with a small bill and grow into it. No one has to agree on what "success" means before the first invoice.
- It's simple to meter. Counting calls or tokens is mostly an engineering task, not a negotiation.
It also has weaknesses. The buyer pays for work whether or not it's useful, so a failed or low-quality output still costs money. Bills are hard to predict, and finance teams dislike that. And a consumption unit like a token is something customers struggle to connect to business value. Kyle Poyar's 2026 survey of 230 B2B software and AI companies found that usage-based and outcome-based companies complain most about how hard it is to forecast and predict revenue.
Outcome-based pricing, defined precisely
Outcome-based pricing ties the price to a result the customer cares about, and the vendor gets paid only when it happens. The result has to be a discrete, verifiable event: a support conversation resolved without a human, a qualified meeting booked, an invoice collected, a claim paid out.
Its strengths mirror usage pricing's weaknesses.
- The buyer's risk drops. No result, no charge. That makes the first purchase far easier, especially for a skeptical buyer or a new vendor with no track record.
- The price maps to value. The customer can compare the fee to what the result is worth, or to what a person would have cost.
- It signals confidence. Poyar notes that outcome pricing tells the market you stand behind the product, and it gives the vendor a built-in reason to keep improving the success rate.
The costs are real, though. The vendor pays for every attempt, including failures. The customer has to agree on what counts as an outcome. And the vendor needs the instrumentation to prove it caused the result. That's why outcome pricing is still rare. In Poyar's 2025 survey, 5 percent of participants said outcome-based was their primary pricing model, while 25 percent expected it to be by 2028. Metronome's 2025 field report on AI pricing reached a similar conclusion from interviews: truly outcome-based pricing remains rare, because many enterprise buyers are uncomfortable tying spend directly to outputs.
The spectrum between them
Usage and outcomes aren't two boxes. They're the ends of a line, and most real products sit somewhere on it. Poyar's survey commentary describes the trend as a move away from charging for access (seats) and toward charging for the work delivered by a combination of software and AI agents. A useful way to read that line is in four steps.
| Step | What you meter | Example unit | Who bears the performance risk |
|---|---|---|---|
| Access | Who can use it | Seats, licenses | Seller (price is fixed) |
| Input-based | Consumption of resources | Tokens, calls, compute minutes | Buyer |
| Output or work-based | Units of work produced | Documents drafted, conversations handled, pages processed | Mostly buyer |
| Outcome-based | Verified results | Tickets resolved, meetings booked, dollars recovered | Seller |
The middle two steps are where the confusion lives. Charging per conversation handled is a work-based price: it counts the work, not whether the customer's problem was solved. Charging per conversation resolved is an outcome price. The unit changes by one word, and the risk changes sides. Poyar's 2025 report makes the same distinction, observing that some models labeled outcome-based are better understood as work-based pricing, while others are truly success-based, where the vendor takes a cut of the upside.
Moving right on the spectrum generally increases the value you can capture and the risk you carry. Moving left makes revenue more predictable and costs easier to cover. Neither direction is better in the abstract.
How outcomes get defined and attributed
The hardest part of outcome pricing isn't the price. It's agreeing on what you're pricing. Poyar's CAMP framework from the 2025 report is a clean checklist of what has to be true for it to work. Outcome-based pricing needs consistency, attribution, measurability, and predictability.
- Consistency: Do all customers value the same outcome, or does every contract need a custom definition?
- Attribution: Will the customer give your product credit for the result, or believe they drove it with a small assist from you?
- Measurability: Can you measure and report the outcome in real time, or does it depend on customer reporting, A/B testing, or a proof of concept?
- Predictability: Can you forecast results with reasonable accuracy, or do they vary widely from customer to customer?
Two practical rules follow from that.
Define the outcome as an event, not a feeling. "Customer satisfied" can't be billed. "Conversation closed with no human reply and no reopen within seven days" can. The reopen window matters, because it stops you from billing for answers that didn't stick.
Decide attribution before you sign. If a human agent touches a thread, who gets the credit? If a meeting was booked by your system but the prospect was already in a sales sequence, is it yours? Write the rule down, and make sure both sides can pull the same log to check it. Bain warns that vendors can't price on usage or outcomes if they don't know what customers are using or achieving, which is why it tells companies to build product telemetry early.
Outcomes that depend on things you don't control are a poor fit. Revenue closed, for example, depends on the customer's sales team, pricing, and market. A narrow, early-funnel result is usually safer to bill than a distant business result.
Risk sharing between buyer and seller
Every pricing model decides who eats which risk. It helps to name four.
- Performance risk: the product doesn't work well. Usage pricing puts this on the buyer, outcome pricing on the seller.
- Volume risk: consumption is higher or lower than forecast. Usage pricing exposes the buyer to a surprise bill, and the seller to a shortfall.
- Cost risk: the seller's delivery cost rises. Usage pricing passes it through. Outcome pricing keeps it with the seller.
- Measurement risk: the two sides disagree on what happened. Usage has little of this. Outcome pricing has the most.
Bain illustrates a related buyer-side problem with a worked example. A vendor pitches a $40,000 AI agent that could eventually replace an $80,000 employee. In the short term, the customer still needs both while it evaluates results, so its costs rise by 50 percent for an undefined period. Bain suggests vendors bridge that gap with delayed payments, flexible contracts, or performance guarantees. That's risk sharing in practice: the seller takes on some of the buyer's transition risk to close the deal.
Margin exposure from inference costs
Pricing and margin are the same conversation for AI. Poyar's 2026 survey found that internal costs and margins were the single most important factor in pricing AI capabilities, selected by 54 percent of respondents. The median target gross margin for AI products was about 50 percent, and only 12 percent aimed for SaaS-like margins of 80 percent or more.
That framing explains the exposure each model creates.
Usage pricing keeps revenue tied to cost, so margin per unit stays roughly steady. The risk is a unit that doesn't map to your real cost. If you charge per call but some calls are ten times more expensive to serve than others, heavy or complex users quietly erode your margin. Metronome's report quotes a revenue operations lead making the point bluntly: seat overages are foregone revenue, but AI overages are real money the company has to eat.
Outcome pricing breaks the link between cost and revenue. You earn the same fee whether a result took one attempt or twenty. If your success rate falls, or the cost of a failed attempt rises, margin shrinks while price stays flat. If your success rate climbs or cost per attempt drops, margin widens. So outcome pricing is a bet that you can keep making delivery cheaper and more reliable. Model it before you offer it: fee per outcome, minus cost per attempt divided by success rate. For the underlying math, see unit economics.
When each model fits
| Situation | Better fit | Why |
|---|---|---|
| Developers integrating a capability into their own product | Usage-based | Buyers expect metered billing, and cost per call is steady |
| Early product, unclear value metric | Usage-based, often with credits | Cheap to start, easy to meter, and you learn what customers value |
| Narrow, countable result with an unambiguous definition | Outcome-based | Verification is simple and the buyer sees the value immediately |
| Result depends heavily on the customer's own process | Usage or hybrid | Attribution disputes will outweigh the benefit |
| New vendor with little proof, selling to a cautious buyer | Outcome-based or a platform fee plus a success component | Lowers the buyer's risk of trying you |
| Buyer needs a fixed budget line | Hybrid with commitments and caps | Predictability beats purity |
| Cost per attempt is volatile or high | Usage-based | Outcome pricing would expose your margin |
| You can't yet instrument and audit outcomes | Usage-based | You can't bill what you can't prove |
Hybrids are where most of the market is landing. In Poyar's 2026 data, 37 percent of companies had hybrid pricing, up from 25 percent twelve months earlier, and Bain's study found that most of the SaaS vendors it analyzed had layered an AI meter on top of seats rather than switching outright. Our article on hybrid pricing for AI products covers how those structures are built, and AI agent pricing models looks at how the choice plays out when the product is an autonomous agent.
Common contract mechanics
The pricing model is only half the deal. The contract terms decide whether it survives real use. Poyar's 2025 report catalogs the common structures, and a few matter most for these two models.
Minimums and commitments. A buyer commits to a usage level or tier, typically "use it or lose it." There are variations: high water-mark billing, where customers drop into overages as soon as they exceed the plan, and drawdown, where usage is consumed flexibly like a gift card. Poyar warns that fear of overages and fluctuations encourages sales to over-sell and customers to over-buy.
Caps. Pay-as-you-go with a cap limits a buyer's potential spend. Poyar notes it's increasingly seen with outcome-based models where outcomes are unknown in advance. Metronome's report also describes soft and hard usage limits as guardrails that let customers protect themselves from unexpected bills. A cap makes outcome pricing far easier to buy, but it also caps your upside, so set it with your cost in mind.
Platform fees. A base fee covers access, support, and advanced features, with usage or outcomes on top. A platform fee also gives the vendor a floor of revenue to cover costs that don't scale per use.
Success bonuses. A traditional subscription fee, plus a bonus or commission when the customer gets a better return than expected. It's a gentle entry point for buyers wary of fully variable pricing.
True-ups and adaptive tiers. Under a true-up, actual usage is reconciled against the commitment at set intervals, and the difference is billed or credited. Under an adaptive flat rate, the customer uses freely within a contract and the tier resets at renewal based on actuals. That's predictable for the buyer but leaves the vendor carrying the cost in the meantime.
Outcome clauses. For outcome pricing, put these in writing: the exact event definition, the observation window (for example, no reopen within seven days), the attribution rule, the data source both sides will audit, and a dispute process with a deadline.
Whatever you choose, keep the structure simple enough that a buyer can explain it to their finance team in two sentences. Poyar's 2026 data shows the cost of complexity: companies with hybrid pricing are generally the happiest with it, but struggle to explain their pricing to customers.
Key Facts: Usage-Based vs Outcome-Based AI Pricing
- Usage-based pricing charges per unit consumed (tokens, calls, minutes). Outcome-based pricing charges per verified result (a ticket resolved, a meeting booked). Under usage pricing the buyer carries performance risk. Under outcome pricing the seller does.
- Of 30-plus SaaS vendors Bain studied, roughly 35 percent raised seat prices by bundling AI, about 65 percent layered an AI meter on seats, and none had fully shifted to usage or outcome pricing (October 2025).
- 37 percent of 230 surveyed B2B software and AI companies used hybrid pricing in 2026, up from 25 percent a year earlier (Growth Unhinged, May 2026).
- 5 percent said outcome-based was their primary model, and 25 percent expected it to be by 2028 (Growth Unhinged, 2025 survey).
- Median target gross margin for AI products was about 50 percent, and only 12 percent targeted 80 percent or more (Growth Unhinged, 2026).
- Outcome pricing needs consistency, attribution, measurability, and predictability (the CAMP framework).
- Truly outcome-based pricing remains rare among enterprise AI deals, per Metronome's 2025 field report.
A short decision path
If you're choosing now, work through these questions in order.
- Can you count something that tracks your cost? If yes, you have a usage meter. Start there.
- Can you define a result in one sentence, as an event both sides can check? If no, stay on usage or work-based pricing.
- Can you instrument it and keep an audit trail? If no, outcome pricing will turn into disputes.
- Do you know your cost per attempt and success rate? If no, don't price on outcomes yet. Model the margin first.
- Can the buyer budget for it? If no, add a commitment, a cap, or a platform fee.
Most companies end up with a base fee, a usage or work component, and sometimes a success component. That isn't indecision. It's a way to share risk in proportion to what each side can control. For broader context on where these choices sit among other AI startup models, see AI startup business models explained, and for the foundations of charging by value, see value-based pricing.
Related Reading

Co-Founder & COO
On this page
- Why AI pushes vendors off per-seat pricing
- Usage-based pricing, defined precisely
- Outcome-based pricing, defined precisely
- The spectrum between them
- How outcomes get defined and attributed
- Risk sharing between buyer and seller
- Margin exposure from inference costs
- When each model fits
- Common contract mechanics
- A short decision path
- Related Reading