Per-Resolution Pricing Is Training AI Support Vendors to Optimize for the Wrong Number
Three pricing models are running in the artificial intelligence customer support market right now. The oldest is per-seat, a flat monthly fee per agent, the model on which Zendesk and Freshdesk built their businesses. The newest is per-resolution, where you pay only when the AI closes out a conversation, the model on which Intercom's Fin agent runs at 99 cents a resolution. In between sits a hybrid: a seat fee for your human team plus a per-resolution charge for whatever the AI handles on top, which is where most vendors have landed as they bolt AI onto existing seat-based products.
Per-resolution pricing sounds like the fair one. You are not paying for agents sitting idle, you are paying for problems solved. That pitch has real appeal for support leaders watching seat costs climb every time they add headcount. But it depends entirely on one word doing a lot of work: resolution.
Here is what that word means in practice at Intercom, the vendor that has leaned hardest into per-resolution billing. According to Intercom's own documentation, a conversation counts as resolved in one of two ways. Either the customer confirms Fin's answer solved the problem or the customer simply stops replying after Fin's last message, what Intercom calls an "assumed resolution." Both outcomes get billed at the same 99 cents. A customer who says "yes, that fixed it" and a customer who reads a wrong answer, gives up, and leaves the chat window open in frustration are, from a billing standpoint, identical events.
That is not a hypothetical edge case. It is the second half of the billing model, built into the product by design, and it means the number vendors report as a resolution rate is measuring something closer to "conversations that ended" than "problems that got solved."
Buyers comparing vendors on resolution rate are comparing a mix of two very different things without a way to tell them apart. A tool that closes 70 percent of conversations because it genuinely answers the question looks identical, on the dashboard, to one that closes 70 percent because customers give up and go elsewhere for help. Neither Intercom's public materials nor most competitors' pricing pages break out what share of billed resolutions were confirmed by the customer vs. assumed because they went quiet.
The cost of getting this wrong is not abstract. In February 2024, a British Columbia tribunal ruled against Air Canada in a case brought by a customer named Jake Moffatt. Moffatt had asked the airline's chatbot about bereavement fares after his grandmother died, and the bot told him he could book a full-price ticket and apply for the discount retroactively. That was wrong. Air Canada's actual policy required the bereavement request before travel. Air Canada argued in the tribunal that the chatbot was a separate entity responsible for its own words. The tribunal disagreed and held the airline liable for everything on its website, chatbot included, awarding Moffatt money to cover the fare difference and his costs.
Nothing about that exchange would have shown up as a failed resolution on a dashboard. Moffatt got an answer, the conversation ended, and by any reasonable per-resolution accounting, it closed. The problem only became visible months later, in a tribunal ruling, after the wrong information had already been acted on. A metric built around whether the conversation ended does not have a category for "ended with an answer that was confidently, costly wrong."
None of this means per-resolution pricing is a bad model. Deflecting genuinely simple, repetitive questions at a fraction of the cost of a human agent is real value, and for high-volume, low-complexity queries, it is often the more honest way to pay, closer to usage than to headcount. The problem is treating the headline resolution number as if it already accounts for accuracy, when by its own definition it does not.
What this means for anyone evaluating these tools: ask the vendor directly what share of their reported resolutions are customer-confirmed vs. assumed. If they cannot or will not break that out, treat the resolution rate on their pricing page as a ceiling, not a track record. Ask which error-detection process runs on assumed resolutions specifically, since those are, by definition, the ones nobody checked. And before signing a contract sized around a resolution-rate estimate, pull a sample of your own transcripts and score them for actual accuracy, not just whether the customer stopped talking.
The gap between "the conversation ended" and "the problem got solved" is where per-resolution pricing quietly optimizes for the wrong number. It is not that the vendors are hiding this, Intercom's own documentation states the assumed-resolution rule plainly. It is that almost nobody asks.
Owen Zhang is editor of CommsAdvisor.com, where he tests and compares contact center, help desk, and customer support software for buyers evaluating vendors like Zendesk, Freshdesk, and Aircall. He previously worked as a software engineer, including a stint at Huawei, before moving into independent B2B software reviews.