Outcome-based pricing is mostly fairy dust

There is a scene in The Wolf of Wall Street where Matthew McConaughey explains to Leonardo DiCaprio that the whole business is a fugazi. “Fugazi, fogazi. It’s a whazy, it’s a woozy. It’s fairy dust.”

That scene plays in my head every time a founder tells me they want to charge for outcomes.

It comes up constantly on first calls. Someone has heard of outcome-based pricing, cannot quite define it, and is holding it the way you hold a silver bullet. Most of them are also smart enough to suspect it does not exist. They just want someone to tell them either way.

Then we run the workshop, map the customer’s value chain, and score the candidate metrics. It becomes obvious inside an hour, every time. The outcome sits at the far end of the chain, and by the time you get out there almost nothing is measurable, attributable, or something two finance teams will agree on at invoice time.

So I went and checked what vendors actually bill on. Across seventeen enterprise software and AI agent companies selling on outcome positioning, three bill on a real business outcome. The rest bill on an output with outcome branding on the pricing page.

That gap is the useful part of this whole topic. This post is about where the line sits, why nearly everything lands on the wrong side of it, and what to build instead.

Outputs are not outcomes, and pricing keeps using one word for both

Outcome-based pricing means the invoice only fires when a measurable result lands in the customer’s business. No result, no fee.

Everything turns on what counts as a result, and software pricing has been sloppy about it in a way other fields sorted out decades ago. Program evaluation runs on a five-step chain, and every position on it has a name:

• Inputs are resources consumed. Tokens, API calls, gigabytes. Bill on these and you have usage-based pricing.
• Activities are work attempted. Agent runs, tool-call sequences. Bill on these and you have agentic or task-based pricing.
• Outputs are work completed. A resolved ticket, a qualified lead, a drafted document. Bill on these and you have output-based pricing, which in customer support usually goes by per-resolution pricing.
• Outcomes are a change in the customer’s business. Cash recovered, a fraud loss reimbursed, a settlement paid out. You can point at a bank statement. Bill on these and you have outcome-based pricing.
• Impact is a change in the world. Lives saved, revenue grown, a market moved. Nobody bills on this, and the section after next explains why.

Nearly every company marketing outcome-based pricing in 2026 is selling output-based pricing. Intercom’s Fin charges $0.99 per resolved support conversation and $9.99 per qualified sales lead. Zendesk charges for a verified resolution. Salesforce meters Agentforce in Flex Credits at $500 per 100,000, where a digital action costs 20 credits and a voice action costs 30. Sierra charges roughly $1.00 to $2.50 per resolved session. Those are all outputs. Each one is a state transition inside the vendor’s own software, and none of them measures a dollar moving anywhere in the buyer’s business.

Output pricing is still a real step down the chain, and it is not the same as usage pricing. Under usage pricing the buyer pays for the attempt: twelve turns of inference that ended in an escalation, twelve turns billed. Under output pricing the vendor eats those twelve turns and invoices nothing. That transfer of failure risk is genuine, and it is why per-resolution pricing feels so different from per-token pricing even though neither one touches the customer’s P&L.

So I am not calling any of this dishonest. Outputs are frequently the correct thing to bill on, and most of this post argues you should go find the best one you can. But the market is holding a conversation about outcomes while shipping outputs, and if you copy what a competitor says on their pricing page rather than what their contract meters, you will build the wrong thing.

The reason everyone wants it is real enough. Outcome pricing lowers the barrier to a first purchase, because the buyer is not writing a cheque against a projection. It puts your revenue on the same side of the table as their results. And it lets your account grow when their business grows rather than when their headcount does. Those are genuine benefits and they are why the idea keeps coming back. The rest of this post is about what you have to be true to collect them.

Why the outcome sits at the wrong end of the value chain

Draw your customer’s value chain and the problem becomes obvious in about ten minutes.

