Logo

Comparing Usage-Based and Outcome-Based PricingIs outcome-based pricing a variant of usage-based pricing? Yes and no.

cover

Outcome-based pricing has created a lot of buzz recently because it's not always clear, from the customer's perspective, what value they will receive from new AI services. To take risk out of their buying decision, AI vendors offer a "pay only for results" model. From a billing perspective, both models depend on billable events and metering. But when and where those events happen, it matters.

What Is Outcome-Based Pricing

Outcome-based pricing aligns payment with results. Unlike usage-based pricing, which charges for work done regardless of outcome, with outcome-based pricing, customers only pay when they see real value, like a support ticket answered by the AI chatbot or a qualified lead books a demo with an AI SDR. When done well, outcome-based pricing builds trust and ties revenue directly to customer success. Adopting outcome-based is ambiguous for most businesses, especially in developer infrastructure. For instance, when using AWS EC2, the work and the outcome are the same: the instance requested by the customer is running and healthy. The customer's expectations are met simply by supplying a healthy processor; thus, payment is by the minute, regardless of the processing outcome. But this is not always the case.

Core Difference: When the Billable Event Happens

With usage-based pricing, the billable event is generated as the work is performed, e.g., number of tokens used, seconds of compute time, requests processed, etc. The billable event may be delayed with outcome-based pricing until a clear success signal is received. For example, an AI SDR sending emails might only generate a billable event when a prospect replies positively or books a demo. In this model, the billable event and metering only happen after the positive outcome is confidently identified. But defining success is often not easy.

Defining Success Can Be Challenging

For example, AI support chatbots usually solve this by asking the user at the end of the chat if their question was answered or if they are still facing an issue. They can also mark the chat as successful if the user stops asking questions after some time. With support AI bots, it's easy to see that every time the bot can eliminate the need for human support, it saves time and cost for the vendor. But let's explore a more nuanced use case. For instance, with an AI SDR, you don't want to charge customers for a “No, thank you” reply. The vendor must implement robust logic, possibly using an LLM to analyze the message and determine if the outcome qualifies as positive. LLMs excel at understanding context but are not always deterministic, so the result will likely be debatable. In both examples, a success event is sent to the billing system once the outcome is confirmed, just like in usage-based pricing. Technically, both models rely on event-based metering; the difference is when that event is emitted during work or in the feedback loop.

Revenue Collection and Recognition Complexities

Charging for work delivered now but only potentially billed in the future introduces revenue collection and recognition complexity. What if the customer cancels or changes their plan before the outcome happens? Should billing apply based on the old pricing when the work happens or the new one when the outcome success loop is closed? How long in the future is an outcome still billable? These are non-trivial questions that require decisions from finance.

Delayed Cost Visibility

You can control spending in real time with a reliable billing provider that offers usage-based pricing. As the work progresses, you can choose to continue or stop spending tokens and run GPUs. With outcome-based pricing, the work is completed now, but the success feedback loop and the associated costs can take days or weeks to finalize. Costs can escalate due to factors such as:

  • Overlapping campaigns
  • Variable conversion rates
  • Canceled subscription

In outcome-based pricing, spending is often only visible after the fact, making budgeting and alerting more difficult. On the other hand, outcome-based pricing is usually based on a finite amount of work, like 1,000 cold emails sent out by an AI SDR or 500 customers interacting with an AI support chatbot like Intercom's Fin AI.

Things to Pay Attention to with Outcome-Based Pricing

Adopting outcome-based pricing offers strong alignment with customer value, but it introduces several complexities teams should be aware of:

  • Delayed Billing Events: Billable events may only occur after a delayed feedback loop, so you must store context and correlate results over time.
  • Defining Outcome: You must clearly define what counts as a “successful” outcome—and implement logic to detect it reliably. Ambiguous definitions lead to disputes and billing inconsistencies.
  • Attribution Challenges: Accurate tracking is critical. You need to know which action led to which outcome to avoid billing the wrong or missing billable events entirely.
  • Revenue Collection and Recognition: If a customer changes plans or cancels between execution and outcome, which plan governs the billing? Accounting needs clear rules to avoid compliance issues.
  • Cost Visibility and Risk: With delayed outcomes, spend becomes unpredictable. You may not know how much a campaign costs until days or weeks later, making real-time budget control harder.

Outcome-based pricing can unlock new business models but requires a flexible metering and billing infrastructure.

Blog Cloud CTA
Launching new product or pricing?
Do it faster with OpenMeter!
Get Started
Peter Marton
Peter Marton@slashdotpeter