Outcome-Based Pricing
Quick Answer: Outcome-based pricing is a pricing model where the buyer pays for a defined result an AI agent delivers, such as a resolved ticket, instead of paying per seat, per hour, or per token.
Outcome-based pricing means you pay for a result, not for access or effort. The agent resolves a support ticket, and you pay for the resolution. It does not, and you pay nothing for that one.
It sits at one end of a spectrum. Per-seat pricing charges for people with a login. Usage pricing charges for tokens or calls. Outcome pricing charges for the work product.
Real examples
Vendors have been moving this way, mostly in customer service, where an outcome is easy to count.
Zendesk. In its August 2024 announcement, Zendesk said it moved to pricing for AI agents tied to automated resolutions, so customers incur costs for issues the AI resolves autonomously. A starter usage level is included at no extra cost.
Intercom. Intercom’s pricing page lists its Fin AI agent at $0.99 per outcome. The page says an outcome counts when the customer confirms the issue is resolved or when they do not ask for more help after Fin responds. Note how loose “no further question” is as a definition. I will come back to that.
Salesforce. Salesforce offers two metered options for Agentforce, announced in May 2025. One is $2 per conversation. The other is Flex Credits, where one agent action uses 20 credits, or $0.10. That is usage pricing at the action level. It is closer to outcomes than seats, but a billed action is not the same as a solved problem.
The pattern: the closer the unit is to the business result, the more the vendor shares the risk.
Why buyers like it
- You do not pay for software that sits unused.
- Cost scales with value delivered.
- The vendor is motivated to make the agent work.
- Budget conversations get easier: the price per resolution compares to your cost per human-handled resolution.
What can go wrong
Outcome pricing is only as good as the outcome definition.
- Soft outcomes. “The customer did not reply” can mean the problem was solved or the customer gave up. A vendor paid on non-replies has a reason to count both.
- Easy-case bias. The agent handles the simple tickets, which you could have automated cheaply. The hard ones still go to humans.
- Attribution. If the customer’s problem was fixed by a status page update, who gets the credit?
- Quality gaps. A cheap resolution that causes a repeat contact is a cost, not a win.
- Unbounded bills. A spike in volume or a looped agent can multiply charges.
- Measurement control. If the vendor measures the outcome, you must be able to audit it.
How to define an outcome
I use five tests. A good outcome is:
- Specific. “Refund request closed with the correct amount” beats “ticket handled.”
- Verifiable. A system of record confirms it, not only the agent’s own report.
- Attributable. You can tell the agent did it, not a person or another tool.
- Durable. It stays done. Add a window, such as no reopen within seven days.
- Auditable. You get the underlying records.
Then add guardrails in the contract: a monthly cap, a baseline for what counts as new volume, a sampling right to review outcomes, and a dispute process.
A short example
Say a retailer’s returns desk gets 10,000 requests a month. A vendor offers a flat fee per approved-and-processed return, not per conversation. The contract defines an outcome as a return label issued and the refund posted in the order system, with no reopen in 14 days. The buyer can sample 200 outcomes a month for review. Fees cap at an agreed ceiling. The vendor now cares about correct policy decisions, not chat volume.
The numbers in that example are made up to show the structure.
When it fits
It works best where the unit of work repeats, the result is visible in a system of record, and the baseline cost is known. See AI agent ROI for building the baseline, and AI agents for customer service for the sector where this model is most common. It fits poorly for open-ended work like research, where “done” is a judgment call.
For a buyer’s view of the finance side, read the CFO guide to AI agent investment.
Common mistakes
- Accepting the vendor’s outcome definition without tests.
- Skipping a baseline, so you cannot tell if you are saving money.
- No cap.
- Ignoring quality metrics next to volume.
- Assuming it removes your integration and governance work. It does not.
Questions to ask a vendor
- Exactly what counts as an outcome, and who decides?
- Can we audit every billed outcome against our own records?
- What happens when a billed outcome gets reopened?
- Is there a monthly cap or a volume band?
- How is a baseline set, so growth in volume is not billed as new value?
- What are the minimums, if any?
- What happens to the price if quality drops?
If a vendor resists these, the pricing may be outcome-flavored while the risk still sits with you.
Related terms
An AI agent is what delivers the outcome. Agentic workflows are the multi-step processes behind it. The venture studio model sometimes pairs with outcome pricing, because both involve shared risk.