What is Outcome-Based Pricing? Definition + Examples

Created time

May 26, 2026 03:09 PM

Title length (<60)

Author

Mike Heap

Ecomm?

Outcome-based pricing, in more depth

⚡

TL;DR: Outcome-based pricing charges for a delivered result rather than software access. The three tests for a real outcome (per Stripe): measurable, attributable, verifiable. Most outcome-based pricing arguments break down on the third one.

At the marketing-line level, outcome-based pricing is simple: the customer pays only when the vendor delivers a defined result.

Stripe puts it well as "outcome-based pricing ties the price of a product or service to a specific, agreed-upon result". Dealhub frames it as "a strategy where the cost of a product or service is directly linked to the results or value it delivers to the customer". We agree with the core of both.

Stripe's guide also offers a useful three-test gate. For something to qualify as a real outcome it has to be:

Measurable: clearly explicit, traceable through the product's instrumentation, and relevant to the customer's goal.

Attributable: both sides have to feel "the maths is fair and the counting is reliable", to use Stripe's phrasing.

Verifiable: the buyer can audit the count themselves, without taking the vendor's word for it.

Graphic explaining the tests for an outcome definition.

Most outcome-based pricing arguments break down on the third test. (We come back to that in the misconceptions section below.)

Outcome-based covers several distinct types of model in the wild:

Per-resolution: Intercom Fin (originally), HubSpot Breeze, Gorgias Automate.

Per-deflection: older Zendesk pricing.

Per-agreed-business-outcome: Sierra (resolved conversation, saved cancellation, upsell, cross-sell).

Per-conversation-handled: Salesforce Agentforce at $2 per conversation, per Metronome's writeup.

Per-recovered-revenue: Chargeflow at 25% of recovered chargebacks; Riskified at 0.4% of fraud-free transactions.

Per-closed-deal: sales-AI tools.

Same category. Very different unit costs. We'll see how the AI customer service vendors slice this in the next section.

How is an "outcome" defined? A look at how AI support vendors count it

⚡

TL;DR: There is no industry-standard definition of an "outcome". Fin counts an outcome when Fin "resolves the issue end to end or executes a Procedure". Zendesk Autoresolve uses a 72-hour quiet period. Sierra counts customer-confirmed outcomes. Each definition shifts the bill in real ways.

There's no industry-standard definition of "outcome", and (in our experience) the differences across the major AI customer service vendors aren't small. Some count resolutions when the customer goes silent, others count only when the customer explicitly agrees. The unit-cost effect is real.

Here's how the major vendors define their billable unit, with sources:

Vendor	What they call it	What counts	What doesn't	Source
Intercom Fin	Per-outcome (renamed from per-resolution in late 2025)	"Fin resolves the issue end to end, or successfully executes a Procedure you've configured to end in a handoff to a human or a workflow." Includes Procedure-driven handoffs since the rename.	The pricing page doesn't enumerate exclusions; community reports flag reopened conversations and agent-handled tickets as non-billable.	fin.ai/pricing
Sierra	Per agreed outcome	"Resolved support conversation, a saved cancellation, an upsell, a cross-sell", outcomes the customer explicitly agrees to during the conversation.	Escalations: Sierra say these incur no charge. They also admit "routing or greeter-style interactions" are better priced consumption-based and offer blends.	sierra.ai blog
Decagon	Per AI resolution	The deliberate "AI resolved" tag, set when the AI's answer ends the loop.	Escalations and pending tickets. Pricing is non-public.	decagon.ai (no public pricing page)
Zendesk AI (Autoresolve)	Per autoresolve	"72-hour quiet period, meaning the ticket stays closed, and the customer does not reopen the conversation." Charge fires "only when the AI agent resolves the issue on its own" with no human intervention.	Reopens within 72 hours; tickets that reach a human.	zendesk.co.uk blog
Gorgias Automate	Per automation	Ticket fully handled by an automation: intent recognised, action taken, customer didn't reply.	Tagged tickets where a human follow-up sent the closing reply.	gorgias.com/pricing (range $0.19 to $0.59 per AR by plan)
Salesforce Agentforce	Per conversation handled by AI agent	$2 per conversation handled by Agentforce: broader than per-resolution, narrower than per-message.	Conversations where the agent doesn't engage.	Metronome

