Resolution-Based Pricing Explained: How Vendors Bill

Created time

Jun 3, 2026 07:59 AM

Title length (<60)

Author

Mike Heap

Ecomm?

What resolution-based pricing is, and why everyone switched to it

⚡

TL;DR: Resolution-based pricing charges a fixed fee (roughly $0.30 to $2) each time the AI resolves a ticket on its own. The pitch is aligned incentives, but the vendor gets to decide what counts as resolved.

Resolution-based pricing charges a fixed fee each time the AI resolves a support ticket on its own, with no human stepping in. Most of the market sits between roughly $0.30 and $2 per resolution (we see all of these on our customers' old invoices).

To put faces to it: HubSpot Breeze runs in the $0.30 to $0.99 range, Gorgias Automate around $0.90 to $1.00, Intercom Fin at $0.99, Zendesk's automated resolution at $1.50 on committed volume (or $2 pay-as-you-go), and Decagon reportedly $2 to $3. The pitch is identical across all of them: you pay for results, rather than for seats or messages.

That pitch is genuinely attractive, which is why nearly every vendor moved to it. The vendors that sell the model hardest argue it reduces risk for the buyer: if the AI doesn't deliver, you don't pay. Sierra puts it plainly: "you pay only when the software achieves specific, valuable outcomes."

Here's the catch. A "result" is not a fixed unit like a kilowatt-hour. It's a definition, and the vendor owns it.

The clearest tell is what Intercom did in late 2025. It renamed its per-resolution charge to "per-outcome" and folded configured handoffs (cases where the AI passes the conversation to a human or a workflow) into what counts as a billable outcome.

Same product, broader definition, more billable events. When the unit you're buying can be redefined by the party sending the invoice, the headline rate stops being the number that matters.

The three layers underneath every per-resolution price

⚡

TL;DR: Every per-resolution price has three hidden layers: the Trigger (what event fires the charge), the Window (how long it must hold), and the Authority (who decides it counted). These three set your bill, far more than the headline rate does.

Every per-resolution price has three layers sitting under the headline rate. I call them the Resolution Definition Stack, and they're where your real cost is set.

Breakdown diagram: the Trigger, Window and Authority layers feed into what you actually pay.

The rate sits on top, where you can see it. These three sit underneath, where most buyers never look.

Layer	The question it answers	The one test to apply
Trigger	What single event puts a charge on my invoice?	"What exact action fires the meter: an answer, a confirmation, or a handoff?"
Window	How long does a resolution have to hold before it counts?	"If the customer comes back angry an hour later, do I pay twice?"
Authority	Who or what decides it was resolved, and can I dispute it?	"Can I reconcile the vendor's count against my own helpdesk export?"

Layer 1: the Trigger

The Trigger is the event that fires the charge. The narrowest, most buyer-friendly trigger is an explicit customer confirmation: the customer says "yes, that solved it." The broadest is a configured handoff that the vendor still counts as a resolution, which is exactly what Intercom folded in with its rename.

In between sit a deliberate "AI resolved" tag the vendor sets (Decagon's approach), and an inferred close where the AI sent a final answer and nothing else happened. The difference isn't cosmetic. A trigger that fires on "AI sent an answer" bills you for every confident reply, including the wrong ones; a trigger that fires on "customer confirmed" bills you only for the replies that landed.

Layer 2: the Window

The Window is how long a resolution has to stick before the charge becomes final. The tightest, most honest window in the market is Zendesk's 72-hour quiet period, where the ticket has to stay closed and the customer must not reopen it before the resolution counts.

If the customer comes back inside three days, no charge. It's the one to beat.

Plenty of vendors have no window at all. The charge fires on the event, and a reopen the next hour bills you a second time for the same underlying issue. As one industry guide put it, "a resolution counted after 5 minutes of customer inactivity is fundamentally different from one verified by an AI quality check." Ask where the window sits before you sign, because it governs how many times you pay for one unhappy customer.

Layer 3: the Authority

The Authority is who, or what, gets to decide a ticket was resolved, and whether you can audit or dispute that decision. This is the layer buyers think about least and pay for most.

Some vendors use a deliberate tag but won't show you the logic behind it (word-on-the-street is that Decagon's tag is set, but the mechanism stays opaque). Some infer resolution from a non-reply, the way Gorgias counts a ticket where the customer simply didn't respond. Some bill per "interaction cycle" that the vendor instruments internally, where, as Aissist's own docs effectively concede, the buyer can't always audit what counts as one cycle versus two.

The common thread: the meter reads against logic you don't control and often can't see. Competitors charging per outcome use vendor-defined resolution logic, and that logic frequently counts ambiguous conversations (the customer wandered off, the AI gave a plausible but incomplete answer) as resolutions.

The test for this layer is the most important question in the whole purchase. Can you take the vendor's resolution count for the month and reconcile it, line by line, against the resolved-ticket export from your own helpdesk? If you can't, you're paying against a number you cannot check.

The same rate, three different bills

⚡

TL;DR: Run real vendors through the Stack and the same headline rate produces very different bills. Our data from 195 deployments shows the metric label alone moves the number about twelve points, and per-resolution billing charges you more as your AI improves.

Run the Stack across the vendors we deal with day to day and the "standard" per-resolution price fragments immediately. Same headline meter, materially different bills.

Vendor	Trigger	Window	Authority
Intercom Fin	AI resolves end-to-end, or a configured handoff completes	Not publicly enumerated	Vendor logic; renamed resolution to outcome in late 2025
Zendesk Autoresolve	AI resolves with no human	72-hour reopen window (tightest)	Reopen-based; the cleanest to audit
Gorgias Automate	Automation handles the ticket	None stated	Inferred from customer non-reply
Decagon	Deliberate "AI resolved" tag	Not stated	Vendor-set tag, mechanism opaque
Sierra	Customer-confirmed outcome	Not stated	Escalations don't charge (buyer-aligned)
Aissist	One automation cycle, or a resolution (whichever is cheaper)	Not stated	Cycle boundary vendor-instrumented; hard to audit

There's a deeper reason the definition matters so much, and it's measurable. We pulled resolution-rate data from 195 real deployments across more than 55 vendors, and the single biggest finding was that the metric label moves the number by about twelve points. Deployments measured as "resolution" post a median rate of 72.5%; the same kind of work measured as "automation" posts 61%.

Stat callout: resolution-labelled deployments median 72.5%, automation-labelled 61%, a 12-point gap from the label alone.

Same underlying capability, different yardstick, twelve points of difference, purely from what the vendor chose to call it and count. (Those are field aggregates, directional rather than apples-to-apples, since every vendor defines its metric differently. The full dataset and method are in our AI resolution-rate benchmarks.) That twelve-point gap is the Authority layer made visible: the definitional slack that inflates a published rate is the exact same slack you're billed against under per-resolution pricing.

Then there's the part that surprises buyers most. Under resolution-based pricing, your bill goes up as your AI gets better. It's the improvement tax.

At 10,000 tickets a month and Zendesk's $1.50 per resolution, an AI that climbs from a 40% to an 80% resolution rate takes your bill from about $6,000 to about $12,000 a month, for handling the same ticket volume. We've written the full maths up in our breakdown of per-conversation versus per-resolution pricing. The short version: the meter rewards the vendor for the improvement, and most of that improvement is work you did (better knowledge, connected APIs, tuned guidance, a weekly review habit).

Before-after: at 40% resolution the bill is $6,000 a month; at 80% it is $12,000, same ticket volume.

That trajectory isn't a corner case. Across the field, the median AI-handling rate is 70%, and the 75th percentile is 80%, so a climb from the low 20s into the 70s and 80s is the normal arc of a deployment. We've watched it happen again and again.

Spectrum of AI-handling rate: low-by-design 26%, P25 56%, median 70%, P75 80%, mature 95%.

TravelJoy: 24% to 80%

TravelJoy, a platform for travel advisors, ran Zendesk's own AI and saw a 24% resolution rate. After switching, they reached 80% across roughly 2,500 to 2,700 tickets a month, saving 193 hours monthly at an 86% AI CSAT.

Their Head of Customer Service, Alan Pugh, put it like this:

"In comparison to Zendesk's AI agent, we're now achieving an impressive 76% AI resolution rate, versus just 24% before." Alan Pugh, Head of Customer Service at TravelJoy.

On a $1.50 per-resolution meter, that climb from 24% to 80% would have more than tripled the AI line on their invoice.

Edel Optics: 25% to 79%

Edel Optics, a European eyewear retailer, jumped from around 25% to 79% resolution, a rise of roughly 50 points more or less overnight, after their own team connected the User Data API so the AI could see order, delivery and return information. They handle 4,000-plus tickets a month at a 92% AI CSAT.

The lift came from work Edel Optics did themselves; we just gave them the User Data API to switch on. Under resolution-based pricing, the vendor would have captured most of the upside of that customer-side work as a higher bill.

Kriptomat: the rejection

Kriptomat, an EU crypto exchange, looked at Intercom Fin at $0.99 per resolution and rejected it as uneconomical before deploying. They now run at a 62% resolution rate across about 1,700 tickets a month. The maths simply didn't work for a team that knew its volume and could see where its rate was heading (and frankly, I don't blame them).

