Outcome-based pricing: are we ready to pay for results rather than software?
What if businesses stopped paying for licences or seats and paid only when the technology actually delivered results? Agentic AI is making outcome-based pricing increasingly practical, but defining success is easier said than done. Who decides whether an AI agent really resolved a problem?
Once upon a time, businesses typically bought software upfront. Then subscriptions, SaaS and cloud computing popularised other models, from per-user fees to charges based on storage, compute consumption and API calls.
Enterprise software has often been priced using metrics that are easy to count. But AI is threatening to disrupt that progression again.
Say an AI agent can resolve a customer enquiry, prevent a customer from leaving or successfully complete a sales process – then why should a business pay for the software it used or the tokens it consumed? Why not just pay for the result instead?
This is the promise of outcome-based pricing; rather than charging customers for access, effort or consumption, suppliers link part of their revenue to measurable business results.
It sounds like the next logical step in enterprise software pricing, but beneath that simplicity lies the question: who owns the risk when the expected outcome isn't achieved?
From outputs to outcomes
Service industries have experimented with variations on outcome-based pricing for decades. Managed service contracts frequently include SLAs and penalties, while other industries have adopted performance-based contracts in which supplier compensation depends partly on measurable results.
Charging for an AI customer service agent according to token consumption is input-based, whereas charging per support case closed is output-based. Charging for problems genuinely resolved moves closer to true outcome-based pricing.
| Input-based pricing | Output-based pricing | Outcome-based pricing | |
|---|---|---|---|
| AI customer support | Pay for LLM tokens, API calls or processing time used by the AI agent. | Pay for each customer conversation handled or ticket closed. | Pay only for customer issues that are successfully resolved, according to an agreed definition of resolution. |
| Customer retention | Pay for compute, API calls or agent interactions used to identify and contact at-risk customers. | Pay for each retention offer generated or customer contacted. | Pay for customers successfully retained for an agreed period, potentially subject to profitability or other conditions. |
| Network fault management | Pay for AI processing, monitoring capacity or time spent analysing network data. | Pay for each fault detected, diagnosed or remediation action completed. | Pay for faults successfully resolved, or against an agreed improvement in service availability, performance or customer experience. |
A typical customer service case might pass between a chatbot, contact centre agent and engineer. Now, if an AI agent handles it from beginning to end, its actions can be logged and linked to a more clearly defined workflow – although that does not necessarily prove the customer’s problem was resolved.
The further a pricing model moves from charging for inputs towards charging for outcomes, the more closely the supplier’s returns align with the customer's objectives – and the more risk the supplier potentially assumes.
Who determines the bill?
Suppose an AI agent detects that a subscriber is considering leaving, offers them a personalised discount and the customer stays. A success undoubtedly, but what if the customer never really intended to leave?
Maybe the AI offered such a generous discount that the customer was retained at the expense of profitability. Maybe network quality improved at the same time, or a competitor increased its prices – business outcomes are rarely as binary as traditional usage metrics.
The problem becomes even more significant if the supplier gets to define the metric itself. Outcome-based pricing is supposed to align incentives between buyer and vendor, but that alignment can break down if the vendor is the sole arbiter of what “success” looks like.
Outcome-based pricing makes measurement part of the product. In customer service, that could mean examining repeat contact across different sessions, abandonment after weak answers, subsequent human intervention and customer satisfaction rather than simply accepting a vendor's headline “resolution” metric.
What does a successful result look like?
Paying an AI customer support provider for successful resolutions rather than messages or tokens sounds hard to disagree with, until you question what “resolved” actually means.
The closer that pricing moves towards those final business outcomes, the more attractive the alignment becomes – but the harder the attribution.
Goodhart's law states that “when a measure becomes a target, it ceases to be a good measure.” So if an AI supplier gets paid for every conversation classified as successfully resolved, “resolution” becomes a commercial target as well as a measure of customer service performance, potentially making it less reliable.
The desired outcome might be that the customer’s problem is genuinely solved, but, as that is difficult to observe directly, the contract might use a measurable proxy. For example, no response from the customer within 36 hours might be treated as a resolution, even though they may have given up, been slow to reply, opened another support channel or solved the problem themselves.
This could incentivise the agent supplier to close conversations earlier or interpret silence as success, improving the measured resolution rate without improving the actual customer experience. Suddenly, a claim of a “90% resolution rate” tells us much less than it first appears.
This doesn’t make outcome-based pricing unworkable, but it makes the definition and auditing of outcomes critical.
Who pays for unsuccessful attempts?
An AI agent might consume LLM tokens, make API calls, query databases and use third-party services while attempting a task.
However, if the attempt fails and the customer pays nothing, the vendor is still on the hook for those costs – a particular risk for computationally expensive applications.
Adopting a hybrid model is one solution, in which a supplier charges a consumption or platform fee covering underlying costs, with another portion of the price linked to agreed outcomes. Alternatively, customers might pay for completed tasks, with performance incentives or penalties attached to wider business KPIs.
Straightforward usage-based pricing may also make sense in some situations. If the customer pays the same amount for the same consumption while the agent becomes more effective, they get more value from the same expenditure.
Who owns the risk?
With a conventional subscription, much of the risk sits with the customer. The software vendor provides the application; whether the organisation uses it effectively enough to meet the expected business case is largely the customer’s problem.
Outcome-based pricing shifts some of that risk to the supplier. If the vendor only gets paid when the desired result occurs, it has a direct financial incentive to improve its technology and help the customer succeed.
But the supplier cannot control every factor that influences the outcome. A vendor might provide an excellent retention agent, but it cannot necessarily compensate for poor network coverage, uncompetitive tariffs or bad customer data. Equally, a sales agent cannot force customers to buy an unattractive product, and a collections agent cannot make somebody pay money they simply don’t have.
Software providers are therefore likely to accept more outcome risk when they have sufficient control over the end-to-end workflow. However, gaining that control may require deeper integration into the customer’s systems and processes, potentially making a SaaS product much more bespoke.
From selling software to selling success
Telecoms providers are familiar with evolving charging models, from minutes, texts and megabytes to subscriptions, bundles and differentiated services. Now, as CSPs explore new AI-enabled services, they may also need to support commercial models linked to actions and outcomes. That means managing more complex relationships between products, usage, contractual conditions, KPIs and results – putting product catalogue, charging and billing capabilities at the heart of the commercial model.
The commercial framework must be used to determine whether contractual conditions have been satisfied, calculate the resulting charges and provide an auditable explanation.
Different customers may also want different commercial arrangements, from subscriptions and consumption pricing to per-transaction charges or hybrid performance contracts.
Outcome-based pricing is unlikely to replace subscriptions or consumption pricing entirely. Plenty of outcomes are too subjective; others take too long to materialise. Many depend on factors beyond supplier control, and vendors can’t go on indefinitely eating the cost of unsuccessful AI activity.
Yet existing models have their limitations too. AI is exposing the weakness in charging on a per-seat basis when it reduces the number of people required to perform a process. Charging per token may accurately reflect the supplier’s costs, while bearing little relationship to what the customer values.
The likely answer is therefore a mix of subscriptions, consumption, transactions, outputs and outcomes, forcing both customers and suppliers to be more precise about what they are buying and selling.
Where pricing is tied to outcomes, the hardest part is agreeing what success means and who shoulders the risk when reality doesn’t match.
Whatever pricing models take hold, CSPs need the flexibility to monetise services in ways that reflect how customers increasingly want to consume and pay for them. Find out how Cerillion’s Enterprise Product Catalogue helps CSPs define and manage the products, pricing and commercial rules that underpin new services.