Paying for What Actually Happens: The Rise of Outcome-Based AI Pricing

There is a quiet but significant experiment happening in software pricing right now. Instead of charging a flat monthly fee for access to an AI tool, some vendors are starting to charge for what the tool actually does.

Per resolved support ticket. Per successful booking. Per document processed. Per lead qualified. Pay for outcomes, not for licences.

It sounds almost obviously better. Why would you pay the same amount whether the software delivers value or not? But dig a little deeper and you find some genuinely difficult problems hiding underneath the appealing surface.

Why outcome-based pricing feels right

Traditional software pricing has always had an awkward mismatch at its core. You pay the same subscription whether you use the product heavily or barely at all. The vendor's incentive is to get you to renew. Your incentive is to get your money's worth. Those two things are only loosely connected.

Outcome-based pricing reframes that relationship. The vendor now has a direct stake in the results. If the AI agent doesn't resolve the ticket, they don't get paid. That is a fundamentally different incentive structure, and it is one that buyers find intuitive.

It also lowers the barrier to adoption. Committing to a large annual licence for an AI tool you haven't proven yet is a hard sell internally. Committing to "we pay per outcome and cap our risk at X per month" is a much easier conversation to have with a finance team.

What AI agents make possible that wasn't before

Outcome-based pricing for software is not a new idea. The reason it never really took off is that software, traditionally, was a passive tool. It waited to be used. You couldn't cleanly draw a line between "the software did this" and "the human operator did this." Attributing the outcome to the tool was too ambiguous to price reliably.

AI agents change that equation. An agent doesn't wait to be used. It acts. It reads the support ticket, drafts the response, checks the policy, and closes the ticket. The entire resolution loop is the agent's. That makes attribution much cleaner, at least in the cases that work well.

Intercom's Fin is probably the most visible current example. It charges per outcome ($0.99) rather than per seat. Salesforce's Agentforce launched at $2 per conversation in 2024, then shifted to Flex Credits at around $0.10 per action in 2025, and now also offers per-user licences; the model is still actively evolving. These are early experiments, but they are real ones with real customers.

The pattern is becoming a template. Build a vertical AI agent, pick a measurable outcome, charge for it.

A short history of how software pricing evolved (optional, click to expand)

Software pricing has gone through roughly three eras. The first was perpetual licencing: you bought the software once, owned it, and paid for upgrades when they arrived. IBM and Oracle built empires on this model. The economics were good for vendors and reasonably predictable for buyers, as long as you could afford the upfront cost.

The second era was the subscription model, driven by SaaS in the early 2000s. Salesforce led the charge, replacing large upfront fees with predictable monthly payments. This shifted risk from buyer to vendor (who now had to keep earning the renewal) and from vendor to buyer (who now paid forever rather than once). Both sides accepted the trade. Subscriptions are now the default for almost all business software.

The third era, still forming, is consumption and outcome-based pricing. Cloud infrastructure normalised paying for what you use rather than what you could use. AWS, GCP, and Azure offer consumption pricing as the standard entry point, though large customers frequently commit to reserved or prepaid capacity for meaningful discounts. AI API providers followed: OpenAI, Anthropic, and Google all charge per token (input and output priced separately). What is new is extending that model further up the stack, past the raw API and into the finished product, charging not for calls made but for results delivered.

Each shift has carried the same underlying logic: align the vendor's incentive more closely with the buyer's actual goal. Outcome-based pricing is the most literal version of that idea yet.

The hard problems

What counts as success?

This sounds simple until you try to define it precisely. A resolved support ticket seems clear. But what if the customer marks it resolved and then emails again three days later with the same issue? What if the agent resolved it technically, but the customer left the interaction feeling frustrated? What if the resolution was correct but slow, and the customer churned anyway?

Every outcome metric has edge cases that reveal how slippery the definition actually is. Vendors will naturally gravitate towards definitions that are easy to measure and that their system can hit reliably. Buyers need to push hard on whether those definitions actually map to the value they care about.

Attribution is messier than it looks

AI agents rarely work in isolation. A support agent might handle the first three messages and then escalate to a human. A booking agent might qualify the lead, but the human salesperson still closed it. A document processing agent might extract the data, but a human reviewed and corrected it before it was used.

Who gets credit? More precisely: what fraction of the outcome is the agent's? Outcome-based pricing often simplifies this by drawing a hard line (did the agent close the ticket without human intervention?), but those hard lines can create perverse incentives. Agents that should escalate might not, because escalation doesn't count as a resolution.

Pricing the tail

Outcome-based models tend to work well for the easy cases and quietly struggle with the hard ones. Vendors report resolution rates of up to around 70% for AI support agents handling tickets fully autonomously, though real-world figures vary considerably. The remaining 30% are complex, edge-case, or sensitive enough that they need human judgment.

The hard cases cost more to handle. But under a per-resolution model, the vendor has an incentive to avoid them or to miscategorise them as outside scope. Buyers need to think carefully about what happens to the cases the model won't or can't resolve, and whether those cases end up costing more in human time than the savings from the easy ones.

The measurement infrastructure problem

To pay for outcomes, you need to be able to measure them. That requires clean data, well-defined events, and often a non-trivial amount of integration work. Many businesses do not have that infrastructure in place. The billing model is simple in principle; the plumbing required to support it is not.

This is particularly relevant for smaller organisations where data hygiene is inconsistent. If you can't reliably measure whether an outcome happened, you can't verify whether you are being billed correctly.

What value-based pricing actually requires

Outcome-based and value-based pricing are related but not identical. Outcome-based pricing charges for events (a ticket resolved, a booking made). Value-based pricing tries to charge based on the economic value those events deliver to the buyer.

Value-based pricing is conceptually purer and practically much harder. The value of a resolved support ticket depends on how much that customer spends, how likely they were to churn, what it would have cost to handle via a human agent, and a dozen other variables that differ by business. Vendors can't know most of that. So they approximate: charge a flat rate per resolution and hope it correlates well enough with value.

The honest version of value-based pricing probably looks more like a shared-savings model. The vendor gets a percentage of the demonstrable cost reduction they create. That is how management consultancies often structure performance fees. It requires trust, transparency, and good measurement on both sides. Most software markets are not there yet.

Where this is heading

Outcome-based pricing will not replace subscription models entirely. For tools where usage is hard to measure or outcomes are diffuse, subscriptions are still the pragmatic choice. But for AI agents doing discrete, measurable tasks, the pressure to move towards outcome-based pricing is going to keep growing.

Buyers will increasingly ask: why am I paying the same whether this agent handles 100 cases or 1,000? Vendors that can confidently answer that question with a per-outcome model will have a competitive edge over those still defending legacy seat-based pricing.

The winners will be the vendors who get the outcome definition right, not just the technology. And the buyers who benefit most will be the ones who do the work upfront to define what value actually looks like for their business, before they sign anything.

How AI with Ash can support you

If you are evaluating AI agents for your business, the pricing model is only one piece of the puzzle. The harder question is whether the agent will actually deliver consistent value in your specific context, and how you would know if it wasn't. That is worth thinking through carefully before you commit.

If you want a clear-eyed look at the options and what they mean for your operation, book a call and we can work through it together.