Outcome-based pricing

Outcome-based pricing charges for the result the customer wanted, not the access or activity that produced it. Not seats, not API calls — resolved support tickets, qualified leads, completed reconciliations, successful collections.

AI agents are what made this practical at scale. When software performs work that previously required a person, the natural unit of value shifts from “access for that person” to “the work itself”, and the vendor can plausibly take responsibility for the result.

Outcome-based pricing examples

Customer support is where the model went mainstream, because a “resolved conversation” is something both sides can count.

• Intercom Fin. Intercom prices its Fin AI agent at $0.99 per outcome. An outcome is counted when the customer confirms the issue is resolved, doesn’t ask for more help after Fin responds, or Fin completes a workflow — and it is charged once per conversation, however many questions it answers.
• Zendesk AI agents. Zendesk prices its AI agents per automated resolution: the customer pays only when the AI agent resolves the request on its own, without a human stepping in. A resolution counts once the ticket stays closed through a quiet period without the customer reopening it.

Notice what both definitions have in common: they are precise, they say what does not count, and they are written into the pricing page rather than left to interpretation. That is the hard part of the model.

How to contract an outcome

Before an outcome can be billed it has to be defined in the contract, the same way a seat or an API call is. A workable outcome clause covers:

1. The definition. What exactly counts — “a conversation closed with no reopen within 72 hours”, “a lead accepted by sales”, “an invoice paid within terms”.
2. The exclusions. What does not count: duplicates, test traffic, outcomes that would have happened anyway, escalations to a human.
3. The evidence. What record proves it, and how the customer can see it mid-period.
4. The price and floor. The rate per outcome, any tiers, and the minimum commitment or platform fee underneath it.
5. The dispute window. How long the customer has to challenge a count before the invoice is final.

How to bill outcomes: a worked example

Say an AI collections product charges a $2,000/month platform fee plus $4 per invoice it gets paid, with the first 300 outcomes included.

Mechanically this is usage-based billing with a business event as the meter: each outcome is recorded as it happens, counted at period end, rated against the tiers and invoiced in arrears next to the fee billed in advance. That is exactly how Bunny’s usage-based billing handles it — the platform fee and the outcome charge sit on one subscription and one invoice.

The three hard problems

Attribution. Did your product cause the outcome, or did it happen anyway? A lead-qualification tool that charges per qualified lead has to define qualification in a way the customer accepts without arbitration.

Measurement. The outcome has to be countable, auditable and resistant to disagreement. This is metering with much higher stakes, because every disputed unit is a disputed invoice.

Revenue predictability. Outcome revenue is variable by construction, which makes forecasting harder and ARR reporting genuinely contentious. Most vendors mitigate with a minimum commitment or a platform fee underneath — a hybrid pricing model.

What it demands of your billing stack

Outcome pricing is metered pricing where the meter is a business event rather than a technical one, and where the customer will audit it. That means an event record with full history, mid-period visibility for the customer, and the ability to change the outcome definition on new contracts without repricing existing ones.

Very few pricing models expose the limits of a billing platform faster. For the wider landscape of usage, credit and hybrid models, see our guide to usage-based pricing models.