The chain is the sequence of steps a customer moves through, from signing up to getting the thing they actually wanted. I covered the method in detail in how to find your SaaS value metric, but the short version: start at the outcome, ask what had to happen before it, and keep going backwards until you hit signup.

Take Calendly. Four steps. Set up the account and connect calendars. Share the booking link. Meetings get booked. Time gets saved and the meetings actually happen.

Now put candidate billing metrics under each step and score them. Two questions, in this order. Can you measure and attribute it? Does willingness to pay rise as it grows?

Watch what happens at step four. “Meetings that actually happened” and “hours of time saved” are the two candidates sitting closest to the real value, and both die instantly on the first question. Calendly cannot see whether you showed up. It has no idea what an hour of your time is worth. It cannot claim credit for either. Those are the outcomes, and they are unbillable.

This repeats in nearly every value chain I draw. The metrics that survive measurement and attribution cluster in the middle of the chain. The metrics at the outcome end fail, and they fail for boring operational reasons rather than strategic ones.

My favourite version of this turned up in a pricing forum. A company sells parking enforcement software to cities and municipalities, billed per violation processed. Their product works. Violations go down. A successful rollout shrinks their own revenue, which is about as broken as a value metric gets.

They had thought it through further than most people do. Bad parking gets pedestrians killed, their software reduces bad parking, so somewhere at the end of that chain are people who did not die. Could they charge for that instead?

Obviously not. A city is running a hundred and fifty road safety initiatives at the same time. Nobody can hand you the slice of a falling fatality rate that belongs to your parking app, and no procurement officer is signing a contract that tries.

Put that story on the chain and it gets very clear. They were billing on an output, violations processed, which their own product existed to reduce. They wanted to jump to impact, lives saved, skipping outcomes entirely. That is two positions in one leap, which is why it sounded impossible the moment they said it out loud. Everything workable sat in between, and that is where yours will be too.

Which gives the rule this whole post is built around:

Move as far toward the outcome as your value metric survives, then stop. Never trade metric quality for proximity to the outcome.

A weaker metric closer to the outcome is worse than a strong metric one step back. The weaker one gets you a monthly billing dispute, a customer who games the meter, and an invoice your own team cannot reconcile. Being philosophically closer to value buys you nothing when you are on a call arguing about whether a ticket was really resolved.

Notice that a resolved support ticket is a good metric precisely because it is an output rather than an outcome. Resolution has a programmatic boundary. The software can compute it, defend it and log it. That is why Sierra, Decagon and Intercom can all sell on it, and why “revenue closed” never made it past any of their pricing committees.

When outcome-based pricing does work: three conditions

Pure outcome pricing survives for years in a small number of places. Look at what those places have in common and you get a test you can run against your own product in about a minute.

Someone outside both companies decides whether the outcome happened. Not your software. Not the customer’s admin. A card network, a bank, a court, a regulator. The moment adjudication happens inside either party’s systems, you have a dispute engine rather than a billing meter.

Cash actually lands in the customer’s account. Not avoided cost. Not efficiency. Not a labour hour that theoretically was not spent. Money arrives and both parties can see the same number. Models that bill against avoided cost fail because the counterfactual is arguable and the baseline drifts.

You eat the full cost of failure. No platform fee, no onboarding fee, no minimum. If the outcome does not happen, you have worked for free. If you need a floor to survive, you are not running outcome pricing, you are running a subscription with an outcome-shaped overage.

Three companies pass all three.

Chargeflow fights payment chargebacks for merchants on Stripe, Shopify Payments and Adyen. It takes 25% of recovered funds and charges zero monthly SaaS fee. The win or loss is adjudicated by Visa and Mastercard, so neither Chargeflow nor the merchant can fudge it. To monetise prevention rather than recovery, it sells separately: $29 per deflected pre-chargeback alert, $0.20 per transaction scan.

Riskified has run this model since 2011. It charges a percentage of approved gross merchandise value and backs it with a 100% chargeback guarantee. If it approves an order that turns out to be fraud, it reimburses the merchant for the whole thing. That is not really pricing, it is underwriting.