Two patterns are doing most of the work in that table. I'll call them the no-reply window and explicit confirmation.

The no-reply window is what Fin uses implicitly, what Zendesk codifies as a 72-hour quiet period, and what Gorgias bakes into "customer didn't reply". It's cheap for the vendor to operate (they don't have to score anything).

The implicit assumption is that no reply means the problem got solved. In our experience, "no reply" also covers the case where the customer gave up, gave the AI a one-star rating in their head, and went to a competitor. The vendor bills; the customer churned.

Explicit confirmation is what Sierra and Decagon use. The billable surface is narrower (only outcomes the customer or the AI deliberately confirms), and the confidence that the outcome is real is higher. Fewer billable events for the vendor; fewer billing surprises for the buyer.

A note on what isn't in that table: My AskAI. We sit in a different model entirely (usage-based), paid the same when the AI works and when it doesn't.

Putting our row above would imply per-ticket is a type of outcome-based, which is precisely the conflation this post is trying to clear up. We come back to the contrast in the My AskAI section.

What's a "good" price per outcome?

⚡

TL;DR: Headline rates run from about $0.30 (HubSpot Breeze lower tiers) to $1.50 (Zendesk Autoresolve), with anecdotal $2 to $3 for Sierra and Decagon enterprise contracts. The trap is that the headline rate isn't the cost per outcome: floors, definition loopholes, and bundled services typically add 20% to 60%.

Headline rates across the AI customer service category sit between roughly $0.30 and $1.50 per resolved ticket, with a long tail above that for enterprise contracts. Here's how the band breaks down:

Tier	Headline rate per resolved ticket	What it usually means	Named example
Volume-tier mid market	$0.30 to $0.50	First-tier per-resolution rates before the floor kicks in.	HubSpot Breeze on lower plans.
Mid market	$0.60 to $0.99	Per-resolution pricing in the established helpdesks.	Intercom Fin at $0.99 • 50 outcomes / month standalone minimum.
Premium	$1.00 to $1.49	Enterprise outcome-based pricing, often bundled with seat fees or service.	Zendesk Autoresolve at $1.50, bundled into Advanced AI.
Be careful	$1.50+	Hidden minimums, mandatory professional services, or definition loopholes that let most interactions count.	Sierra and Decagon enterprise contracts (anecdotal $2 to $3 per resolution; non-public).

