Summary: Outcome pricing makes sense as the way forward for AI assistants since they do more and more of the work that customers can measure. It is not easy to do well, however. Before charging customers based on outcomes, vendors must have proof that the outcome occurred and was caused by the vendor’s software.
Charging for a resolved support ticket sounds straightforward. An AI agent does the work, the customer gets the result, and the vendor charges for it.
In practice, defining exactly what has been delivered is much harder. A ticket might be marked as resolved, but that does not necessarily tell you whether the agent resolved it, whether a human intervened, or whether the customer considers the issue closed. If that result is going to appear on an invoice, both sides need to be working from the same evidence.
This is becoming more important as AI changes how customers perceive the value of software. The latest research from Thales and IDC on software licensing and monetization found that 55% of buyers expect AI capabilities to be included at no additional cost, while 35% expect to pay more.
Vendors that want to charge separately for AI need to make the value clear.
Why Outcome Pricing Is Arriving Anyway
Software has traditionally been relatively easy to package around access. Customers might pay for a certain number of users or subscribe to a particular edition. That becomes less useful when an AI agent is completing work that previously required several people.
This is already affecting the way vendors think about pricing. Strategy& sees agentic AI pushing software toward measures such as meetings booked or support tickets resolved, rather than the number of people using the product.
There is pressure on the vendor side, too. AI brings compute and model costs that change with consumption. Two customers paying the same subscription fee may generate very different costs depending on how heavily they use AI capabilities.
Usage-based pricing offers one way to account for that variation. Outcome pricing takes the idea further by aligning the charge more closely with the result the customer receives. Both depend on something quite practical: the vendor has to know what happened in production and be able to count it accurately.
That gets considerably harder once the unit being counted is an outcome.
Can You Measure the Result?
Consider a customer support agent. A vendor could define its outcome as a resolved ticket, but “resolved” can mean several things. Perhaps the agent supplied an answer. Perhaps the customer accepted that answer. Or perhaps the ticket needs to remain closed for a defined period before anyone considers the problem resolved.
The definition matters because the event needs to be captured reliably. If confirming an outcome requires someone to look into the customer’s systems or wait until a quarterly review, it will be difficult to use as the basis for routine billing.
McKinsey gives a useful example of this problem. It describes an AI-native sales development company that allows customers to pay either per qualified lead or per outreach. Ninety percent chose the activity-based option, in part because agreeing on what constituted a qualified lead made the outcome model cumbersome.
Before adding an outcome to the price list, ask whether your system can automatically recognize and record it when it occurs. When deciding what to measure, vendors need to define the commercial model. That means understanding the market, what competitors are doing, and where customers see value.
They can then decide how tightly usage needs to be controlled. That might mean leaving usage fully open, setting a soft limit with a notification and grace period before overage billing begins, or applying a hard limit that blocks further use. High-value software, particularly where usage is expensive to meter, may justify harder limits. A new product trying to capture market share may start with no limits at all.
Will the Customer Agree That Your Agent Caused It?
Even a measurable outcome can be difficult to attribute. Suppose an AI agent drafts an answer to a support request and a human employee edits it before sending it. The ticket subsequently closes. Deciding how much of that outcome belongs to the agent is not as straightforward as it once was.
The same problem appears when several systems contribute to a transaction or when an agent initiates work that a person ultimately completes. This also becomes a commercial issue as soon as money is attached to the result. The vendor needs a record of the agent’s actions that can support the charge if the customer questions it.
There is a useful parallel with overage charges. One of the biggest sources of billing disputes is runaway usage. A customer may ignore limit and grace-period notifications, continue consuming the software, and then dispute an unexpectedly large bill even though the charges are covered by the contract.
Vendors can reduce that risk by intervening before the invoice arrives. Account managers need visibility into high overage rates so they can contact customers early, while customer portals can provide near-real-time usage information alongside email notifications. That gives customers a chance to see consumption building before it becomes an unexpectedly large bill.
A useful test is whether you could show a customer the evidence behind a disputed outcome charge today. If the answer depends on piecing together records after the event, the pricing model could well be ahead of the infrastructure supporting it.
Can You Control What Happens While the Agent Is Running?
AI agents also introduce a less visible problem. The amount of work required to achieve the same outcome can vary. An agent may need several attempts to complete a task, invoke other tools, or consume substantially more compute than expected. The vendor needs a way to control that activity before costs start to accumulate.
Customers need similar protection. IDC’s buyer research found that runaway costs are the biggest concern around consolidating software relationships, cited by 74% of respondents. The same concern becomes particularly relevant when autonomous software can generate consumption without somebody approving every action.
Commercial controls need to operate while the software is being used, and customers need visibility into their consumption before it becomes a billing problem. When an agent reaches the limits of a customer’s plan, the system needs to apply the terms that have already been agreed. That might mean notifying the customer, stopping further activity, or permitting additional use that will be billed.
Finding out what happened when the invoice is prepared is too late.
Build the Evidence Before Charging for the Outcome
For many vendors, usage-based pricing is likely to be the practical route toward outcome pricing.
It allows them to collect production data and learn how consumption relates to the results customers receive. Over time, history can show whether a particular outcome is sufficiently stable to serve as a useful pricing metric.
The underlying commercial systems need to develop alongside it. Entitlement management provides a way to define what each customer has purchased and apply those rights as the product is consumed.
This is especially relevant given the volume of change vendors are already managing. More than 60% have already added AI capabilities to their products, and 76% report that AI is prompting them to consider new pricing models. At the same time, only 3% are fully confident that their licensing currently meets customer expectations.
For most AI vendors, outcome pricing is therefore something to work toward rather than rush into. The first job is to establish exactly what happened in production, how the agent contributed, and whether the customer’s commercial terms were applied correctly.
Once a vendor can answer those questions from its own systems, it has the evidence needed to decide whether an outcome is ready to become something it sells.
