AI companies have started charging for outcomes

A first look at outcome-based AI pricing: why per-resolution charging is becoming real, why support agents got there first, and why the hard part is defining what counts as an outcome.

AI companies are starting to charge for outcomes. Instead of billing purely for seats, tokens, or usage, some vendors are billing for the thing the agent claims to finish.

That sounds like the most obvious thing in the world. If an AI agent solves a customer problem, charge for the solved problem. If it does not solve the problem, do not charge. Simple.

The definition underneath the pricing page matters most:

What counts as solved?

Once you ask that, the whole thing gets much more useful.

The old software price was easier to understand

Most software pricing has been based on things that are fairly easy to count: seats, usage, credits, API calls, storage, tasks, conversations.

Those units may be annoying, but at least they are mechanical. You used the thing, so you pay for the use.

AI agents put pressure on that model because the sales pitch is not “we give you a tool to use.” The pitch is closer to:

Give the agent work and it will do some of it for you.

That changes the commercial question.

If the agent is acting like a worker, should the customer pay for access to the worker, the time the worker spends, or the jobs the worker finishes?

That is where outcome-based pricing comes in.

Where this is already real

The clearest examples are in customer support AI. That makes sense. Support work has tickets, conversations, escalations, reopens, queues, and relatively clean logs. It is one of the few places where you can plausibly say: this problem was handled by the AI, and no human had to step in.

Here is the short version.

Major vendors are experimenting with pricing AI work differently from traditional SaaS.

But the table also shows the catch.

Most of the clean examples are support-agent examples. Once you move away from support into sales, operations, document handling, bookings, or consulting, the word “outcome” gets slippery very quickly.

The awkward bit: silence can look like success

The support world often uses some version of this logic:

1. Customer asks for help.
2. AI responds.
3. Customer does not ask for more help.
4. Conversation is counted as resolved.

Sometimes that is fair. If I ask how to reset a password, the AI tells me, I reset it, and I go away, that is probably a resolution.

But silence is not always satisfaction.

The customer might have given up. They might have switched to phone. They might have emailed a human. They might have accepted a bad answer because the support surface trained them that arguing with the bot was pointless.

That is the problem with “resolved” as a billing unit. It feels objective until you inspect the definition.

Zendesk’s newer automated-resolution mechanics are interesting because they try to formalise the definition: no human handoff, a quiet period, and a verification layer. That is better than a hand-wavy “the AI handled it” claim. It is still a contract around a proxy.

And that is the real lesson:

Outcome pricing is mostly proxy pricing.

A resolved ticket is a proxy for a helped customer. A qualified lead is a proxy for future revenue. A booked appointment is a proxy for business value. A completed workflow is a proxy for operational progress.

Some proxies are clean. Some are rubbish.

Clean outcomes, messy outcomes, fake outcomes

The useful question is: what kind of outcome are we talking about?

That last column is where buyers should slow down.

The vendor does not get to define the outcome alone. If the vendor controls the agent, the dashboard, the metric, and the invoice, the customer is not buying outcome pricing. They are buying trust in the vendor’s interpretation of events.

That may be fine with the right vendor and the right contract. Auditable outcome pricing needs a record the customer can inspect.

Why support got there first

Customer support has the right ingredients: high volume, repetitive questions, existing ticket systems, clear escalation paths, timestamps, reopen data, conversation logs, and measurable human deflection.

That is why support AI is the first place where this pricing model looks real.

It is also why I would be careful extrapolating too far.

Charging per resolved support conversation is simpler than charging per saved customer, per closed sale, per completed project, or per improved business outcome. The further away you get from a logged event, the more the pricing model becomes an argument about causality.

And causality is expensive.

Did the AI create the outcome, help with the outcome, or just happen to be nearby when the outcome happened?

That is where invoices turn into arguments.

The small-operator version needs a narrow evidence trail

The tempting move is to say: if Intercom can charge per resolution, a consultant or automation business should charge per outcome too.

Maybe. The pure version creates trouble quickly.

For a small operator, pure contingency is usually a trap. It creates all the wrong incentives:

• the provider wants to count more outcomes
• the client wants to reject borderline outcomes
• both sides argue about attribution
• edge cases become billing fights
• a good month can create invoice shock
• a bad month can make the provider work for free

The safer pattern is hybrid:

base fee plus a narrow, auditable success component.

The base fee pays for setup, monitoring, maintenance, risk, and the fact that the system exists whether this month is busy or quiet.

The success fee only applies where the outcome is narrow enough to count cleanly.

For example:

• a catering enquiry with date, guest count, event type, and valid contact details confirmed by the client
• a trades job request created inside ServiceM8 or Tradify
• a new-patient appointment marked attended in Cliniko or Nookal
• a group-booking enquiry captured with dates, room count, contact details, and source tag

The phrase that matters is: the client’s system of record says it happened.

The operating rule

If I were designing this for a real business, I would start with the evidence trail:

1. What exact event counts?
2. Which system records it?
3. Who can edit or confirm it?
4. What is excluded?
5. How long is the attribution window?
6. What happens if the customer comes back unhappy?
7. What is the monthly cap?
8. How does the client dispute an item?

Vague answers mean the pricing model needs more design.

That is the practical lesson hiding inside the trend. Outcome pricing is mainly an evidence-design problem.

The invoice comes last.

What to watch

The next market test is whether vendors publish the trigger definitions.

Do they say what counts as resolved? Do they explain the quiet period? Do they exclude human escalations? Do they show what happens when the customer reopens the issue? Do they let the customer audit billed outcomes? Do they cap spend before a spike turns into a nasty invoice?

That is where the real market will sort itself out.

The serious vendors will define the unit.

The weaker ones will sell the vibe.

My take

I like this model more than I expected to because it forces a better conversation. If software is going to do work, then buyers and builders have to get much more precise about what “done” means.

That is a better conversation than counting seats and hoping the work happened.

The old SaaS question was: how many people need access?

The AI-agent question is sharper:

What work did it finish, and how do we know?

That is the part worth watching.

Outcome pricing exposes the hidden contract behind AI agents. The agent is valuable when it completes work that someone can verify.

And if nobody can verify the work, it probably should not be priced as an outcome.

Sources

• Intercom pricing
• Fin AI pricing and usage limits
• Zendesk outcome-based pricing announcement
• Zendesk automated resolutions documentation
• Gorgias AI Agent pricing
• HubSpot Breeze pay-per-result coverage
• Sierra on outcome-based pricing for AI agents
• Salesforce Agentforce flexible pricing
• Decagon: what is resolution-based pricing?
• Siena AI critique of outcome-based AI pricing
• Bessemer: AI pricing and monetization playbook