The natural next question: how does that compare to the cost of a human-handled ticket? Industry rules-of-thumb (Zendesk's State of Service, SQM Group benchmarks) put fully-loaded B2B SaaS ticket cost between $5 and $12. At those numbers, $1.50 per resolved ticket looks like a payback inside one billing cycle.

The trap in that calculation is the second variable. The headline-rate-times-current-volume maths assumes the AI's resolution rate is fixed; in practice it climbs over time, mostly because of work the customer does (the data is in the My AskAI section below).

On an outcome-based contract, every additional resolution the AI achieves gets billed at the headline rate. The blended cost per resolved ticket stays roughly flat, even though the underlying work to enable those resolutions sits with you (the customer) and not with the vendor.

So the "good" number on outcome-based pricing is the blended cost per resolved ticket once your AI's resolution rate has climbed and stabilised. That number is almost always higher than the headline-rate × your current volume suggests.

Three things buyers get wrong about outcome-based pricing

⚡

TL;DR: Three traps. "Risk-free" means risk-free against a vendor-controlled definition of "worked". "Per-resolution" and "per-outcome" cover billing models that vary 10x in unit cost. And the headline rate is almost never the blended cost: floors, definition loopholes, and bundled services usually add 20% to 60%.

In our experience walking buyers through these contracts, three misconceptions show up almost every time.

"Outcome-based pricing means we only pay if the AI works"

This is the line every outcome-based vendor leads with, and in fairness, most of the time the AI does work. The wrinkle is that every outcome model has a vendor-set definition of "worked".

Take Fin: a billable outcome is "Fin resolves the issue end to end, or successfully executes a Procedure you've configured to end in a handoff to a human or a workflow" (fin.ai/pricing).

Zendesk Autoresolve's bar is a 72-hour quiet period after AI-only closure. Sierra's bar is the customer explicitly agreeing to an outcome (scored by Sierra). Three vendors, three different bars, and we've reviewed enough of these contracts on customer calls to know the bar matters more than the rate.

None of those definitions are dishonest, just to be clear. The issue (the one we keep coming back to with buyers) is that you sign a contract against a number the vendor controls and calculates.

Even Sierra themselves acknowledges outcome-based pricing "isn't universally applicable" and offers consumption-based blends for routing and greeter-style interactions where the outcome definition gets fuzzy. Dealhub's own glossary entry warns that "purely success-based pricing strategies tend not to work" and recommends hybrid models, which is the vendor side conceding the gap.

The operator side concedes it too. The OP on a recent r/B2BSaaS thread framed it as: "Customers love the idea in theory: pay for value delivered… But in practice? Budget unpredictability, lack of control over outcomes and all the complications when customers don't fully follow through on their side." That's a definitional complaint about who controls the count.

"Per-resolution and per-outcome mean the same thing"

A resolution is one flavor of outcome. Outcome-based can also mean per-deflection, per-agreed-business-outcome (Sierra), per-recovered-refund (Chargeflow at 25% of recovered chargebacks), per-conversation-handled (Salesforce Agentforce at $2), per-closed-deal, and so on. Unit costs vary 10x across these types.

The cleanest example of why the distinction matters is Intercom Fin's late-2025 rename. Fin used to charge per "resolution"; now it charges per "outcome", and the new definition explicitly includes Procedure-driven handoffs that the old definition didn't bill for.

Same model, broader unit, larger invoice. The rename isn't deceptive (Intercom were transparent about it), but the buyers on the old contract saw their bills shift without changing anything on their side.

When you're reading an outcome-based pricing page, the first question we'd push you to ask is "what exactly counts as an outcome?" (the per-outcome rate is the second-most-important number).

"The price per outcome is the cost per outcome"

In our experience reviewing these contracts, the blended cost is normally 20% to 60% higher than the headline rate, for four reasons:

Volume floors. Fin's standalone plan is $0.99 per outcome with a 50-outcome / month minimum (call it a $50/month floor if you barely use it). The typical buyer is in the bundle where minimums climb.

Definition loopholes. The Fin rename is our canonical example: same headline rate, broader billable surface, higher bill.

Professional services. Sierra and Decagon enterprise contracts typically include implementation services in the SOW. The published "per-outcome" rate is rarely the all-in.

Suite-bundle uplifts. Zendesk Autoresolve at $1.50/resolution lives inside Advanced AI, which lives inside a higher-priced seat tier. The per-resolution rate sits on top of a per-seat base.

A commenter on the r/B2BSaaS thread above put the operator-side experience starkly: at one vendor they billed "7 figures a year when I was working there while the increase in profit was below 5%". That's the headline-rate-versus-blended-cost gap rendered as a single line. The model can work, but it can also bite, and the bite gets bigger as the buyer's underlying business grows.

Outcome-based pricing vs subscription, usage-based, and value-based pricing

⚡

TL;DR: Subscription pays for access. Usage-based pays for inputs the buyer can count (a ticket, an API call). Outcome-based pays for results the vendor scores. Value-based pricing is the negotiated parent of outcome-based. Usage-based and outcome-based sit in opposite corners on the question of who controls the "win" definition.

Outcome-based pricing only really makes sense alongside the three or four models it isn't. Here's a clean comparison:

Term	Definition	Difference from outcome-based pricing
Subscription / SaaS pricing	Recurring fee for software access.	Charges for access, not results. Most AI vendors are now hybrid: subscription base plus per-outcome or per-ticket.
Per-seat pricing	Subscription priced per user.	A flavor of subscription. Costs scale with team size, not with what the AI delivers.
Usage-based pricing	Pay per unit of input through the system, a ticket sent, an API call, a token consumed.	The honest alternative to outcome-based. The buyer can count the unit themselves; the vendor doesn't control the definition. Cost per resolved ticket falls as resolution rate climbs, so the customer captures the improvement upside. (Full case in the next section.)
Value-based pricing	Buyer's perceived value sets the price (often via discovery + quote).	Negotiated, not metered. Outcome-based is the meterable subset of value-based.
Per-resolution pricing	A specific outcome-based flavor where the billable unit is a resolved support ticket.	The most common outcome-based model in AI customer service. Heavily vendor-defined.
Performance-based pricing	Often used interchangeably with outcome-based, but historically refers to ad spend or commissions.	Same idea, different lineage; "outcome-based" is the newer, software-centric label.

The four-way live comparison for a buyer evaluating an AI customer service vendor right now is subscription vs usage-based vs outcome-based vs value-based. Almost everything in the category is some hybrid of two of those four.

Why My AskAI uses usage-based pricing instead of outcome-based

⚡

TL;DR: We charge per ticket. As resolution rate climbs from 40% to 80% (which it does, mostly because of work the customer does), cost per resolved ticket falls under usage-based pricing and stays flat under outcome-based. TravelJoy went from 24% on Zendesk's AI to 80% on My AskAI: that gap would have cost about $2,000/month extra on outcome-based pricing.

We made the choice to price My AskAI per-ticket (usage-based) rather than per-resolution (outcome-based) deliberately. The short version: usage-based aligns vendor and buyer incentives better, you can count the unit yourself, and the cost per resolved ticket falls as the AI's resolution rate climbs (which it always does, because you're the one doing most of the work).