AirHelp takes 35% of recovered airline compensation under EU regulation EC 261/2004, rising to 50% if it has to litigate. No claim, no fee. Adjudication is a civil aviation authority.

Notice what all three are. Money recovery businesses sitting next to a clearing system that already decides winners and losers. If your product does not sit next to one of those, you can still design a good pricing model, but it will not be this one.

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

Most of the confusion on this topic is four different models sharing a vocabulary. Value-based pricing in particular gets used as a synonym for outcome pricing, and they are not close. Value-based pricing is how you set the number on the page, before the sale, based on what the buyer believes the product is worth. Outcome pricing is a metering architecture that decides whether you get to invoice at all, after the work.

Almost every AI company that says outcome pricing is in the last row. Intercom sells seats at $29 to $139 per month plus $0.99 per resolution with a 50-outcome monthly minimum. Zendesk sells Suite seats at $55 to $115 per agent per month with resolutions layered above. Sierra markets pure outcome pricing and signs contracts with a floor around $150,000 a year plus $50,000 to $200,000 in setup. Decagon is reported at a platform fee starting around $50,000 before usage.

The “no platform fee, pure outcome” AI agent is the most durable myth in this category. I could not find a single verified enterprise contract without a floor.

What breaks when you ship outcome-based pricing anyway

Say you have a defensible output and you decide to meter on it. Six things go wrong, in roughly this order.

Attribution breaks the moment a human touches the work

This is the failure that kills the ambitious version of the model. Intercom hit it directly when designing pricing for Fin for Sales. The company considered charging a percentage of closed-won revenue, which is the purest outcome you could pick in sales, and abandoned it. If the account executive gives a weak demo, or the buyer’s budget freezes, or the deal slips a quarter for reasons nobody controls, the software gets punished for a human failure downstream. Intercom shipped a $9.99 qualified lead instead, defined by filter rules the customer configures themselves.

Anywhere your software hands off to a person, a second vendor or a market condition, attribution stops working. That covers most of B2B software.

Definitions drift, so your contract fills up with exclusions

“Resolution” sounds unambiguous until it is a line item. Enterprise agreements on outcome meters end up carrying a standard set of carve-outs, and you should assume you will negotiate all of them:

• A 48 to 72 hour lookback window. If the customer contacts support again through any channel inside it, the original event is reversed and credited back.
• Interactions ending in under three exchanges do not count.
• Sessions from bots, scrapers and monitoring pings do not count.
• Anything escalated because of a system error or API timeout does not count.
• Anything where the customer logged a low satisfaction score does not count.
• Audit rights. The buyer samples your billing logs, and if the error rate crosses a negotiated ceiling of around 3% to 5%, you credit the whole cohort retroactively.

Every one of those is reasonable. Together they are a second product spec, and they land on your engineering roadmap before you have collected a dollar.

Both sides start gaming the meter

Tie money to a state change and both parties optimise against the state change rather than the work.

You are incentivised to declare success as early as the contract allows. A polite summary message and a fast session close books revenue. Solving the hard underlying problem does not book any more.

The buyer is incentivised in the opposite direction. Route the final message through a human and the interaction stops qualifying. Their support team keeps using your agent for the whole workflow and pays for none of it. I have seen this pattern discussed openly in CX practitioner communities, which means your customers’ ops leads are already trading the technique.

Your gross margin inverts on exactly the hard cases

Traditional SaaS runs 75% to 85% gross margin because delivery cost is close to zero. Outcome pricing on an AI agent breaks that, because you pay for inference on every turn whether or not you get to invoice.

Run the shape of it. A complex multi-turn workflow burns roughly $0.08 to $0.25 in model cost across twelve reasoning turns. On turn thirteen the customer gives up and asks for a human. You have spent the money and you bill zero.

