Usage and Outcome Pricing: Honest, Dangerous, and Hard to Prove

Pricing software that thinks starts by pricing units of resolved work against variable inference, review, and risk cost.

Two pricing models get held up as the answer to the AI margin problem, and they sit at opposite ends of a spectrum. Usage pricing charges for what the customer consumes. Outcome pricing charges for what the customer gets. Both are improvements on the seat for software that does work. Both are also dangerous, in precisely opposite ways, and the failure modes are mirror images. This chapter takes them seriously enough to show where each one breaks, because the right answer for most companies is not "pick one" but "know exactly what each costs you."

Usage pricing: honest about cost, brutal about adoption

Usage pricing charges per unit of consumption: per token, per API call, per compute-second, per document processed. Its great virtue is alignment with cost. Because your cost is variable per unit, a per-unit price tracks it naturally, and the margin problem from the seat chapter largely disappears: heavy users pay for the cost they create. This is why usage-based public SaaS companies have outperformed, posting 120-plus percent net revenue retention against around 110 for subscription peers and growing revenue faster, per usage-pricing research, and why adoption of usage-based models has climbed sharply across the industry.

So far so good. Now run the Adoption Penalty Test, and watch usage pricing fail in the second mode: it punishes the customer.

Here is the problem in one sentence. Pure usage pricing means the better your product works, the more the customer pays, with no ceiling. A customer who adopts enthusiastically, rolls you out across the team, and runs you hard gets rewarded with a bigger bill. They are being penalized for the behavior you most want. And worse, the bill is unpredictable: it depends on usage they cannot fully forecast, which makes it impossible for their finance team to budget and easy for it to spike.

The cautionary tales are not hypothetical. Snowflake and Datadog both built large businesses on consumption pricing and both became case studies in bill shock. Datadog bills spiral for mid-market teams not because one meter runs away but because several usage meters run concurrently and compound, and Snowflake's elastic credit model produces surprises when usage grows faster than the customer's visibility into it. These are successful companies. The bill shock is the cost of pure usage pricing, paid in customer trust and procurement friction, and it is a recurring tax even when the model works.

There is a second, quieter failure of pure usage pricing specific to AI: it makes the customer pay for your inefficiency. If your agent makes ten model calls to resolve a ticket and a competitor's makes three, pure per-call usage pricing charges the customer for your worse architecture. The customer cannot see this, but they feel the bill, and a competitor who prices on the resolved ticket rather than the calls will look cheaper and more aligned even at a higher margin. Usage pricing on inputs you control can quietly punish the customer for engineering decisions they did not make.

Outcome pricing: aligned with value, hard to prove

Outcome pricing charges for the result: per resolved ticket, per qualified lead, per successful reconciliation, per dollar recovered. Its great virtue is alignment with value. The customer pays only when they get what they came for, which is the most defensible pricing story you can tell: "you pay us when we deliver." It passes the Adoption Penalty Test in the best mode, rewarding both sides, because more outcomes means more customer value and more vendor revenue, and a customer rarely resents paying for results they actually received.

Intercom's Fin agent is the reference example, pricing at $0.99 per resolution rather than per message, with a careful definition of what counts: the agent answered and the conversation did not transfer to a human within a window, or the customer confirmed the answer helped, as laid out in Fin's resolution model. Contrast it with Salesforce's early Agentforce model at $2 per conversation, charged whether or not the issue was resolved. The difference is the whole lesson: per-conversation pricing makes the customer pay for the agent's failures; per-resolution pricing makes the vendor eat them. At a 60 percent resolution rate, per-conversation pricing costs the customer roughly 40 percent more for the same value. Per-resolution is the more aligned model, and it is not an accident that it is the one people cite admiringly.

But outcome pricing has two hard problems, and they are why it is not the universal answer despite being the most aligned.

The verification problem. Outcome pricing requires both sides to agree on whether the outcome happened. For a support resolution this is already fuzzy: did the AI resolve it, or did the customer give up and go elsewhere? Did the customer who clicked "this helped" actually get helped, or were they being polite? Fin spends real product effort on defining and detecting resolution precisely because the definition is contestable, and every contestable definition is a future billing dispute. For murkier outcomes (a "qualified" lead, an "improved" forecast, a "resolved" risk) the verification problem can be unsolvable cheaply, and a pricing model you cannot audit is a pricing model that generates disputes at every renewal.

The attribution problem. Even when you can verify the outcome happened, you have to establish that you caused it. If revenue went up, was it your AI or the new marketing campaign? If tickets dropped, was it your agent or the product getting better? Outcome pricing on outcomes you only partially cause is a fight waiting to happen, because the customer will attribute the good outcomes to themselves and the bad ones to you. The cleanest outcomes to price on are the ones where attribution is unambiguous because the AI did the whole thing end to end: the resolution the agent handled alone, the document the AI processed without a human. The further the human is from the loop, the cleaner the attribution and the more defensible the outcome price.

There is a third issue founders underestimate: outcome pricing transfers cost risk to the vendor. If you charge per resolution and your resolution rate is lower than you modeled, or your cost per attempt is higher, you absorb the gap. Outcome pricing is, in part, the vendor selling the customer insurance against the AI not working. That insurance has a price, and if you do not load it into the outcome price you will discover you sold it too cheap. The vendor who prices per resolved ticket is betting on their own resolution rate; if the bet is wrong, the margin is gone, and the customer bears none of it.

The mirror-image failure, on one diagram

Set the two side by side and the symmetry is the whole point.

	Usage pricing	Outcome pricing