Here's the longer version:

What we do instead

We charge per ticket. In a helpdesk chat channel every two AI replies count as one credit, working out to roughly $0.10 per ticket at the Scale plan rate. In email, the first AI reply is one credit and each follow-up is half a credit, so about $0.15 per email ticket.

Full plan and credit detail lives on the My AskAI pricing page and the pricing explainer.

The unit is something you can count in your own helpdesk export. There's no 72-hour quiet period to score, no 24-hour-no-reply heuristic, no vendor-controlled "AI resolved" tag.

We pay the model bill (OpenAI, Google, Anthropic) on every reply we send; we charge a thin margin on every reply you send. The maths is symmetrical.

Why outcome-based sounds better and isn't

We've already covered the surface argument in the misconceptions section: paying only when the AI "works" sounds risk-free, but every outcome model has a vendor-set definition of what "worked" means. The deeper argument: most of what makes resolution rate climb is customer-side work (vendor cleverness is real but a smaller share).

The customer does most of the work that lifts resolution rate

The things that move an AI's resolution rate from 40% to 80% in production, in our experience across customer rollouts, are:

Keeping the knowledge base up to date: adding new articles, fixing the old ones, retiring the stale ones.

Connecting tools and APIs: helpdesk integration, live user data, order lookups, refund flows.

Writing and tuning guidance: when to escalate, when to suggest an upgrade, what tone to use.

Setting up triage and tagging: which intents the AI handles, which always go to a human.

Running a weekly QA loop that closes the questions the AI couldn't answer (in our product, Self-Learning surfaces the candidates and the Insights → Custom Answers loop closes them).

The vendor's contribution is real (model selection, RAG architecture, training pipeline) but it's the smaller share. On outcome-based pricing, every additional resolution the customer's work enabled gets billed by the vendor at the per-resolution rate.

Chart showing usage-based costs falling for resolved tickets.

You pay for the lift you engineered. On usage-based pricing, you capture the full upside, the unit cost per resolved ticket falls as the resolution rate climbs.

The numbers: TravelJoy

TravelJoy moved from Zendesk's own AI (24% resolution) to My AskAI (76% at case-study time; since climbed to 80%). Alan Pugh, TravelJoy's Head of Customer Service, put it as:

