Why 'Pay Per Resolution' AI Pricing Can Cost More the Better It Works

Per-resolution pricing has become the dominant model for AI customer support agents in 2026, and the pitch is genuinely appealing: instead of paying for seats or message volume regardless of whether the AI actually helped anyone, you pay only when it resolves something. Vendors in this space are now charging somewhere in the neighborhood of a dollar per resolved conversation, and on the surface that reads as the fairest arrangement available, aligned incentives, pay for value delivered. Underneath that pitch sits a structural problem that most buyers don't fully register until the bill starts climbing.

The Bill Grows Exactly When the Product Is Working

Almost every other software pricing model has a built-in ceiling that tracks something predictable, seats, message volume, API calls, that a buyer can budget against in advance. Per-resolution pricing inverts that relationship: the better the AI performs, the more resolutions it logs, and the higher the bill climbs, with no natural ceiling tied to anything except how much of your support volume the AI successfully handles. That's a genuinely different risk profile than it sounds like on first read. Paying only for outcomes is a reasonable, even favorable, deal when volume and AI performance are both uncertain and a buyer wants to avoid paying for a tool that doesn't work. It becomes a much less favorable deal once the AI is working well and handling a large share of ticket volume, because success is now the thing driving cost upward with no discount kicking in to offset it. A team that adopted this pricing specifically because the AI's effectiveness was unproven ends up facing its largest bills exactly once that uncertainty is resolved in the AI's favor.

The Real Lever Isn't the Rate, It's the Definition

Every vendor in this category quotes a per-resolution rate, and it's tempting to shop primarily on that number. The more consequential variable is one that rarely appears next to the price: what actually counts as a resolution. One vendor might count any conversation the AI touched and didn't explicitly escalate as a resolution. Another might only bill when a customer explicitly confirms their issue was solved, and never charge for a conversation that ends in escalation to a human. Those are two entirely different cost structures wearing the same per-unit price tag, and a vendor charging a lower headline rate with a loose definition of resolution can end up costing more in practice than a vendor charging a higher rate with a strict, customer-confirmed definition.

This matters because "resolution" isn't a standardized term across the industry the way, say, an API call is. Each vendor defines it according to their own product and billing logic, and that definition is precisely the lever that determines whether the pricing model is actually fair in practice or just fair-sounding in the pitch.

The Incentive Problem This Creates

A vendor whose revenue scales directly with the number of conversations counted as resolved has a built-in commercial interest in a generous definition of resolution, closing conversations quickly and confidently rather than escalating anything ambiguous to a human, because escalation is typically unbilled while a marked resolution is billed revenue. That doesn't necessarily mean any specific vendor is gaming this deliberately, but the incentive structure exists regardless of intent, and a support leader adopting this pricing model without scrutinizing it is trusting the vendor's definition of success to also be a customer's definition of success, with no independent check in between unless one gets built deliberately.

How This Compares to Older Software Pricing Risk

It's worth contrasting this against the pricing risks buyers are more used to managing. Seat-based pricing risks paying for capacity nobody uses, a familiar, well-understood waste that shows up clearly on a license utilization report. Usage-based pricing (per API call, per message) risks a bill that scales with activity regardless of whether that activity produced value, but at least the meter itself, an API call, a message sent, is objectively countable and rarely in dispute. Per-resolution pricing combines the worst instincts of both: the bill scales with activity like a usage model, but the unit being counted, a "resolution," is a judgment call the vendor makes about their own product's success, not an objective technical event. That combination is what makes this pricing model worth more scrutiny than either of the models it's often compared favorably against.

What to Pin Down Before Signing a Per-Resolution Contract

None of this is a reason to avoid per-resolution pricing outright, it's a genuinely reasonable model for a team facing real uncertainty about AI performance and volume. It is a reason to negotiate the specifics rather than accepting the headline rate at face value:

• Get the exact definition of "resolution" in writing. Does it require explicit customer confirmation, or does it default to billing after a timeout with no negative response? The gap between those two definitions can represent a large share of total spend.
• Confirm what happens on escalation. A conversation that starts with the AI and ends with a human closing it out should not, in almost any reasonable framing, count as an AI-billed resolution, but this needs to be explicit in the contract rather than assumed.
• Ask whether there's a customer-satisfaction gate on billing. A model that only bills when a customer confirms the fix worked is structurally more aligned with actual value delivered than one that bills based on conversation closure alone.
• Model the cost at higher volume, not just current volume. Since this pricing model has no natural ceiling, project what the bill looks like if the AI successfully handles two or three times the ticket volume it handles today, not just what it costs at today's usage.
• Audit a real sample of billed resolutions manually. Once live, periodically pull a sample of conversations the vendor billed as resolutions and check whether the underlying issue was actually solved, not just whether the conversation ended without an explicit complaint.

Why This Model Is Spreading Now, Specifically

It's worth being clear-eyed about why per-resolution pricing has become the default in this category over the last year rather than treating it as a purely buyer-friendly innovation that happened to arrive now. AI support agents only became reliable enough to resolve a meaningful share of conversations without human involvement fairly recently, and outcome-based pricing became commercially viable for vendors at exactly the moment that reliability crossed a threshold where the vendor could be confident of collecting on most conversations rather than absorbing the risk of a low resolution rate. That's not a criticism of the model itself, a vendor pricing based on actual delivered value is reasonable, it's a reminder that the shift happened because it started working in the vendor's favor, not because vendors collectively decided buyers deserved a fairer deal. Understanding that framing helps explain why the definition of "resolution" tends to drift toward whatever counts more conversations as billable, rather than toward the strictest, most customer-centric definition available.

Fair-Sounding Isn't the Same as Fair

Outcome-based pricing earns its reputation as the buyer-friendly option because it removes the risk of paying for a tool that does nothing. It doesn't automatically remove the risk of paying more than the value actually delivered once the tool starts working, and that second risk is the one that shows up on an invoice months into a contract rather than during the sales conversation. The fix isn't skepticism toward the pricing model itself, it's treating "resolution" as a negotiable, auditable term rather than a given, before it becomes the thing quietly driving a support budget upward every month it succeeds.

A buyer who negotiates the definition upfront, gets escalation handling written into the contract, and commits to periodic manual audits ends up with a pricing model that behaves the way the sales pitch described. A buyer who accepts the headline rate and assumes the rest will sort itself out is the one explaining an unexpectedly large invoice to finance a quarter after rollout, wondering why the tool's apparent success came with a bill that grew faster than anyone had budgeted for.