A support leader I spoke with last year pushed her automated resolution rate from 41% to 68% in a single quarter. She trimmed handle time, rewrote her knowledge base, and tuned the routing logic. Her reward showed up in the renewal quote: the annual cost had almost doubled. Nothing about the vendor's product had changed. The bot simply got better at its job, and her per-resolution contract billed her for every extra ticket it closed.
That is the trap hiding inside the most popular AI support pricing model of 2026. Per-resolution pricing sounds fair - you only pay when the AI actually solves something. For a pilot or a small team, it is genuinely the safest way to buy. But the same mechanic that de-risks a pilot turns punitive at scale, and most buyers do not run the math until the second-year invoice lands. This is a model-versus-model comparison: per-resolution, outcome-based, and flat-fee (including self-hosted). The goal is to help you find the crossover point before you commit a budget to the wrong side of it.
The three ways vendors charge for AI support
Support AI pricing has splintered into a few families, and vendors rarely use the same words for them. Here is the plain version.
Per-seat is the legacy CX model. You pay per human agent license, the way you always paid for Zendesk or a helpdesk. It makes almost no sense for AI, because the entire point of AI support is that you need fewer seats, not more. Any vendor still pricing pure AI deflection per seat is pricing against the value they claim to deliver.
Per-conversation charges for every conversation the bot touches, resolved or not. It is simpler to forecast but you pay for failures, abandonment, and spam alongside real wins. Fin has a useful breakdown of why per-resolution and per-conversation pull in different directions.
Per-resolution charges only when the AI closes a conversation without a human. Intercom's Fin made the $0.99 resolution the industry reference point, and a wave of platforms followed. The pitch is honest incentive alignment: the vendor gets paid when you get value. Independent roundups now track a whole category of per-resolution-priced platforms, and a comparison of per-resolution versus per-seat shows why the seat model is fading.
Outcome-based is per-resolution's more ambitious cousin. Vendors like Sierra tie the fee to a defined business outcome, sometimes a specific resolution type or a CSAT threshold. Same billing family, tighter definition, usually a higher unit price.
Flat-fee and self-hosted break the pattern. You pay a fixed platform fee (or run the system yourself) and cover your own model inference. There is no per-unit vendor markup that scales with volume. Your bill tracks your infrastructure, not your success rate.
The debate that matters for a growing team is per-resolution against flat-fee. Everything else is a variation on those two cost shapes.
Model the cost curve before you sign
Consumption pricing feels cheap because you meet it at low volume, on a sales call, with a friendly unit price. The problem is that the number you should care about is the slope of the line, not the point where you start.
Here is an illustrative model. Assume a realistic 65% automated resolution rate for a well-tuned Tier 1 bot, a per-resolution rate at both the common $0.99 and a discounted $0.50, and a rough raw inference cost of about $0.05 per handled conversation (a multi-turn chat with retrieval, run on a mid-tier model). These are illustrative figures - your inference cost shifts with model choice, context length, and guardrails - but the shape holds.
| Monthly conversations | Resolved (65%) | Per-resolution @ $0.99 | Per-resolution @ $0.50 | Raw inference (~$0.05) |
|---|---|---|---|---|
| 10,000 | 6,500 | ~$77k/yr | ~$39k/yr | ~$6k/yr |
| 100,000 | 65,000 | ~$772k/yr | ~$390k/yr | ~$60k/yr |
| 1,000,000 | 650,000 | ~$7.7M/yr | ~$3.9M/yr | ~$720k/yr |
At 10,000 conversations a month, per-resolution is a rounding error on most budgets and the risk-sharing is worth the premium. At 1,000,000, the same contract at $0.99 runs to roughly $7.7M a year while the underlying compute costs closer to $720k. Even after you load in a real platform license, retrieval infrastructure, monitoring, and a small operations team, a flat-fee or self-hosted deployment at that volume tends to land somewhere between $1M and $2M fully loaded. The per-resolution contract is charging you several times your true marginal cost, and the gap widens with every ticket you deflect.
This is the arithmetic behind total-cost comparisons of AI pricing models: consumption pricing is a straight line through the origin, and flat-fee is a line with a fixed intercept and a near-flat slope. Somewhere between 10k and 100k monthly conversations, those two lines cross. The exact crossover depends on your resolution rate and negotiated unit price, but for most teams doing serious Tier 1 automation it arrives faster than the sales conversation implies.
Key takeaway: run the projection at three times your current volume with your real resolution rate. If the per-resolution line has already crossed a flat-fee alternative at that point, you are signing up to pay a growth penalty.
The per-resolution pricing problem: getting taxed on your own deflection
The cost curve is the mechanical issue. The incentive structure is the deeper one.
Per-resolution pricing couples your vendor's revenue to your automation rate. That alignment is the selling point, and at pilot stage it genuinely protects you. But past the crossover point it inverts. Every improvement your team makes - a better knowledge base, cleaner routing, a fine-tuned prompt - increases the number of billable resolutions. You are doing the engineering work, and the vendor collects the upside. You get taxed on deflection you built.
The second issue is the word "resolution" itself. It is a metered unit that the vendor defines, and the definitions vary more than buyers expect. Some platforms count a resolution whenever the customer stops replying within a set window. That sounds reasonable until you realize it bills you for people who got confused and abandoned the chat, or who found the answer elsewhere and never came back. A frustrated customer who gives up looks identical to a satisfied one in that metric. When your unit cost is tied to a definition you do not control, the vendor has quiet leverage over your bill.
Voice makes this sharper. Production voice deployments have longer, messier interactions and fuzzier resolution boundaries, and real benchmarks from 2026 voice deployments show how much the definition of a completed call drives cost. A per-resolution model on voice, without a tight and audited definition, is an open-ended meter.
None of this means per-resolution vendors are acting in bad faith. Most are not. It means the model's incentives point away from yours the moment you succeed, and you should price that in rather than assume goodwill will hold across a renewal.
Where each pricing model actually wins
There is no universally correct model, and any consultant who tells you otherwise is selling one. Here is the honest breakdown.
| Situation | Best-fit model | Why |
|---|---|---|
| Pilot or first 90 days | Per-resolution | You want the vendor sharing risk while you prove value. Pay only for outcomes. |
| Low or seasonal volume (<10k/mo) | Per-resolution | The premium is small and forecasting is easy. |
| Unpredictable volume, thin ops team | Outcome-based or per-resolution | You avoid paying for a flat capacity you may not use. |
| High, steady Tier 1 volume (100k+/mo) | Flat-fee or self-hosted | The per-resolution meter compounds; a fixed fee flattens the curve. |
| Data-sensitive or regulated | Self-hosted | You control the model, the data path, and the cost, with no per-unit markup. |
| Deep custom workflow, not just FAQ deflection | Custom build (flat-fee) | Per-resolution products optimize for generic deflection, not your process. |
The pattern that catches teams out is graduating from the first row to the fourth without renegotiating. You buy per-resolution to de-risk a pilot, the pilot works, volume climbs, and you never revisit the model because switching feels like work. Two years later you are paying seven figures for a meter you outgrew. Analysts who track SaaS pricing have watched the same drift, and writers like Kyle Poyar at Growth Unhinged document how usage and outcome pricing quietly reprice as customers scale.
Choose per-resolution deliberately, with a written plan for when you will re-evaluate. Do not let it become the default just because it was easy to start.
The questions that expose the real cost
Before you sign any AI support contract, put these in an email and get written answers.
- How exactly do you define a resolution? Get the trigger condition in writing. Does an abandoned chat count? A deflection to a help article? A customer who does not reply in 24 hours?
- What does this cost at 3x my current volume? Make them build the projection with your resolution rate, not a demo rate.
- Is there a volume cap or a tier where the model flips to flat-fee? Many vendors offer a committed-use discount that behaves like a flat fee. Ask before you need it.
- What are your rate-increase terms at renewal? A per-resolution contract with an uncapped rate increase is a blank check on your own growth.
- Can I move to self-hosted or export my configuration? Portability is your only real leverage. If you are locked in, the meter runs on the vendor's terms.
If a vendor cannot answer the resolution definition question crisply, treat that as the answer. The pricing model families overview from Fin is worth reading precisely because it comes from a per-resolution vendor being candid about the tradeoffs.
How OpenNash CX Can Help
OpenNash CX is built for the far end of that cost curve: teams with high, steady Tier 1 volume who do not want to pay a growth penalty every time their automation improves. The pricing is flat-fee, available cloud or self-hosted, and it does not charge you more for resolving more. Your budget is predictable, and the savings from better deflection stay with you instead of flowing back to a per-resolution meter.
The way we work maps cleanly onto the decision this article lays out:
- Audit: we model your real cost curve across per-resolution, outcome-based, and flat-fee at your projected volumes, so the choice is arithmetic, not a sales pitch. If per-resolution genuinely wins for your volume, we will tell you.
- Design: we define the resolution logic, escalation paths, and human-in-the-loop approvals up front, so "resolved" means what you say it means, not what a meter decides.
- Build and deploy: we implement against your actual workflows, not a generic FAQ bot, with the guardrails and audit logs an operations team needs after launch.
- Ownership: the system is yours. Self-hosted if your data demands it, exportable either way, with no per-unit markup between you and your own compute.
If you are choosing a platform for a pilot, per-resolution is often the right first move. If you are already past the crossover point and watching the meter climb, that is the conversation we are built for.
Book a call to map your volume and resolution rate to the pricing model that actually wins for your team.