What is Outcome Based Pricing?

Outcome-based pricing ties the price of a product or service to a specific, measurable result.

The customer pays when the promised outcome is delivered: a support ticket resolved, a lead qualified, a document drafted, a transaction completed. If the result doesn't happen, neither does the charge.

This model has existed for decades in industries like payments (Stripe charges per successful transaction) and aviation (Rolls-Royce's "Power by the Hour" charges airlines per hour of engine uptime). What's new is AI making it viable for software. When an AI agent resolves a support ticket end-to-end, the outcome is clean enough to charge for. Intercom's Fin agent charges $0.99 per resolved ticket. If the bot can't close it and a human takes over, the customer pays nothing.

Gartner forecasts that 40% of enterprise SaaS will include outcome-based pricing elements by 2026, up from 15% two years prior. The driver is agentic AI: as software moves from assisting humans to executing work autonomously, the natural pricing unit shifts from who has access to what gets done.

How outcome-based pricing works

The mechanics require more upfront work than other pricing models. Both sides need to agree on what counts as a result, how it's measured, and what happens at the edges.

The Stripe article on outcome-based pricing puts it well: this isn't just a pricing change, it's a business-wide redesign of how you sell, measure, and bill.

Who uses outcome-based pricing today?

Outcome-based pricing is concentrated in categories where AI performs discrete, measurable work and where the value is clear enough for a CFO to approve.

The pattern: outcome pricing works when the product does the work end-to-end and the result is binary (resolved or not, completed or not, delivered or not).

Where outcome-based pricing fits in the model landscape

Outcome-based pricing sits at the highest value-alignment end of the pricing spectrum. It's also the hardest to implement.

Moving from left to right, value alignment increases but so does the risk the vendor takes on. The vendor absorbs cost variability: a difficult support ticket might consume 10x the compute of a simple one, but the customer pays the same $0.99 either way.

Bessemer's AI pricing playbook captures the tradeoff: outcome-based pricing works when you're confident in your AI's performance, when you can absorb cost variance, and when the outcome is unambiguous and measurable.

The attribution problem

Attribution is the central challenge of outcome-based pricing. Business results rarely have a single cause.

If a customer's sales increase after adopting your platform, how much of that growth came from your product versus their new marketing campaign, seasonal trends, or a competitor exiting the market? If an AI agent "resolves" a ticket but the customer still calls back two days later, was it really resolved?

Products that execute entire workflows autonomously have the cleanest attribution. Products that assist humans or contribute partially to a result face much harder attribution challenges. This is why outcome pricing has gained traction fastest in customer support AI (binary: resolved or not) and payments (binary: transaction completed or not) rather than in categories like marketing or sales enablement where attribution is muddier.

The economics of outcome-based pricing

Outcome pricing changes the financial profile of a software business in ways that CFOs and investors need to understand.

The revenue recognition implications deserve attention. Under ASC 606, outcome-based contracts often recognize revenue at the point the outcome is delivered, not ratably over a subscription period. EY's recent analysis on outcome-based SaaS pricing highlights that companies must carefully evaluate whether their contractual promise is access to a platform (stand-ready obligation, recognized ratably) or delivery of specific outcomes (recognized at delivery). The distinction affects everything from how revenue hits the P&L to how contracts are structured.

When outcome-based pricing works (and when it doesn't)

Outcome pricing isn't universally applicable. It requires specific conditions to function.

Products in "soft ROI" territory, where the AI offers advice without closing the loop, struggle with outcome pricing. If the product suggests an action but the human decides whether to execute, the attribution chain breaks. This is why Bessemer's playbook warns that copilots offering advice without closing the loop live in dangerous territory for monetization, especially as 2025 AI pilots hit their first renewal cycles in 2026.

Hybrid approaches: the practical middle ground

Pure outcome-based pricing is rare. Most companies that use outcome elements combine them with a base fee.

This hybrid approach addresses the biggest buyer objection: unpredictability. 78% of IT leaders report unexpected charges from consumption-based or AI pricing models, and 90% of CIOs cite cost forecasting as their top challenge in AI deployment. A base fee plus outcome charges gives CFOs a number they can budget while preserving the value alignment that makes outcome pricing attractive.

Learn more about hybrid structures in our post on hybrid pricing.

Outcome-based pricing and billing infrastructure

Outcome pricing demands more from billing infrastructure than any other model.

You need real-time event capture to record outcomes as they happen. You need attribution logic to determine which outcomes count. You need configurable rate cards so pricing per outcome can change without code deploys. You need guardrails (caps, minimums, volume tiers) built into the billing layer, not managed in spreadsheets. You need revenue recognition that handles point-of-delivery recognition for outcome units alongside ratable recognition for base fees. And you need transparent reporting so customers can verify the counts themselves.

Most billing systems were built for subscriptions. Adding outcome-based pricing on top of Stripe or a homegrown system means building custom metering, custom attribution logic, custom invoicing, and custom revenue recognition. Each of those custom layers becomes code your engineering team maintains instead of product they ship.

That's the billing v1 to billing v2 transition. The pricing model grows more sophisticated than the infrastructure can support. Not because the billing system was bad, but because outcome-based pricing is an architectural requirement, not a configuration option.

For context on how pricing models relate to billing architecture, see our posts on token pricing, credit-based pricing, and the credit architecture problem.

Looking to implement outcome-based or hybrid pricing with real-time metering, configurable rate cards, and proper revenue recognition? Talk to one of our billing experts.