"You're beating Zendesk's AI agent 76% to 24% on AI deflection. Huge."

Doing the counterfactual maths: a 52-point lift on TravelJoy's ~2,500 monthly tickets is roughly 1,300 extra resolved tickets per month. At Zendesk's $1.50 per autoresolve, those extra resolutions would have added roughly $2,000 per month to the bill, money TravelJoy would have paid Zendesk for resolutions TravelJoy's own engineering and content work made possible. (Connecting their website, connecting Notion as a knowledge source, closing out questions the AI couldn't answer via Insights, adding custom answers continuously, writing Communication style and Handover guidance, setting up AI Tagging.)

On our usage-based pricing, those resolutions don't cost any more than the same volume of tickets did before they switched.

The numbers: Edel Optics

Edel Optics is (in our view) the cleaner version of the same argument. They moved from 25% to 30% resolution up to 75% to 79% after adding the User Data API themselves, and the case study notes this "lifted resolution by about 50 points overnight".

With about 4,000 tickets per month and roughly 3,000 of them now resolved by the AI, that overnight lift represents around 2,000 extra resolved tickets per month (yes, from one customer-side engineering change).

At $1.50 per resolution, that's about $3,000 per month in additional billing on outcome-based pricing, for an engineering change Edel Optics shipped themselves. On usage-based pricing, the same ticket volume costs the same as it did before the API got connected. Edel Optics's work, Edel Optics's upside.

The honest limit

Usage-based pricing has a real trade-off: you also pay for tickets the AI tried and failed on. We don't pretend that away. The argument we'd make for it anyway is twofold:

Predictability: you can model spend in a spreadsheet, with no vendor-controlled scoring rule introducing variance. Alignment: every dollar of improvement you engineer stays with you (the vendor sees the same per-ticket rate either way).

For the canonical worked example, at 10,000 tickets per month and a 75% AI resolution rate, our Scale plan comes in at roughly $1,299/month.

Intercom Fin's bill on the same volume is approximately $7,425 (5.7x). Zendesk AI is approximately $11,250 (8.7x). Gorgias Automate is approximately $6,750 (5.2x).

The full breakdown lives in our pricing explainer post. The 5x to 8x gap exists because competitors charge per resolution (so their costs rise as their AI gets better) and because their "outcome" definition often counts ambiguous conversations the buyer didn't expect to be billable.

FAQs

What is outcome-based pricing in simple terms?

Outcome-based pricing is a billing model where the buyer pays only when the vendor delivers a defined, measurable result, like a resolved support ticket, a closed deal, or a recovered refund. You're not paying for software access, agent seats, or units of usage. You're paying per outcome, with the outcome defined and counted by the vendor.

What's the difference between outcome-based and value-based pricing?

Value-based pricing is the broader category: the price gets set by the buyer's perceived value, usually negotiated. Outcome-based pricing is the meterable subset of value-based, the same idea, but with a per-event billing meter attached. Outcome-based is what value-based looks like when you can count the event.

What's the difference between outcome-based and usage-based pricing?

Usage-based pricing charges per unit of input through the system (a ticket sent, an API call, a token consumed); outcome-based pricing charges per result the vendor scores as a win. Two practical differences matter a lot. Under usage-based you can count the unit yourself, and the cost per resolved ticket falls as resolution rate climbs. Under outcome-based the vendor controls the unit definition, and the cost per resolved ticket stays roughly flat as the rate climbs, so you pay the vendor for improvements your own work enabled.

How does Intercom Fin define a "resolution"?

Per fin.ai/pricing, a Fin outcome is "Fin resolves the issue end to end, or successfully executes a Procedure you've configured to end in a handoff to a human or a workflow". The headline rate is $0.99 per outcome, with a 50-outcome / month minimum on the standalone plan. Fin renamed "resolutions" to "outcomes" in late 2025; the new definition explicitly added billable Procedure handoffs.

How do other AI customer service vendors define a "resolution"?