Now notice which queries do that. Simple questions resolve in one or two turns and are profitable. Complex ones consume the most compute and are the most likely to fail the resolution test. Your cost concentrates in exactly the interactions that generate no revenue, which is how blended margins slide toward 50% to 60% unless a platform fee is holding the floor. If your AI cost structure is not already mapped, the unit economics of AI products is the prerequisite reading before you meter anything.

Your revenue recognition gets messy

Not a fun section, but the CFO conversation is going to happen and it is better to have it before the pricing page ships.

Under ASC 606 and IFRS 15, payment tied to an uncertain future event is variable consideration, and you can only book it when a significant reversal is unlikely. A 72 hour lookback window and a customer dispute right are exactly the conditions that make reversal likely. So revenue defers until the window closes and the dispute right lapses.

For a venture-backed company reporting ARR, that is a real problem. Your recognised revenue lags the work, the ARR number gets harder to defend in a diligence process, and quarterly revenue picks up volatility it did not have when you sold seats. Talk to your accountant before you commit to a lookback window, not after.

Metering becomes a product you did not plan to build

Usage billing counts stateless events. Outcome billing tracks state machines across multi-day lifecycles, which is a different engineering problem.

You cannot commit an event to the ledger until the lookback window expires without reversal, so you need distributed state and a reconciliation process. Every line on the invoice has to be backed by an audit package: the conversation log, the state transitions, the escalation flags, the reasoning trace of whatever model made the call. You store it, index it and serve it to enterprise customers on demand. That is a team.

What buyers actually do when you offer outcome pricing

The pitch says outcome pricing removes buyer risk. Procurement disagrees, and it is worth knowing how before you build the whole thing around a benefit the buyer does not want.

CFOs buy predictability, not optimisation. Fifty seats at $1,200 is a purchase order somebody can approve. An outcome meter is an open liability. If a product recall triples support volume next quarter, the software bill triples with it. In high-volume consumer businesses the model also punishes growth: more customers means more resolutions means a bigger invoice, whether or not the business got better.

Legal slows down. With a seat contract, the vendor MSA is standard and counsel skims it. With an outcome meter, general counsel has to negotiate what success means, which exclusions apply, how long the lookback runs, what happens on a satisfaction override and who gets audit rights. Deals stall for months in that review.

Invoice verification lands on the buyer’s ops team. One enterprise IT director described spending five business days a month pulling random samples of 500 closed tickets to check whether the vendor’s model had billed them correctly. That internal labour cost comes straight out of whatever the software was supposed to save.

Past a threshold they walk back to fixed. Mid-market support teams paying $0.99 to $1.50 per resolution report abandoning outcome-metered vendors once automated volume crosses roughly 10,000 tickets a month. At $10,000 to $15,000 monthly for the AI layer alone, a fixed subscription or a few more seats simply prices better and budgets cleanly.

The math is not subtle at the top end. A 500-seat support team handling 100,000 tickets a month at a 50% deflection rate generates 50,000 automated resolutions. At $1.50 committed, that is $75,000 a month on top of seat licences, about $900,000 a year, against agent-assist tooling at $30 to $50 per seat that would run $15,000 to $25,000 a month.

One number to stop repeating while you are here. The “68% of enterprise buyers prefer outcome-based pricing” statistic that circulates in billing vendor content has no traceable analyst or academic source. It traces back to a vendor-sponsored survey that asked people whether they would like to pay for results, without mentioning overage liability, lookback windows or audit obligations. Everybody says yes to that question.

Zendesk: what a two-year outcome pricing experiment looks like

If you want one company that contains this entire argument, it is Zendesk. They ran the experiment in public, at scale, and then moved the meter.

August 2024. Zendesk launched automated resolution pricing at $1.50 per resolution on committed volume and $2.00 pay as you go, sitting on top of Suite seats at $55 to $115 per agent per month, with small bundled allowances of five to fifteen resolutions per agent.