The pattern operators describe on community threads matches what we see in the data. On a thread in r/B2BSaaS, one founder who'd priced a product on outcomes summed it up: "But in practice? Budget unpredictability, lack of control over outcomes and all the complications when customers don't fully follow through on their side."

What to do this week

⚡

TL;DR: Before signing, ask the vendor the three Stack questions in writing, then reconcile one month of their resolution count against your own helpdesk export. The gap between the two is your real price.

If you're weighing up a resolution-based contract, you can pressure-test the definition in an afternoon. I'd do four things, and not one of them is an argument about the rate.

Put the three Stack questions to the vendor in writing. Ask exactly what event triggers a charge, whether there's a reopen window and how long it is, and who decides a ticket counts as resolved. Get the answers in the contract rather than the sales call. Fifteen minutes, and it's the highest-leverage thing you'll do in the whole evaluation.

Model your bill at two resolution rates. Take today's rate and a rate 50 points higher, and run the monthly cost at both. If the higher number scares you, you've found the improvement tax before it found you. Thirty minutes.

Reconcile one month against your own export. Pull a month of resolved tickets from your helpdesk and compare the count to the vendor's billed resolutions. The gap between the two is your real price. Around two hours, and it's the only test that actually checks the Authority layer.

Check the window against your reopen rate. Look at your actual reopen rate and see how the vendor's window (or lack of one) interacts with it. Twenty minutes.