Aligns with	Vendor cost	Customer value
Adoption Penalty mode	Punishes customer	Rewards both
Predictability	Poor (bill shock)	Moderate (depends on outcome volume)
Who bears cost risk	Customer	Vendor
Main failure	Bill shock, paying for vendor inefficiency	Verification, attribution, vendor eats bad performance
Verification cost	Low (meter is objective)	High (outcome is contestable)
Best when	Cost varies wildly, value is hard to define	Outcome is clean, attributable, AI does it end to end

Usage pricing is honest about your cost and dangerous to your customer's budget. Outcome pricing is honest about your customer's value and dangerous to your margin. Neither is "the AI pricing model." They are two ends of a spectrum, and the Value-Cost-Risk Triangle is what tells you where on the spectrum to sit: good pricing balances customer value, vendor cost, and risk allocation, and usage pricing over-weights the cost corner while outcome pricing over-weights the value corner. The art is putting the model where all three corners are tolerable.

The Value-Cost-Risk Triangle as a chooser

Run any candidate model through the three corners and ask whether each is acceptable, not optimal, just acceptable:

• Value corner. Does the price track what the customer gets, such that they feel the bill is fair relative to value received? Usage often fails here (they pay for consumption, not value). Outcome wins here.
• Cost corner. Does the price stay above your margin floor across the realistic range of customer behavior? Usage wins here (price tracks cost). Outcome can fail here when your performance is worse than modeled.
• Risk corner. Who bears the risk that the AI underperforms or costs more than expected, and is that allocation acceptable to both sides? Usage puts the risk on the customer; outcome puts it on the vendor. Neither is automatically right.

A model is viable when no corner is intolerable. Pure usage with no cap fails the value corner (bill shock, paying for inefficiency) for most customers. Pure outcome on a fuzzy, partially-attributable result fails the cost and risk corners for most vendors. The viable designs almost always sit in between, which is why the next section, and most real AI pricing, lives in the hybrid.

The hybrid is usually the answer

In practice the durable models combine the two with guardrails that fix each one's failure mode. A few patterns I have seen work:

Work-unit price with a usage floor and ceiling. Price on the recognizable work unit (closer to outcome) but bound it: a committed minimum so revenue is predictable for you, and a cap or spend alert so the bill is predictable for them. This neutralizes usage pricing's bill shock and outcome pricing's revenue unpredictability at once.

Outcome price with a cost-recovery floor. Charge per outcome, but set the outcome price above your fully-loaded cost-per-attempt divided by your realistic success rate, so you are profitable even when the AI fails some fraction of the time. Then the outcome model stops being uncapped insurance you gave away. If your cost per resolution attempt is twenty cents and you resolve 70 percent, your break-even resolution price is about twenty-nine cents, and you price above that with margin, not at the cost of a success as if failures were free.

Usage price with adoption protection. Keep usage-based metering for cost alignment, but add volume tiers that lower the per-unit price as usage grows, so heavy adoption is rewarded rather than punished. This directly addresses usage pricing's Adoption Penalty failure: the customer who runs you hard gets a better rate, not just a bigger bill, and you still cover cost because volume tiers are set above your floor.

The point of the hybrid is not complexity for its own sake. It is that usage and outcome each solve one corner of the triangle and break another, and a well-built hybrid solves both corners with mechanisms borrowed from the quota and contract chapters that follow.

A decision guide

When does each model fit? Use this as a starting filter, then validate against your own cost stack and customer.

• Lean usage when cost per unit varies wildly, value is genuinely hard to define, and your buyer is technical enough to manage consumption (developer tools, infrastructure, raw API access). Add caps and alerts to prevent bill shock.
• Lean outcome when the outcome is clean, objectively verifiable, unambiguously attributable to your AI, and your AI does it end to end with little human involvement (autonomous support resolution, document processing, automated reconciliation). Load the cost risk into the price.
• Hybrid (the default for most) when neither corner is fully comfortable, which is most real AI products. Price on the work unit, bound it with floors and caps, and route the heavy tail to metered overage.

The mistake is treating this as an identity choice, picking usage or outcome because it matches your worldview about fairness. It is an engineering choice about which corner of the triangle your product can afford to put the risk in. Decide it with the cost stack and the margin distribution in front of you, not with a slogan.

Practical exercise

Take your current or planned model and run it through the triangle. Write one honest sentence per corner: is value alignment acceptable, is the price above your floor across the realistic range, and is the risk allocation one both sides can live with. If any corner is intolerable, you have found which guardrail from the hybrid patterns you need to add. Do not ship a model with an intolerable corner and hope the customer does not notice; they will, at renewal, when it is most expensive to fix.

Key Takeaways

• Usage pricing aligns with vendor cost but punishes customer adoption with unpredictable, uncapped bills and makes customers pay for vendor inefficiency.
• Outcome pricing aligns with customer value and rewards both sides, but faces verification and attribution problems and transfers cost risk to the vendor.
• The two failures are mirror images: usage is honest about cost and dangerous to the customer's budget; outcome is honest about value and dangerous to the vendor's margin.
• Per-resolution beats per-conversation because the vendor, not the customer, eats the failures; cleanest outcomes are those the AI does end to end with unambiguous attribution.
• The Value-Cost-Risk Triangle is the chooser: a model is viable when no corner (value, cost, risk) is intolerable, which usually lands you in a hybrid.
• Hybrids fix each model's failure: work-unit price with floor and cap, outcome price with a cost-recovery floor, or usage with volume tiers that reward adoption.

Internal map

For the larger argument, keep this chapter connected to Pricing Software That Thinks, Revenue, Re-Engineered, the smaller-model margin argument, and The Economics of Inference.