The trouble was in the definition. A resolution counted when the customer clicked “yes, problem solved”, and also when the customer was shown an AI answer and simply said nothing. On email and web forms, silence for 72 hours counted as a resolution.

Anyone who has run a support queue knows what silence usually means. A user who gets an unhelpful bot answer does not file a complaint, they leave and call the phone line or churn. Zendesk was billing $1.50 to $2.00 for those. Meanwhile knowledge base deflections that had been free under flat plans were now metered as overages.

18 May 2026. Zendesk rebuilt it into three tiers:

• Assisted Escalation. The AI collects details and hands to a human. No charge.
• Contained Resolution. The AI handled the session to the end but the customer never confirmed anything. No charge, and it does not draw down the allowance.
• Verified Resolution. The session ended without a human, and a second language model audited the full transcript against the original request and confirmed the intent was resolved. Billable.

Read what that change actually is. Zendesk conceded that an unconfirmed session close is not evidence of value, and paid for the concession by giving away the two cheapest categories. Then they added an auditor to defend the one they kept.

They did not move closer to the outcome. They moved back one step, to the nearest thing they could prove. That is the rule from earlier, executed by a public company under customer pressure, and it cost them about twenty months to learn.

IDC’s Tapan Patel made the same point more politely in a market note on the launch: aligning cost with delivered utility only holds if the definitions are unambiguous and the buyer has the reporting to govern spend.

What older industries already learned about billing on outcomes

Software did not invent this. Performance contracting has run for decades in energy, healthcare and law, long enough for every failure mode to be documented and fixed. The lessons compress well.

Two things carry over. First, every durable outcome contract in these industries ended up hybrid, with a fixed component protecting the provider and a variable component carrying the alignment. Second, the gaming is not a character flaw in your customers. It is what happens to any metric that carries money, and the fix is always structural rather than a conversation about good faith.

How to price close to the outcome without selling one

Here is the process I run, which is really the value metric process with the outcome question folded in.

1. Build the value chain and put candidates under every step. All of them, including the ones you would never ship. The bad candidates are what make the good ones obvious. Do this before anyone opens a spreadsheet.

2. Score every candidate for measurement and attribution first. Easy, possible or hard. Hard is a no, not a maybe, and it does not get rescued on the grounds that it is the real value. A number you cannot compute is not a metric. This is where the outcome-end candidates die, and letting them die quickly is the entire point of the exercise.

3. Take the furthest-right candidate that survived. Not the furthest right on the board. The furthest right that passed step two. If that lands you in the middle of the chain, you have the right answer and you should stop feeling bad about it.

4. Wrap it so both sides can live with it. Some fixed floor covering your platform cost and their budget predictability, plus a variable layer on the metric you chose. Every serious AI company has converged on this, and they did not do it out of timidity. It is the shape the constraints force. If you are choosing the variable layer, the trade-offs in usage based pricing apply directly.

5. Write the exclusions before you sign anything. Lookback window, minimum interaction depth, bot filtering, error-escalation carve-outs, satisfaction overrides, audit rights and an annual spend cap. Draft them yourself, in your own template. If procurement writes them first you will accept worse ones.

6. Instrument the metric and run it silently for a quarter. Watch it against real accounts with no money attached. If you cannot reconcile the number to your own satisfaction with nothing at stake, your customers will not reconcile it when there is.

Who this suits: products with a programmatic completion boundary, an ops buyer who already thinks in volumes, and gross margin headroom to absorb failed runs.

Who it does not: anything whose result depends on a human doing their job afterwards, anything selling into a fixed annual budget with no volume elasticity, anything where the value is a cost the customer avoided, and any product where a single unit’s worth swings wildly between customers. Internal tooling like Jira, Linear or Retool sits several steps from anyone’s revenue and has no honest outcome to bill on. Seats are the right answer there and always will be.

Where this leaves outcome-based pricing

