Blog
Outcome based pricing: define resolved first
Outcome based pricing charges per result, so the contractual definition of the result, not the rate, decides your bill. Define resolved before you sign, because whoever writes that definition controls the meter, and a loose one quietly bills you for activity that never solved anything.
Key takeaways
- Outcome based pricing ties the fee to a result, so the definition of that result is the most important term in the contract.
- Zendesk pioneered per resolution pricing for automated support, and the model is spreading across AI features in 2026.
- A loose definition that counts deflections, escalations, and repeat contacts inflates the bill with non resolutions, so the buyer must define resolved tightly and in writing.
- The rate matters far less than what the rate is charged on, so the definition, not the price per unit, is where the negotiation is won.
What is outcome based pricing in SaaS?
Outcome based pricing charges for a result rather than for access or activity, for example a fee per automated support resolution rather than per agent seat or per message handled. Zendesk pioneered this model for automated resolutions, and it is spreading fast as vendors attach AI features to outcomes they can charge against. The appeal to buyers is real: in principle you pay only when the software delivers value, which aligns the vendor's revenue with your result. In practice, that alignment holds only if the outcome is defined the way you would define it, not the way the vendor would.
This is the third meter in the 2026 shift from seats toward usage, agents, and outcomes, and it is the one that hides the most risk. A seat is easy to count and a unit of usage is usually clear, but an outcome is a matter of definition, and definitions are negotiable. That is why outcome pricing belongs squarely in AI pricing defense, and why the discipline for it sits in our AI Pricing Defense Guide. The vendor will arrive with a definition. Your job is to make sure the one in the contract is yours.
Why must you define resolved before signing?
You must define resolved before signing because the definition of the outcome decides what you pay, full stop. Consider the difference. If resolved means a genuine, complete resolution that closed the customer's issue without further contact, the meter counts real value and the alignment works. If resolved counts any conversation the system touched, including deflections that sent the customer elsewhere, escalations that handed the problem to a human, and repeat contacts where the same issue came back, then the meter counts activity, not value, and the bill inflates with interactions that solved nothing.
The danger is that the loose definition looks reasonable on the surface and only reveals itself in the invoice. A vendor whose system "engages" thousands of conversations can bill for all of them under a loose definition of resolved, even when many of those conversations failed to resolve anything and some made matters worse by frustrating the customer into a second contact. Whoever writes the definition controls the meter, so it must be the buyer. This is the same principle that makes the outcome definition a contract clause in its own right, which we break down in the outcome definition clause.
| Interaction type | Loose vendor definition | Tight buyer definition |
|---|---|---|
| Issue closed, no repeat | Counts as resolved | Counts as resolved |
| Escalated to a human | Often counts as resolved | Excluded, the system did not resolve it |
| Deflected to a help article | May count as resolved | Excluded unless the issue actually closed |
| Repeat contact, same issue | Each contact may count | Counted once at most, or excluded |
How does a loose definition inflate the bill?
A loose definition inflates the bill by counting everything the system touches as a billable outcome, so your cost rises with volume rather than with value. Three categories do most of the damage. Escalations, where the AI could not solve the problem and handed it to a human, should plainly not be a resolution the AI gets paid for, yet a loose definition often counts them. Deflections, where the customer was pointed at a help article and may or may not have been helped, are frequently counted as resolved without any evidence the issue closed. And repeat contacts, where the same unresolved issue generates a second and third conversation, can each be billed, so a failure to resolve becomes a multiplier on the invoice rather than a deduction.
The perverse result is that a worse performing system can cost more under a loose definition, because every failed interaction that generates a follow up adds to the count. The buyer ends up paying most when the software works least, the exact opposite of what outcome pricing promises. This is why the definition cannot be left to the vendor's standard terms. A precise, buyer written definition that excludes escalations, requires genuine closure for a deflection to count, and de duplicates repeat contacts keeps the price tied to value as intended. The wider set of AI billing traps and how to disarm them sits in our AI Pricing Defense Guide.
How do you negotiate an outcome based pricing contract?
You negotiate an outcome based pricing contract by treating the definition as the centre of the deal and the rate as secondary. Start by defining the outcome precisely and in writing: state exactly what counts as resolved, and just as importantly what does not. Exclude escalations to a human, exclude deflections that do not end in genuine closure, and de duplicate repeat contacts on the same issue so a single problem cannot be billed multiple times. The narrower and clearer the definition, the closer the meter stays to real value.
Then build the protections around it. Require transparent reporting that lets you audit the count against the definition, because a meter you cannot inspect is a meter you cannot trust. Cap total spend with a consumption ceiling, so an unexpected surge in volume cannot produce an unbounded bill, the same protection you would secure on any usage meter. And set a baseline period before per outcome billing begins, so both sides can observe real behaviour and confirm the definition is producing sensible numbers before money changes hands. Each of these is a standard consumption protection applied to the outcome meter, and together they keep the model honest.
A worked example
Indicative example. A buyer evaluating an AI support tool on per resolution pricing found the vendor's standard definition counted every engaged conversation, including escalations and deflections, as a resolution. Modelled against the buyer's actual contact mix, that definition would have billed for a large share of interactions that never closed an issue. The buyer rewrote the definition to count only genuine closures, excluded escalations and unclosed deflections, de duplicated repeats, added an audit right and a consumption ceiling, and ran a baseline period first. The effective cost fell substantially because the meter now counted value rather than activity. The figures here are indicative and shown to illustrate the mechanics.
How does outcome pricing fit the wider meter shift?
Outcome pricing fits the wider meter shift as the furthest point on a spectrum that runs from seats, through usage, to outcomes, with each step moving the basis of the bill further from something the buyer can easily count. Seats are simple. Usage units, credits, messages, compute, require benchmarking to compare but are at least measurable. Outcomes add a layer of definition on top, because the unit itself is a matter of contractual agreement rather than a physical quantity. Analysts expect a large share of enterprise SaaS spend to move toward usage, agent, and outcome models by 2030, so this is not a niche concern.
The through line for the buyer is the same at every step: control the meter. For usage that means consumption ceilings and benchmarking. For agents it means understanding what triggers a billable action. For outcomes it means owning the definition. A buyer who carries that single instinct, never accept a meter you do not control, into every one of these models is equipped for the whole transition. The AI premium that often rides alongside these meters, and the carve out that contains it, is covered in the AI carve out clause, and the full defense runs through our AI Pricing Defense Guide.
What is the move before you sign?
Define resolved before anything else. Write the outcome definition yourself, exclude escalations and unclosed deflections, de duplicate repeat contacts, and put it in the contract in plain language. Add an audit right so you can inspect the count, a consumption ceiling so the bill cannot run away, and a baseline period before billing starts. Negotiate the definition harder than the rate, because the rate is only as good as what it is charged on. The full method sits in our AI Pricing Defense Guide, and a strategy call is the place to pressure test your definition before you sign.
Own the definition before you sign.
Use the AI Pricing Defense Guide to defend every AI meter, draft the term with the outcome definition clause, and contain the premium with the AI carve out clause.
Book a Strategy Call →Frequently asked questions
What is outcome based pricing in SaaS?
Outcome based pricing charges for a result rather than for seats or usage, for example a fee per automated resolution rather than per agent or per message. Zendesk pioneered the model for automated support resolutions, and it is spreading because vendors can tie price directly to value delivered. The catch is that the result must be defined contractually, because whoever defines it controls the bill.
Why must you define resolved before signing an outcome based contract?
Because the definition of the outcome decides what you pay. If resolved counts any conversation the system touches, including deflections, escalations, and repeat contacts, the bill inflates with activity that did not actually solve anything. A tight definition that counts only genuine resolutions keeps price tied to real value. Whoever writes the definition controls the meter, so it must be the buyer.
How do you negotiate an outcome based pricing contract?
Define the outcome precisely and in writing, exclude escalations, repeats, and partial interactions from the count, require transparent reporting you can audit, cap total spend with a consumption ceiling, and set a baseline period before per outcome billing begins. Treat the definition as the heart of the negotiation, because the rate matters far less than what the rate is charged on.
Published market figures reflect 2026 SaaS pricing analyses and are labelled indicative where appropriate.