This is also the honest case for a generous free trial. We run a 30-day one partly so buyers can see their real number before they commit.

There's an estimate at day seven and the exact go-forward cost by day thirty, because, as most buyers find, you only really learn what a meter costs you once you're inside it. Whatever vendor you're looking at, insist on seeing that real number before you sign.

How do I get an AI to audit a vendor's resolution definition for me?

I'd hand the heavy lifting to an LLM here. Paste this into ChatGPT, Claude or Gemini, fill in the brackets, and it'll run the Resolution Definition Stack against whatever the vendor sent you. It can't see your invoice, so it flags what you still need to confirm.

You are helping me evaluate an AI customer support vendor that uses resolution-based (per-resolution) pricing. Analyse their pricing using the "Resolution Definition Stack" — three layers that decide my real bill:

1. TRIGGER — what single event fires a charge? (an AI answer / a customer confirmation / a configured handoff?)
2. WINDOW — how long must a resolution hold before it counts? (e.g. a reopen window like Zendesk's 72 hours, or none?)
3. AUTHORITY — who or what decides a ticket was resolved, and can I audit or dispute it against my own helpdesk export?

Here is what the vendor told me:
[paste the vendor's pricing page text, contract clause, or sales-email answer]

Here is my context:
[your helpdesk, monthly ticket volume, current AI resolution rate, and where you expect it to be in 12 months]

Output a table with one row per layer: what the vendor's definition is, how buyer-friendly it is (tight / loose / unclear), and the exact question I should send the vendor to pin it down. Then estimate how my monthly bill changes if my resolution rate rises 50 points. For anything the vendor hasn't stated, write "unverified — ask the vendor" instead of guessing.

Run the output past the vendor before you sign. Desk analysis can model the bill, but only your own helpdesk export can tell you whether their count and yours agree.

When resolution-based pricing is actually the right call

⚡

TL;DR: Resolution-based pricing genuinely suits buyers whose resolution rate is already high and stable, who want to hand delivery risk to the vendor, or whose ticket volume is impossible to forecast.

I'll be straight with you: resolution-based pricing isn't a trap in every case. There are buyers it genuinely suits, and pretending otherwise would be unfair.

If your resolution rate is already high and stable, say you're already near the field's 80th-percentile ceiling of 80%, the improvement tax has very little room to bite. There's a limit to how far a resolution rate can climb, and a buyer who's already near it isn't going to watch their bill double. For that buyer, I'd say a success meter is perfectly reasonable.

If you actively want to hand delivery risk to the vendor, resolution-based pricing does that by design. You're paying a premium for the vendor to carry the downside, and some teams rationally prefer that. Sierra, for one, doesn't charge on escalations at all, which is a genuinely buyer-aligned choice within the model.

And if your ticket volume is wildly unpredictable (sharp seasonal spikes, a launch-driven business), a meter tied to outcomes can be easier to stomach than one tied to raw volume, because it flexes with what the AI actually handles. The improvement tax mostly punishes the teams climbing from a low base. If that's not you, the model may fit.

✅

Resolution-based pricing fits if…

Your AI resolution rate is already high and stable (near the field's 80% ceiling), so the improvement tax has little room to bite

You want the vendor to carry delivery risk and you're happy to pay a premium for it

Your ticket volume swings too wildly to forecast, and an outcome meter flexes with it

❌

Avoid resolution-based pricing if…

You're climbing from a low resolution rate (the 20s or 30s), where the improvement tax doubles your bill as you get better

You can't reconcile the vendor's resolution count against your own helpdesk export

The vendor won't put the Trigger, the Window and the Authority of its definition in writing

Read the definition beneath the rate

⚡

TL;DR: The rate is the least informative number in a resolution-based quote. Decompose the Trigger, the Window and the Authority before you sign, because the vendor writes all three.

The rate on the pricing page is the least informative number in a resolution-based quote. The Trigger, the Window and the Authority decide what you actually pay, and all three are written by the vendor.

I'd decompose them before you sign, and reconcile one month of the vendor's count against your own helpdesk export. That gap is the price you can't see on the page.

For what it's worth, this is the structural reason we price per ticket rather than per resolution. You pay when the AI works, counted against your own helpdesk export, so there's no vendor-controlled definition of "resolved" to audit in the first place.

The bill stays flat as the AI improves, which means your cost per resolved ticket falls instead of rising as your rate climbs. (We count a ticket as resolved when it wasn't escalated to a human, and we keep escalation deliberately easy rather than claiming to know an issue was solved without the customer confirming it. That's our resolution metric, though, rather than our meter.)

That's a different post. This one just argues that whichever model you choose, you should read the definition underneath the rate. If you want the field data behind the rates quoted here, our AI resolution-rate benchmarks is the place to start, and we walk through our own per-ticket alternative in our pricing explainer.

FAQs

How much does resolution-based AI customer support cost?

Most vendors charge between roughly $0.30 and $2 per resolution. From what we see across our customers' helpdesks, HubSpot Breeze sits in the $0.30 to $0.99 range, Intercom Fin at $0.99, and Zendesk at $1.50 to $2. But the headline rate is only half the cost: what you actually pay depends on how the vendor defines and counts a "resolution," so two vendors at the same rate can produce very different bills.

What counts as a "resolution" in AI support pricing?

It depends entirely on the vendor, and I think that's the whole problem. Some count a resolution only when the customer confirms the issue is solved; others count an AI answer with no reply, an inferred close, or even a configured handoff to a human. Many bill against vendor-defined logic that counts ambiguous conversations as resolved, so the only safe move is to demand the exact definition in writing before you sign.

Does resolution-based pricing get more expensive as my AI improves?

Yes, and that's the improvement tax. Because you pay per resolution, doubling your resolution rate roughly doubles your bill for the same ticket volume. At 10,000 tickets a month and $1.50 per resolution, a climb from 40% to 80% takes the bill from about $6,000 to $12,000, which we walk through in our per-conversation versus per-resolution pricing breakdown.

What's the difference between resolution-based and outcome-based pricing?

Resolution-based pricing is one kind of outcome-based pricing. "Outcome-based" is the umbrella term for any agreed result (a resolved ticket, a saved cancellation, an upsell), while "resolution-based" specifically meters on resolved support tickets. The line blurs in practice: Intercom renamed its per-resolution charge "per-outcome" in late 2025 and widened what counts, which we cover in our outcome-based pricing explainer.

What's the difference between resolution-based and per-conversation pricing?

Per-conversation pricing meters on every conversation the AI has, resolved or not; resolution-based pricing meters only on the ones it resolves. Per-conversation is more predictable, since you can roughly forecast conversation volume, but you pay for unresolved chats too. Our per-conversation versus per-resolution comparison runs them side by side.

How do I check whether a vendor's resolution count is accurate?

Export a month of resolved tickets from your own helpdesk and reconcile that count against the vendor's billed resolutions. The gap between the two numbers is the definition spread: the difference between what you'd call resolved and what the vendor charges for. If you can't run that reconciliation because the vendor's logic is opaque, treat it as a red flag.

Is resolution-based pricing better than usage-based pricing?

It depends on where your resolution rate is heading. If it's already high and stable, a resolution meter can be fine; if you're climbing from a low base (the normal arc, since the field median is 70% and most teams start in the 20s or 30s), usage-based pricing keeps your bill flat and lets you capture the upside of your own improvement work. Our pricing explainer walks through how the per-ticket version works.

What resolution rate should I expect from AI customer support?

Across 195 real deployments and more than 55 vendors, the median AI-handling rate is 70%, with the middle of the field sitting between 56% and 80%. Industry matters far more than company size: Education and Travel sit near the top, Telecom and Manufacturing lower. Bear in mind the metric label moves the number by about twelve points, so compare like with like; the full dataset is in our AI resolution-rate benchmarks.

Resolution-based pricing, explained: what actually counts as a "resolution"

What resolution-based pricing is, and why everyone switched to it