We laid out the table in the vendor section above, but the short version. Sierra counts outcomes the customer explicitly agrees to (resolved conversations, saved cancellations, upsells, cross-sells); Decagon counts deliberate "AI resolved" tags; Zendesk Autoresolve uses a 72-hour quiet period after AI-only closure; Gorgias Automate counts tickets fully handled by an automation; Salesforce Agentforce counts conversations handled by the AI agent at $2 each.

What's a good price per AI resolution?

Headline rates in AI customer service run from about $0.30 per resolution (HubSpot Breeze lower tiers) to $1.50 (Zendesk Autoresolve) to $2 or $3 (anecdotal enterprise contracts at Sierra and Decagon). Anything above $1.50 usually means a hidden minimum, a mandatory professional services line, or an outcome definition broad enough that most interactions count. Compare against your current fully-loaded cost per human-handled ticket ($5 to $12 in B2B SaaS) for the payback frame, and remember the blended cost is normally 20% to 60% above the headline.

Has anyone actually made outcome-based pricing work?

Yes, but with caveats, and the operators who say so usually recommend hybrids over the pure model. On an r/B2BSaaS thread one commenter (u/paul-towers) suggested "a monthly / annual fee that includes a given number of outcomes" as the best practical compromise. Another (u/Tjgoodwiniv) advised "tying something like that to things you can control". Sierra and Decagon clearly can make it work at the revenue level (both publicly past $100m ARR), but the model is hardest on smaller buyers, the same revenue mechanic that drives the vendor's growth shows up as the buyer's billing volatility.

Why do AI vendors prefer outcome-based pricing?

The honest answer is that outcome-priced contracts grow with the buyer's resolution rate over time, and most of that growth comes from customer-side work, knowledge updates, API connections, guidance tuning, triage setup. Charging per resolution means the vendor's revenue scales with improvements the vendor didn't engineer. It's a strong commercial model for vendors precisely because the underlying lift is mostly free for them. We'd rather price for the work we do (the unit we send) than for the work our customers do (the lift they engineer).

What are the hidden costs of outcome-based pricing?

In our reviews of these contracts: minimum monthly spends (Fin's $1,000 / month floor on the standalone plan); definition loopholes that broaden the billable surface mid-contract (Fin's late-2025 rename added Procedure handoffs); professional services lines (Sierra and Decagon enterprise contracts typically include implementation in the SOW); and suite-bundle uplifts (Zendesk Autoresolve sits inside Advanced AI, which sits inside a higher seat tier). The blended cost is typically 20% to 60% above the headline per-outcome rate.

Why does My AskAI use usage-based pricing instead of outcome-based?

We covered this in full in the My AskAI section above, but the short version: we charge per ticket because the buyer can count the unit themselves, the vendor doesn't control a scoring rule, and the cost per resolved ticket falls as resolution rate climbs, capturing the upside for the customer whose work is doing most of the lifting. At 10,000 tickets / month and a 75% AI resolution rate, that comes out to about $1,299 / month vs $7,425 for Fin and $11,250 for Zendesk AI. Detail in our pricing explainer.

Does usage-based pricing cost more if the AI doesn't work?

Yes, you pay for tickets the AI tried (even the ones that didn't resolve). We're upfront about that trade-off. The argument we'd make for usage-based anyway: predictability (you can model spend in a spreadsheet, with no vendor-controlled scoring rule introducing variance) and alignment (every dollar of improvement you engineer stays with you). As a backstop, we offer a 60% AI resolution rate or your money back guarantee on the pricing page.

When does outcome-based pricing actually make sense for the buyer?

Three conditions, all rare in practice. First: the resolution definition is fully auditable (you can re-derive the score from your own data, without taking the vendor's count on faith). Second: the vendor has skin-in-the-game beyond the bill, Sword Health-style health-outcome contracts where the vendor is delivering an actual clinical result. Third: the integration is so deep the vendor genuinely drives most of the lift, leaving little for the customer to engineer. For AI customer service specifically, where your knowledge base, API connections, and guidance do most of the lift, those conditions rarely hold.

What is Outcome-Based Pricing? Definition, Examples, and How AI Vendors Bill For It