Mike HeapMike is an experienced Product Manager who focuses on all the “non-development” areas of My AskAI, from finance and customer success to product design, copywriting, testing and more.
Table of Contents
- Why this debate exists, and the four models you have to compare
- The Five Tests to apply to any AI pricing model
- Test 1: Predictability
- Test 2: Alignment
- Test 3: Improvement tax
- Test 4: Lock-in
- Test 5: Support load
- What this looks like in real rollouts
- TravelJoy: when the improvement tax does the deciding
- Kriptomat: when predictability does the deciding
- Edel Optics: when the customer-engineering question does the deciding
- What to do this week
- When the other models actually win
- The takeaway
- Pros and Cons summary
- FAQs
Last Updated
Created time
May 27, 2026 01:27 PM
Title length (<60)
Author
Ecomm?
Image
Publish date
May 29, 2026
Slug
per-conversation-vs-per-resolution-pricing
Featured
Featured
Type
Article
Ready to Publish
Ready to Publish
Per-conversation pricing taxes you for trying. Per-resolution taxes you for succeeding. Per-reply taxes the natural shape of customer conversations. Per-seat ignores AI quality entirely. Five tests to pick the model that doesn't punish you for getting better.
Last week I was on a call with a Head of CX who'd just been quoted by two AI vendors. Different headline rates, sure. But more importantly, two completely different pricing models.
She wanted me to tell her which one was cheaper. The honest answer is: it depends on what your AI does next.
Most AI vendors will only ever volunteer one of these models to you: the one that flatters their margin. That model might be the right one for you, or it might not.
This post is the cleanest way I know to find out.
I'm Mike, co-founder of My AskAI. We help 4,500+ teams run AI customer service inside Zendesk, Intercom, HubSpot, Gorgias, and Freshdesk. We sit through these procurement conversations every week and watch teams either pick the model that suits their volume curve, or get blindsided by it six months in.
The buyer-side guidance below is what most of the SERP misses (see Withorb's seller-side guide or the r/AI_Agents seller threads for that view).
Why this debate exists, and the four models you have to compare
TL;DR: Four AI customer service pricing models exist: per-ticket (My AskAI ~$0.10), per-reply (Aissist $0.09 + $0.60 cap), per-resolution (Fin $0.99, Zendesk $1.50, Sierra/Decagon non-public), and per-seat (Freshdesk Freddy $35/agent/mo). Vendors only ever pitch the one that flatters their margin.
Most procurement spreadsheets compare two vendors on the same pricing model. They don't compare two models against each other.
That's how teams end up six months in, suddenly realizing the model itself is the problem (more than the specific vendor).
Here's the four-model landscape every CX buyer is actually choosing between. We'll work through each one with concrete examples from the vendors most likely to show up in your evaluation.
Per-ticket.
Often pitched as "per-conversation". The unit is a discrete helpdesk ticket, and your helpdesk already counts it. We use this model at My AskAI; the effective rate is around $0.10 per ticket.
Other vendors describe a similar idea using "conversation" as a looser word. Sometimes that means a back-and-forth thread within a single ticket, sometimes a 24-hour session, sometimes just a synonym for ticket. The exact definition matters, so ask for it in writing.
Per-reply (or per-interaction).
Each AI message is billed. The clearest public example here is Aissist, which charges $0.09 per AI interaction OR $0.60 per resolution, whichever is lower.
Aissist defines an interaction as "one automation cycle from user input to AI response, including all automation steps within that flow." So every back-and-forth exchange counts as one interaction. The per-resolution cap exists because, without it, a multi-turn customer conversation would balloon the bill.
Per-resolution.
The dominant AI customer service model, and pretty much the one to beat in terms of mindshare. Intercom Fin charges $0.99 per outcome (the term Fin renamed "resolutions" to in late 2025), with a 50-outcome-per-month minimum standalone.
Sierra charges per agreed outcome (non-public list price). Decagon does the same, with anecdotal rates between $2 and $3 per resolution from buyers we've spoken to. Zendesk's Autoresolve is $1.50 per automated resolution, with a 72-hour "quiet period" before the charge fires.
Gorgias Automate ranges from $0.90 to $1 per automated resolution depending on plan. HubSpot Breeze sits in the $0.30 to $0.99 band. Ada is also per-resolution.
Per-seat (or per-agent).
The heritage model from the human-support era. The AI is sold as a copilot attached to a seat.
Freshdesk Freddy Copilot is $35 per agent per month, and Zendesk's Advanced AI add-on is $50 per agent per month. Salesforce Agentforce is more of a hybrid: $2 per conversation handled by the agent, sold in agent-attached tiers.
Per-seat is the right model when the AI is genuinely a copilot to a human rather than an autonomous resolver.
A quick note on what My AskAI actually does, because the per-ticket headline simplifies the underlying mechanic. The literal billing unit is a credit, and the credit math is channel-specific.
Helpdesk chat: every 2 AI replies = 1 credit (effective ~$0.10 per chat ticket). Helpdesk email: first AI reply = 1 credit, each follow-up question = 0.5 credits (effective ~$0.15 per email ticket). The widget: 1 credit per 1-hour session, unlimited messages within that hour.
So the headline is per-ticket; the underlying mechanic is closer to per-reply with bundling that smooths the multi-turn cost a pure per-reply model imposes. The bundling is a deliberate design choice. It stops the per-reply tax that catches customers out on chatty conversations.
The full mechanic and all questions on our pricing can be found here.
The Five Tests to apply to any AI pricing model
TL;DR: Five questions to score every pricing model on: predictability, alignment, improvement tax, lock-in, and support load. The model that wins three out of five is rarely the one the vendor recommends.
Five questions. Run each model through them.
Here's the framing I'd give a buyer: the model that wins three out of five is rarely the model the vendor recommends. The two it loses on tend to be the two that matter most at scale.
Here's the matrix. We will work through each test below.
Test | The question | Per-ticket | Per-reply | Per-resolution | Per-seat |
1. Predictability | Can your CFO forecast next month's bill within ±10%? | Yes (tied to ticket volume) | Partial (multi-turn variance) | No (tied to AI quality + vendor's resolution definition) | Yes (flat) |
2. Alignment | Does the vendor only get paid when the customer gets value? | Partial: paid when the AI tries | Partial: paid per attempt | Yes, but the vendor controls what counts | No |
3. Improvement tax | When resolution rate climbs from 40% to 80%, what happens to the bill? | Stays flat | Falls slightly | Doubles | Stays flat |
4. Lock-in | What term does the vendor define unilaterally? | "Ticket" (channel-defined) | "Reply" or "interaction" (boundary-fuzzy) | "Resolution" (the biggest single lock-in) | Seat count |
5. Support load | How much vendor-side review do you need to audit the bill? | Low | Medium | High | Lowest |
Test 1: Predictability
Per-resolution bills move with two variables, neither of which the buyer fully controls. The first is AI quality (better AI raises the bill; that's Test 3). The second is the vendor's resolution definition (we'll get to that under Tests 2 and 4).
For a CFO trying to forecast a line item, two unknown variables is one too many.
Kriptomat is the cleanest named example I can give. They're a crypto exchange running customer support on Intercom, processing roughly 1,700 tickets per month, and volume swings as crypto-market activity rises and falls.
Their case-study says it plainly: they "rejected Intercom Fin at $0.99/resolution as uneconomical." Predictability was the deciding test for them, full stop.
Per-reply is partially predictable in the same sense per-ticket is. The buyer controls how many tickets and (loosely) how many turns the AI runs. But multi-turn conversations swing the bill more than a fixed-volume per-ticket model does, which is exactly why Aissist's $0.60/resolution cap exists.
Per-ticket and per-seat are both tied to inputs the buyer counts directly: tickets in the helpdesk export, agents in the HR roster. Your CFO can model spend in a spreadsheet, which we've found is the single sentence that closes the budget conversation.
The Economic Buyer your champion is selling to uses the phrase "usage shock" for the failure mode they're worried about, and predictable models don't usage-shock.
Test 2: Alignment
Per-resolution sounds aligned: the vendor only gets paid when the customer gets value. In the abstract, the marketing line is honest, and I'm happy to credit it.
The wrinkle is that the vendor defines what counts.
Fin's definition (from their pricing page) is: "Fin resolves the issue end to end, or successfully executes a Procedure you've configured to end in a handoff to a human or a workflow." Sierra counts "a resolved support conversation, a saved cancellation, an upsell, a cross-sell", outcomes the customer agrees to during the conversation. Zendesk's Autoresolve fires on a "72-hour quiet period, meaning the ticket stays closed, and the customer does not reopen the conversation."
Gorgias counts an automation as completed when the customer didn't reply. Six vendors, six definitions, all materially different (and we've watched a few of these definitions quietly shift between contract renewals).
The question isn't whether per-resolution is aligned. It's who gets to decide what aligned means.
A Reddit thread on r/B2BSaaS captures the operator-side experience about as honestly as I've seen it framed anywhere.
The OP, who tried outcome-based pricing on their own copilot product, wrote that customers loved the idea of paying for value delivered in theory. But in practice: "Budget unpredictability, lack of control over outcomes and all the complications when customers don't fully follow through on their side."
I have to be fair to per-ticket and per-reply: both charge for failures. The vendor gets paid when the AI tries, regardless of whether it succeeded. That's the genuine case against them.
Where per-resolution wins on alignment is at the abstract level. Where it tends to lose is in the definition.
Test 3: Improvement tax
This is the one most teams don't price in until it's too late. Charge per success and you charge more when the customer's bot gets better. Charge per attempt and your bill stays flat as quality climbs.
Here's the math at 10,000 tickets per month.
- 40% resolution rate: 4,000 resolved tickets.
- 80% resolution rate: 8,000 resolved tickets.
- Per-resolution bill at $1.50/resolution (Zendesk Autoresolve's published rate): 40% gives you $6,000/mo; 80% gives you $12,000/mo. The bill doubles.
- Per-ticket bill at $0.10/ticket (My AskAI's effective rate): 40% or 80%, doesn't matter, $1,000/mo flat.
- Per-reply bill at $0.09/interaction with a $0.60/resolution cap (Aissist's structure): falls slightly at 80%, because better AI tends to resolve with fewer turns.
- Per-seat bill: flat (seats don't move with AI quality).
The mechanic, in one sentence: if you charge per success, you charge more when the customer's bot gets better.
The honest version of that argument, from a chat we had this morning at My AskAI: "Outcome-based pricing charges them for the privilege of doing the work, whereas usage-based stays the same and you get the benefit. Your actual overall cost to handle a ticket goes down as your resolution increases with usage-based pricing."
The procurement-side version of that question (we will come back to it in Section 4): where will your resolution rate be on day one, and where will it realistically be in 12 to 24 months?
If the answer is "20% on day one, 60% or 70% in 18 months", the improvement tax under per-resolution is a doubling of your AI line item.
Test 4: Lock-in
Every pricing model defines a unit. The question, as I keep coming back to, is who controls the definition.
"Ticket" is channel-defined. A Zendesk ticket is a Zendesk ticket; an Intercom conversation is an Intercom conversation.
The vendor has almost no wiggle room on the count, because your helpdesk export reconciles to the bill. That's the smallest lock-in surface of the four models.
"Reply" or "interaction" is boundary-fuzzy. Aissist's definition (one automation cycle from user input to AI response, including all automation steps within that flow) includes internal automation steps the buyer can't always see directly. Whether one cycle ends and another begins depends on vendor instrumentation, so if you're auditing reply counts, you're trusting the vendor's count (this is the bit we'd want a side-by-side audit log for, frankly).
"Resolution" is the biggest single lock-in surface of the four (and the one I push back on hardest in procurement calls). Six vendors, six different definitions, all changeable by the vendor at contract renewal.
The cleanest single example: Intercom Fin renamed "resolutions" to "outcomes" in late 2025, and in the rename they added Procedure handoffs to the billable surface.
Same headline rate. New events that count. Same buyer signature (we wrote about this in the outcome-based pricing glossary when it happened).
"Seat count" is a definitional unit the buyer controls directly through HR and IT. Smallest lock-in of all.
A rule of thumb I give people: if the resolution definition in a contract has more than two clauses ("the AI resolves the issue end-to-end, OR successfully executes a Procedure handoff, OR the conversation stays closed for 72 hours, OR..."), Test 4 is failing. Multiple clauses are how vendors expand billable surface over time without renegotiating the headline rate.
Test 5: Support load
How much work do you (or your team) have to do every month to audit the invoice?
Per-resolution requires a real audit, especially under the "no-reply window" pattern that Fin, Zendesk, and Gorgias all use in slightly different forms. The "no-reply = problem solved" assumption sounds reasonable until you remember it counts the case where the customer gave up and went to a competitor.
The vendor bills. The customer churned. Catching that needs review (and we've seen support managers add a full afternoon a month for it).
Per-reply needs a quick check that the AI isn't being chatty for its own sake. Aissist's $0.60/resolution cap covers the worst case but doesn't surface the underlying signal, so you have to look at conversation length distribution to see it (we'd recommend a sample of 50 conversations per month).
Per-ticket and per-seat: your helpdesk export already reconciles. No vendor-side audit needed.
The hidden cost of Test 5 shows up as operator time more than dollars. A monthly resolution audit is a champion-level task, and if your team is already at capacity, I'd want you to factor that in.
What My AskAI does, in detail.
Chat-channel billing is per-credit, where every 2 AI replies = 1 credit (effective ~$0.10 per chat ticket). Email is first reply = 1 credit, each follow-up question = 0.5 credits (effective ~$0.15 per email ticket). The widget bills 1 credit per 1-hour session, unlimited messages.
On the matrix above, per-ticket wins Tests 1, 3, and 5; loses Test 2 (we get paid when the AI tries and fails); ties on Test 4. Three out of five is the trade we made, and Section 4 covers why we think it's the right one for most CX buyers.
What this looks like in real rollouts
TL;DR: TravelJoy lifted 24%→80% (per-resolution would have cost an extra ~$2,100/mo). Kriptomat rejected Fin at $0.99/resolution for predictability reasons (~6× difference vs per-ticket). Edel Optics jumped 25%→79% after adding the User Data API themselves (per-resolution would have captured ~$3,000/mo of their engineering work).
Three rollouts, three different starting models, three different reasons each chose what they chose.
The pattern: the model that fits depends on where your resolution rate is going more than where it sits today.
TravelJoy: when the improvement tax does the deciding
TravelJoy is an all-in-one platform for travel advisors. They run customer support on Zendesk and process roughly 2,500 to 2,700 tickets per month.
Before they switched to My AskAI, they were running Zendesk's own Advanced AI at a 24% resolution rate. Their current rate is 80%. Their Head of Customer Service, Alan Pugh, put the result this way: "You're beating Zendesk's AI agent 76% to 24% on AI deflection. Huge."
Run that through each pricing model. Zendesk Autoresolve is $1.50 per resolution, so at 80% on 2,500 tickets per month, the AI-resolved tickets alone would be $3,000 per month.
The gap from the 24% they used to get to the 80% they get now is the part Zendesk Autoresolve would have captured most aggressively. I worked it through: the 56-percentage-point lift on 2,500 tickets is about 1,400 extra resolved tickets per month, or roughly $2,100 in additional billing per month under per-resolution pricing at $1.50.
Our per-ticket pricing at $0.10 per ticket holds them around $250 to $270 per month for the same 2,500-ticket volume, regardless of resolution rate.
The lift came from connecting their website via website sync, connecting internal Notion as a knowledge source, fixing the questions the AI couldn't answer, adding custom answers continuously, writing Communication & Style and Handover guidance, and setting up AI Tagging.
All of that is customer-side work, and I want to flag it again: under outcome-based pricing, the vendor would have captured every dollar of upside from work the customer did. Under per-ticket pricing, the customer keeps it.
Kriptomat: when predictability does the deciding
Kriptomat is an EU-licensed crypto exchange running Intercom for support. They process around 1,700 tickets per month, with volume that scales with crypto-market activity.
Their case-study main-actions list states the procurement decision plainly: they "rejected Intercom Fin at $0.99/resolution as uneconomical." They currently run at 62% AI resolution rate on My AskAI.
The per-resolution counterfactual: 62% on 1,700 tickets is roughly 1,054 resolved tickets per month. At Fin's $0.99 per outcome, that's about $1,043 per month for AI-resolved tickets. On our per-ticket pricing, the same 1,700 tickets cost approximately $170 per month.
Roughly a 6x difference at this volume.
Kriptomat's case is interesting because the deciding test wasn't Test 3 (improvement tax); at 62% resolution, we're well below the ceiling.
The deciding test was Test 1 (predictability). When your monthly ticket volume swings with the price of bitcoin, a model whose bill also swings is the wrong structural fit. Different buyer, same model wins, different reason.
Edel Optics: when the customer-engineering question does the deciding
Edel Optics is a European eyewear retailer running customer support on Zendesk, processing 4,000+ tickets per month (and this one's my favorite for making the attribution argument).
The case study is explicit on the deciding move: they went from 25-30% resolution to 75-79% "overnight" after the customer added the User Data API themselves. The engineering work that drove the lift came from them rather than from the vendor.
The per-resolution counterfactual at $1.50: a 50-percentage-point lift on 4,000 tickets per month is about 2,000 extra resolved tickets, or roughly $3,000 per month in additional billing the vendor would have captured. For engineering work that Edel Optics paid for separately.
On our per-ticket pricing: no change to ticket volume, no change to bill.
The Edel Optics framing is the textbook version of why the improvement-tax mechanic reads as an attribution question rather than a vendor smear. And we think it's the right one to lead with.
The customer connects the API, writes the guidance, builds the custom answers, runs the weekly review of where the AI's struggling, and that work compounds. The vendor's contribution (model choice, RAG architecture, training pipeline) is real and smaller. Per-resolution captures the upside of both; per-ticket leaves the customer-driven upside with the customer.
To be clear: yes, TravelJoy, Kriptomat, and Edel Optics are all our customers. The pricing-model argument doesn't depend on that.
Whatever vendor you pick, pick the model where the upside of your work stays with you.
What to do this week
TL;DR: Four-step checklist (~3 hours total): pull 90-day ticket volume, project resolution rate 12 to 24 months out, get the vendor's "resolution" definition in writing, ask the per-resolution vendor for a flat-bill quote alongside the per-resolution one. The decision usually flips after Test 3.
I'd run the Five Tests against the two vendor quotes you already have. The decision usually flips after Test 3.
Here's a concrete four-step path that takes most teams under three hours total.
- Pull the last 90 days of ticket volume from your helpdesk. Roughly thirty minutes. Compute the gap between your highest and lowest months. If the gap is greater than 30%, predictability (Test 1) is the deciding test, full stop. A model whose bill also swings is the wrong fit.
- Project your resolution rate 12 to 24 months out. About an hour with the team. If you expect a 20-percentage-point or larger improvement (and you should: TravelJoy lifted 56%, Edel Optics 54%, both because the customer did the work that compounded), Test 3 dominates and per-resolution is off the table.
- Get the vendor's "resolution" definition in writing. Thirty minutes per vendor. Find it in the pricing FAQ or contract addendum (rather than the marketing landing page) and I cannot stress this enough. If the definition has more than two clauses, Test 4 is failing. The cleanest version of the question to ask is: "What will the resolution rate look like on day one, and how much will it realistically change over time?" The vendor's answer to the second half tells you what they expect your improvement tax to cost.
- Ask the per-resolution vendor for a flat-bill quote at your current volume. One email. Most per-resolution vendors will quote a flat alternative for a 12-month contract, and we've seen the gap between their per-resolution headline rate and the flat alternative tell you what they think your resolution rate is going to do. If the flat quote is materially higher than the per-resolution math at your current rate, they're expecting growth, so price it in.
If you want to see what per-ticket looks like priced against your specific volume, our pricing page has a calculator that takes the same inputs.
When the other models actually win
TL;DR: Per-resolution wins for low-volume pilots and bounded-resolution industries (medical, legal, fintech). Per-reply wins for narrow single-channel bots that resolve in one or two turns. Per-seat wins when the AI is genuinely a copilot rather than an autonomous resolver.
Per-ticket isn't the right answer for every buyer. Here's where each of the other three models is the honest call.
Per-resolution wins for low-volume pilots and bounded-resolution industries.
If you're under roughly 1,000 tickets per month running a one-vendor pilot, the improvement tax never reaches a number that matters. Per-resolution feels aligned and the vendor wears the risk of bad performance.
The honest steelman, from one of our recent founder POVs: "If, on day one, you're already getting 80% resolution and you're comfortable with the overall cost, then your costs aren't going to rise significantly as resolution increases, because there's a limit to how far it can go." That's the legitimate edge: buyers already near the ceiling.
The same logic applies to medical, legal, and fintech use cases where compliance caps resolution rates well below the 70-80% bands a general CX team aims for (this is the carve-out I most often have to talk people into). Sierra acknowledges this directly in their own writing on outcome-based pricing: outcome-based "isn't universally applicable" and they offer consumption-priced blends for routing or greeter-style interactions. The honest carve-out.
Per-reply wins for narrow, single-channel bots that almost always resolve in one or two turns.
Order-status lookups. Password resets. Single-question FAQ bots.
That's the class of use case where multi-turn conversations are an anti-pattern. If your AI fundamentally shouldn't be having long conversations, per-reply is honest pricing (and I've genuinely told buyers to go with it).
My own take on this, from the same chat: "Per-reply pricing isn't a bad model, especially when combined with a per-resolution cap, because you're only paying for what's used. In our experience, conversations aren't actually that long, especially since AI can provide succinct answers for users." The break point is the opposite shape: consumer-facing products with heavy back-and-forth, or long automation flows that fire many AI replies per ticket.
Aissist's $0.09 + $0.60-cap structure is the best public example of someone trying to make per-reply work for general support.
Per-seat wins when the AI is genuinely a copilot rather than an autonomous resolver.
Heritage teams where a human is still on every ticket and the AI is drafting, summarizing, or suggesting.
Freshdesk Freddy Copilot at $35 per agent per month is fair value at this read. The model only goes wrong when the team is trying to scale resolution beyond headcount, at which point per-seat caps your AI capacity at your seat count (which is exactly the opposite of what most CX teams want from AI).
There's one model nobody should be paying for in 2026 customer service: pure subscription tiers with no usage metric whatsoever. The Crunch's "AI Agents Price 2026" guide recommends this approach to avoid "spike overruns", but the result is paying a fixed amount whether the AI handles 100 tickets or 100,000.
Usage-tied pricing (per-ticket, per-reply, or per-resolution) is the floor of honesty.
The takeaway
TL;DR: Pricing models reflect a vendor's strategy for which buyer they want to win. Pick the model that doesn't punish you for getting better. For most teams with a climbing resolution rate, that's per-ticket.
The Five Tests give you a defensible answer in 30 minutes. A pricing model reflects a vendor's strategy for which buyer they want to win, more than any deeper moral question.
Your job is to pick the model that doesn't punish you for getting better.
The biggest test, in our view, is Test 3: the improvement tax. If your resolution rate is going to climb (and for most teams it will, because most of the climb comes from work the team does, more than from any magic the vendor does), then a model that doubles the bill when the rate doubles is the opposite of aligned.
It's a model that captures the upside of your work.
If you want the theory layer above this post, the outcome-based pricing glossary covers the underlying argument in more depth. If you want the worked example of what per-ticket pricing (the boring-but-effective option) looks like in practice, the My AskAI pricing explained post walks through the credit math at our typical volume tiers.
And if you want to put your own numbers against it, our pricing calculator is the fastest way.
Pros and Cons summary
TL;DR: One-line verdicts on when each model wins and when it fails, as the "save this for later" reference table.
Each of the four models has a profile. Here's the one-line read on when each wins and when each fails.
Per-ticket.
Wins for teams scaling resolution where the bill has to be forecastable and long-horizon planning matters. Most vendors that pitch "per-conversation" actually mean per-ticket, so accept it as a synonym but pin them on the exact ticket definition in writing. It fails when the vendor can't (or won't) define a "conversation" precisely, and for one-off pilots where you want zero-cost failures.
Per-reply.
Wins for narrow channel-specific bots where the AI usually resolves in one or two turns. It fails for anything multi-turn or open-ended: natural conversations spike the bill in ways the vendor demo never shows.
Per-resolution.
Wins for low-volume pilots, AI-insurance buyers, and bounded-resolution industries where the resolution ceiling is genuinely low. It fails for high-growth resolution curves, fluctuating volume, and any case where you're paying the vendor for your own knowledge or API work.
Per-seat.
Wins for heritage human-heavy teams adding AI as a copilot to existing agents (not as autonomous resolution). It fails when you want AI to expand capacity beyond seat count.
FAQs
What's the difference between per-ticket, per-reply, per-resolution, and per-seat AI pricing?
Per-ticket charges a flat amount each time the AI engages with a helpdesk ticket, typically around $0.10. Per-reply charges per individual AI message (Aissist is the cleanest example at $0.09 per interaction, capped at $0.60 per resolution).
Per-resolution charges only when the AI succeeds: Fin at $0.99, Zendesk Autoresolve at $1.50, Sierra and Decagon non-public. Per-seat charges per human agent who uses the AI as a copilot: Freshdesk Freddy Copilot at $35 per agent per month, Zendesk's Advanced AI at $50.
All four are sold as "what AI agents cost". They are not the same model.
Which AI agent pricing model is cheapest at scale?
Per-ticket is cheapest at scale for teams whose resolution rate is climbing, which is most teams. At 10,000 tickets per month with 75% resolution, My AskAI Scale runs around $1,299 per month vs Intercom Fin at $7,425 (5.7x), Zendesk AI at $11,250 (8.7x), and Gorgias Automate at $6,750 (5.2x).
From a founder POV we captured this week: "Your equivalent cost per resolution actually falls over time" with usage-based pricing, while per-resolution rises with quality. The qualifier matters: per-ticket wins specifically because Test 3 (improvement tax) penalizes per-resolution as resolution rate climbs.
How is a "resolution" defined by AI vendors like Intercom Fin, Decagon, and Sierra?
Fin defines a resolution (renamed "outcome" in late 2025) as "Fin resolves the issue end to end, or successfully executes a Procedure you've configured to end in a handoff to a human or a workflow." Sierra counts "a resolved support conversation, a saved cancellation, an upsell, a cross-sell", outcomes the customer explicitly agrees to. Decagon uses a deliberate "AI resolved" tag set when the AI's answer ends the loop (their criteria are non-public).
Zendesk Autoresolve uses a 72-hour quiet period: the charge fires only when the ticket stays closed for 72 hours. Six vendors, six definitions, all changeable by the vendor at contract renewal. Always ask for the definition in writing.
Is per-resolution pricing the same as outcome-based pricing?
Not quite. Per-resolution is one flavor of outcome-based pricing.
Outcome-based also includes per-deflection, per-recovered-refund (Chargeflow's 25% model), per-fraud-prevention (Riskified's 0.4%), per-agreed-business-outcome (Sierra), and per-closed-deal (sales AI). Per-resolution is the dominant outcome-based flavor in AI customer service. For the full taxonomy, see our outcome-based pricing glossary.
Does per-resolution pricing make my AI bill go up when the AI gets better?
Yes. At 10,000 tickets per month, a per-resolution bill at Zendesk Autoresolve's published $1.50 per resolution goes from $6,000 per month at 40% resolution to $12,000 per month at 80% resolution. The bill doubles when the resolution rate doubles.
A per-ticket bill at $0.10 stays flat at $1,000 per month across the same range. Most of what causes the resolution rate to climb is customer-side work (knowledge updates, API connections, guidance tuning, weekly review of where the AI struggled), so under per-resolution pricing, you're paying the vendor for upside the team engineered.
Is "per-conversation" pricing the same as per-ticket pricing?
Usually, but not always. Some vendors use "per-conversation" as a synonym for per-ticket: one billable unit per discrete helpdesk ticket. Other vendors use it to mean a back-and-forth thread within a single ticket, or a 24-hour session, or a per-channel-engagement count.
The ambiguity is real, and it's worth pinning down in the contract. Always ask for the exact definition in writing before you sign. "Per-conversation" without a specific definition is a Test 4 (lock-in) failure waiting to happen.
What pricing model does My AskAI use, and why?
We use a per-ticket effective model with per-credit underlying mechanics.
Helpdesk chat: every 2 AI replies = 1 credit (effective ~$0.10 per chat ticket). Helpdesk email: first reply = 1 credit, follow-up questions = 0.5 credits each (effective ~$0.15 per email ticket). Widget: 1 credit per 1-hour session, unlimited messages.
The reason for the bundling is the per-reply tax: pure per-reply pricing punishes multi-turn customer conversations, and the bundling smooths that out. On the Five Tests above, per-ticket wins Tests 1 (predictability), 3 (improvement tax), and 5 (support load); loses Test 2 (alignment, since we get paid when the AI tries, regardless of success); ties on Test 4 (lock-in).
Three out of five is the trade we made. The full mechanic is documented in our pricing explainer.