Outcome-based pricing is a real model that works in a narrow band: money recovery businesses sitting next to an external clearing system that already decides who won. If that is not you, then what is on offer is output pricing with better marketing, and the useful question stops being “how do we charge for outcomes” and becomes “how far toward the outcome can our metric actually reach”.

That is a better question anyway. It has an answer, you can find it in an afternoon with a whiteboard, and the answer holds up in a contract negotiation.

The founders who get burned here are the ones who picked proximity to the outcome over quality of the metric, then spent two years arguing about invoices. Zendesk did a version of that in public and walked it back. You can skip the twenty months.

Most of my work at Potio starts here, on the unit before the model, because pricing arguments that run for six months are almost always arguments about a value metric nobody ever named.

Frequently asked questions

Is outcome-based pricing the same as value-based pricing?

No, and conflating them causes real damage. Value-based pricing is a strategy for setting the number: you price from what the buyer believes the product is worth rather than from your costs, then invoice a fixed fee. Outcome-based pricing is a metering architecture: the invoice does not fire until a result is verified after the fact. You can run value-based pricing on a flat annual subscription. You cannot run outcome pricing without measurement infrastructure and contractual definitions of success.

What is output-based pricing, and how is it different from outcome-based pricing?

Output-based pricing bills for work your software completed: a resolved ticket, a qualified lead, a drafted document. Outcome-based pricing bills for a verified change in the customer’s business, like cash recovered or a fraud loss reimbursed. The names come from the inputs, activities, outputs, outcomes and impact chain used in program evaluation, and the distinction matters because an output is something you can compute and defend while an outcome usually needs a third party to adjudicate it. Almost everything sold as outcome-based pricing in AI today, including per-resolution pricing, is output-based pricing.

What do AI agents actually charge per resolution?

Published and reported rates in 2026 cluster between $0.85 and $2.50. Intercom’s Fin is $0.99 per support outcome and $9.99 per qualified sales lead. Zendesk runs roughly $1.50 committed and $2.00 pay as you go. Sierra is around $1.00 to $2.50 on custom enterprise quotes. Ada has been reported near $0.85 and Forethought near $0.90 before its acquisition by Zendesk. Almost all of these sit on top of seat licences or a platform floor, so the per-unit rate is never the whole price.

How does outcome-based pricing affect revenue recognition and ARR?

It defers revenue. Under ASC 606 and IFRS 15, outcome-contingent payment is variable consideration and can only be recognised when a significant reversal is improbable. Lookback windows and customer dispute rights make reversal probable, so recognition waits for those to lapse. In practice that means recognised revenue trails delivered work, quarterly revenue gets more volatile, and the ARR figure you report to investors is harder to defend. Get your accountant in the room before you set the lookback window.

Is per-outcome pricing better than per-seat for AI products?

Only where the completion boundary is programmatic and your margin can survive failed runs. Seats still work when the software helps a person do their job, which is why Harvey sells named legal seats and GitHub Copilot sells developer seats. Seats break when the software replaces the work, because your customer’s headcount falls exactly as your value rises. Most AI companies now run both: a seat or platform floor plus a consumption or outcome layer above it.

What should be excluded from an outcome meter?

At minimum: interactions under three exchanges, sessions from bots and scrapers, anything escalated because of a system error or timeout, anything where the customer logged a low satisfaction score, and any event where the customer makes contact again through any channel inside a 48 to 72 hour window. Add a mutual audit process with a defined error ceiling and a remedy. Write these into your own contract template rather than negotiating them one deal at a time.

Can a small SaaS company run outcome-based pricing without an enterprise contract?

Rarely, and usually not for the reason people expect. The blocker is not contract sophistication, it is that you carry the delivery cost on every failed attempt with no floor underneath you. Sierra and Decagon can market outcome pricing because six-figure platform commitments absorb the failures. Without that cushion, a run of complex customers can invert your margin in a single month. If you want to start here, put a small platform fee or a monthly minimum under the meter first. Intercom’s 50-outcome monthly minimum on external helpdesks exists for exactly this reason.