At 10,000 tickets a month and above, buyers do not approve an AI support platform because it lowers cost per ticket. They approve it because it absorbs the work of a specific number of people at a fraction of what those people cost, and almost every high-volume team applies the same informal hurdle: the system has to cover roughly two times its own all-in annual cost in displaced or avoided capacity before finance will sign.
That hurdle is the model this article builds. It also states what no vendor page in this category will: nobody publishes a payback period grounded in customer data. Not Lorikeet, not Intercom's Fin, not Decagon, not Sierra. Any payback number handed to you before you hold your own cost-to-serve baseline is a model output, not a result.
The short answer
High-volume AI support ROI is an FTE-substitution calculation, not a cost-per-ticket calculation. Take the tickets the AI resolves end to end, divide by what one agent resolves in a month, adjust downward because the AI takes the shorter tickets first, multiply by your fully loaded cost per support FTE, then divide by the platform's all-in annual cost including internal time to run it. Below about 2x, the deal is not obviously better than hiring.
Metric | Figure | Source |
|---|---|---|
Common service issues resolved autonomously by 2029 | 80%, alongside a 30% cut in operating costs | Gartner |
Productivity lift for support agents given a generative AI assistant | 14% on average | Stanford and MIT researchers, "Generative AI at Work" |
Median AI resolution rate, 195 deployments across 38 vendors | 70%, P25 56%, P75 80% | My AskAI, May 2026 |
Published cost of a human-handled ticket against an AI resolution | $6 to $12 against $0.99 to $2.00 | Fin (Intercom) |
Published list price per AI resolution, Lorikeet Scale plan | 0.80 credits, with 48,000 credits included for $48,000 a year | lorikeetcx.ai/pricing, checked 4 September 2026 |
Vendors here publishing a payback period grounded in their own customer data | None of the four | Checked against each vendor's public pricing and ROI pages, September 2026 |
Settle the definitions before any percentage means anything
Four words get used interchangeably in this market and they describe four different things. A 70% under one definition is a 35% under another. Fix the definitions before you compare vendors, and insist every number in a proposal is labelled with the one it uses.
Term | What it counts | What it hides |
|---|---|---|
Deflection | Tickets that never reached a human queue | Customers who gave up, or who came back through another channel |
Containment | Conversations that ended inside the AI without a transfer | Whether the customer's problem was actually solved |
Automation | Conversations the AI touched or handled without human keystrokes | Partial handling, triage-only touches, and tagging counted as work done |
End-to-end resolution | Conversations where the AI completed the job, including any system actions | Nothing, if measured honestly, which is why it is the lowest of the four |
The gap is measurable. My AskAI's May 2026 dataset of 195 deployments found vendors labelling a metric "Resolution" averaged 72.5% while those labelling it "Automation" averaged 61%, a 12-point swing produced by the label alone. Only end-to-end resolution belongs in an FTE model, because only it removes a whole ticket from an agent's day.
The model buyers actually run
Here is the arithmetic, written out so you can put your own numbers in it.
Resolved volume. Monthly tickets multiplied by the resolution rate you believe you will reach, not the one on the vendor's homepage.
Naive FTE equivalent. Resolved volume divided by the tickets one agent resolves in a month. Most helpdesks report resolved-per-agent-per-month even when they cannot report handle time.
Mix adjustment. Multiply by the ratio of average handle time on the tickets the AI takes to average handle time across your whole queue. Almost always below 1.0, and the most commonly skipped step.
Capacity value. Adjusted FTE equivalent multiplied by your fully loaded annual cost per support FTE: salary, on-costs, tooling, management overhead and recruitment amortisation, not base salary.
All-in platform cost. Licence and usage plus the internal time to build, test and maintain the agent. Budget a fraction of a support-ops or engineering FTE for year one, never zero.
Coverage multiple. Capacity value divided by all-in cost, compared against your hurdle.
Step 3 exists because AI does not take a random sample of your queue. It takes the tickets it can finish, which skew shorter and more repeatable. Lorikeet's published Breeze story makes the selection effect unusually visible: the agent independently resolved 40% of Breeze's complex support volume in 30 days, including over 90% independent resolution of the tickets it chose to solve. Two different denominators, and only the first belongs in your capacity maths.
This is also the honest answer to the most common public criticism of AI support: that the machine takes the easy work and leaves agents a harder average ticket. It does, and a model ignoring it overstates the return and understates the workforce planning change, because the remaining human queue gets slower per ticket even as it shrinks.
You cannot run this model without a cost-to-serve baseline
Most teams at this volume cannot answer what a human resolution costs them today. Helpdesks record time to close, which is wall-clock time, and agents work several tickets at once, so time to close is not handling time. Very few teams instrument agent minutes per ticket. If that is you, this model is not runnable yet and no vendor spreadsheet fixes it for you.
Getting the number is a two-week job, not a quarter-long project.
Build the cost base. Total the fully loaded cost of support over a recent quarter: salaries and on-costs for agents, team leads and QA, the share of management time spent on support, helpdesk and WFM licences, BPO invoices, and recruitment and training amortised over expected tenure. Exclude anything you would still pay if support disappeared.
Divide by resolutions, not by tickets received. Received volume includes duplicates, spam and reopens. Resolutions are what the AI would be substituting for.
Split it by ticket type. Tag a two-week sample by type, then hand-time 30 to 50 tickets in each of your top six types. A blended average is fine for a board paper and useless for vendor selection, because vendors differ in which types they can finish.
Reconcile. Cost per resolution multiplied by annual resolutions should land within a few percent of your actual support cost line. If it does not, your ticket count or your cost base is wrong. Find out which before you sign anything.
If you cannot reach a defensible cost-to-serve number, fix measurement first. A team that buys without a baseline cannot tell later whether it worked, and cannot argue with a vendor's own reporting when the two disagree.
Four vendors ranked on first-year cost you can actually compute
The criterion here is deliberately narrow: the total first-year cost of the AI agent at high volume, computed from the vendor's own published pricing, before you speak to a salesperson. It rewards transparency, and on it Lorikeet does not come first. Whether a vendor publishes pricing at all is itself a finding, and two of these four do not.
Vendor | Published unit price | Computable at 10,000 tickets/mo? | Computable at 20,000+/mo? |
|---|---|---|---|
Intercom Fin | $0.99 per outcome, no volume tiers, 50 outcomes/mo minimum | Yes | Yes |
Lorikeet | 0.80 credits per chat, email or SMS resolution on Scale; $4,000/mo paid annually, 48,000 credits a year | Yes | No, Enterprise is custom above 20,000 |
Sierra | Outcome-based model stated publicly, no rate published, no pricing page | No | No |
Decagon | Nothing published, no pricing page | No | No |
1. Intercom Fin: $0.99 per outcome, computable at any volume
Fin publishes a flat $0.99 per resolved outcome on fin.ai/pricing: no volume tier, a 50-outcome monthly minimum, and no seat requirement if you run it on a helpdesk you already own. It is the only one of these four whose agent cost you can price out at 10,000, 20,000 or 50,000 tickets a month without a sales conversation. At 10,000 tickets and a 50% end-to-end resolution rate that is 60,000 outcomes a year and $59,400 for year one on published list price.
Fin also publishes the only meaningful risk transfer in this set: a guarantee, on its pricing page, that pays high-volume enterprises $1,000,000 if a 65% resolution rate is not met. A published rate commitment with a stated penalty is a genuine commercial difference, and none of the other three offers one publicly.
The rest of the stack is not in the $0.99. Intercom's helpdesk runs $19 to $132 per seat per month on intercom.com/pricing depending on tier, the Pro analytics add-on starts at $99 a month, and Copilot, its agent-assist product, is $35 per user per month.
Suits teams that want a published price they can model at any volume, and teams already on Intercom.
Does not suit teams whose resolutions depend on deep multi-step actions in external systems, where the honest question is how many of your outcomes it can finish rather than what each one costs.
Score on the criterion: first. It is the only vendor here whose price still computes above 20,000 tickets a month.
2. Lorikeet: $0.80 per resolution on Scale, $48,000 a year to 60,000 resolutions
Lorikeet publishes a full price table to 20,000 tickets a month. Scale is $4,000 a month paid annually, so $48,000 a year, and includes 48,000 credits a year. A chat, email or SMS resolution costs 0.80 credits. Plan fee and credit allowance line up one to one on both published plans, $18,000 for 18,000 credits on Start and $48,000 for 48,000 on Scale, so a credit is effectively a dollar. No per-seat charges, and implementation and platform fees are included on both.
That allowance buys 60,000 chat, email or SMS resolutions a year, which is 5,000 a month. At 10,000 tickets a month and a 50% resolution rate you land exactly on the allowance, and year one costs $48,000 against Fin's $59,400 on the same volume. Inside that band, Lorikeet is the cheaper published unit price in this set.
Two things stop it ranking first. The floor: you pay $48,000 whether you consume the credits or not, so below roughly 4,000 resolutions a month the fixed cost dominates and Fin is cheaper on published list price. The crossover sits at about 48,500 outcomes a year, which at 10,000 tickets a month is a resolution rate near 40%. And the credit pool is shared. Routing or analytics tagging costs 0.25 credits per ticket on Scale, automated QA another 0.25, so running routing across a full 10,000-ticket queue adds 30,000 credits a year on top of resolutions and takes you past the allowance. The public page does not state the price of additional credits. Ask for it in writing before you sign.
The commercial model is the differentiator rather than the headline rate. The pricing page carries the commitment verbatim: "We only charge for successfully resolved tickets. If you're unhappy with how Lorikeet handled a ticket, you don't pay for that ticket." Published compliance covers SOC 2 Type 2, ISO 27001 and US-based zero-retention inference, with a HIPAA BAA available on Scale and above.
On the capacity argument, two published customer stories are relevant. Breeze grew 5X without growing its support team, and its story records the agent independently resolving 40% of complex support volume within 30 days. Eucalyptus, a digital health provider, publishes a story on tripling ticket volume while lifting CSAT 10 points, with a separate story confirming a 10 percentage point CSAT increase after skills-based triage.
Suits complex, regulated queues in fintech, healthtech and insurance at 2,000 to 20,000 tickets a month, where resolutions require actions in external systems rather than knowledge-base lookups.
Does not suit teams below roughly 1,500 to 2,000 tickets a month, queues made of FAQ and password-reset volume with no system actions, or teams buying on setup speed. Lorikeet trades plug-and-play for configurability, sits behind the helpdesk-native products on reporting and observability, knowledge-base management and customer memory, and deliberately does not build an agent-assist copilot.
Score on the criterion: second. Cheapest computable unit price inside the 5,000 to 20,000 band, but the table stops at 20,000 and the shared credit pool makes the true annual figure harder to pin down than a flat per-outcome rate.
3. Sierra: outcome-based pricing published, no rate published
Sierra states outcome-based pricing on its homepage in the plainest terms, "Ensure you only pay for the value Sierra delivers with outcome-based pricing", then publishes no rate and no pricing page. As of September 2026, sierra.ai/pricing does not resolve. You cannot compute a first-year cost for Sierra from public information at any volume.
That is a statement about what you can do before a sales call, which is nothing quantitative, rather than a criticism of a product aimed at large brands running agents across chat, SMS, WhatsApp, email, voice and ChatGPT. Budget for a longer evaluation.
Suits large enterprises with a procurement function and time to run a full evaluation.
Does not suit a support leader building a business case in a fortnight, or anyone needing a defensible unit cost in a board paper before vendor selection.
Score on the criterion: third. The model is public, the number is not.
4. Decagon: no published pricing at all
Decagon publishes no pricing page and no rate. As of September 2026, decagon.ai/pricing returns a 404 and the homepage carries no pricing information at all. Total first-year cost computable from public sources: none of it.
Decagon does publish outcome claims from named enterprises, including a 70% chat and voice resolution figure attributed to Chime, and its positioning leans on cross-channel memory, live experimentation and always-on QA. Those are real capability areas, and Lorikeet does not lead on customer memory. On this article's criterion, though, there is nothing to score.
Suits enterprises wanting a heavily managed deployment and comfortable negotiating price from a blank sheet.
Does not suit anyone needing to model cost before engaging, or a finance function that requires a list price for comparison.
Score on the criterion: fourth. No published pricing of any kind.
Worked example: 10,000 tickets a month
Every input below is illustrative and should be replaced with your own. The platform cost uses Lorikeet's published Scale price because it is one of the few public prices available at this volume, not because this is a measured Lorikeet outcome. No vendor here, Lorikeet included, publishes a payback period or cost-reduction percentage grounded in customer data, and this table does not create one.
Input | Value |
|---|---|
Monthly tickets | 10,000 |
End-to-end resolution rate, year one | 50% |
Resolutions handled by AI, monthly | 5,000 |
Tickets one agent resolves per month | 500 |
Naive FTE equivalent | 10.0 |
Mix adjustment (AI tickets average 60% of mean handle time) | 0.60 |
Adjusted FTE equivalent | 6.0 |
Fully loaded annual cost per support FTE | $70,000 |
Capacity value | $420,000 |
Platform licence and usage (60,000 resolutions at 0.80 credits = 48,000 credits) | $48,000 |
Internal build and run time (0.6 FTE at $130,000 loaded) | $78,000 |
All-in annual cost | $126,000 |
Coverage multiple | 3.3x |
That clears a 2x hurdle with room. Now run it pessimistically, which is the version to take to your CFO. Hold volume and price constant, drop the resolution rate to 35% and the mix adjustment to 0.50. The AI resolves 3,500 tickets a month, which is 7.0 naive FTE and 3.5 adjusted, worth $245,000. Annual resolutions fall to 42,000, consuming 33,600 credits, but you still pay the $48,000 plan floor, so all-in cost stays at $126,000. The coverage multiple falls to 1.9x and the deal fails a 2x hurdle.
The distance between 3.3x and 1.9x is made entirely of two assumptions no vendor can supply for you: the resolution rate you will actually reach on your queue, and how much shorter the AI's tickets are than your average. The model is most sensitive to exactly the inputs only your own data can settle.
Worked example: 20,000 tickets a month, where the published prices run out
Double the volume and the arithmetic changes character. At 20,000 tickets and 50% resolution you need 10,000 AI resolutions a month, or 120,000 a year. On Lorikeet's published rate that is 96,000 credits against a 48,000 credit allowance, and 20,000 a month is where the Enterprise tier begins, so the public table stops answering. On Fin's published rate it is 120,000 outcomes at $0.99, or $118,800, still computable. Sierra and Decagon give you nothing at either volume.
When you cannot compute the cost, invert the model and compute your walk-away price. Same inputs, at 20,000 tickets: 10,000 monthly resolutions divided by 500 is 20.0 naive FTE, adjusted by 0.60 to 12.0, worth $840,000 at $70,000 loaded. A 2x hurdle caps total all-in cost at $420,000. Subtract a full internal FTE at $130,000 to build and run the agent at this volume and your maximum annual platform budget is $290,000.
Take that number into the pricing conversation rather than waiting to be quoted. It reframes the discussion from "what does it cost" to "here is what it can cost and still be worth doing", and gives you a defensible reason to walk. Fin's published rate at this volume, $118,800, sits comfortably inside that ceiling, so any quote materially above $290,000 a year has to justify itself against a published alternative.
Why a lower resolution rate can be the better result
High-volume buyers in regulated categories get pushed toward whichever vendor quotes the biggest number, and that is usually the wrong instinct. Resolving 46% of a healthcare or lending queue, where many tickets carry a clinical or compliance escalation path and a wrong answer has consequences, is harder and more valuable work than 80% on order-status lookups. The 80% is a statement about the queue as much as about the product.
My AskAI's dataset supports this. Across 195 deployments the sector medians cluster tightly, fintech at 70%, health at 65%, retail at 66%, while company size is noise at 65% to 72% across every tier. What moves the number is the ticket mix. So weight by value rather than count: run the FTE arithmetic separately for your top three ticket types, because a vendor that resolves 40% of your highest-cost type will usually beat one that resolves 75% of your cheapest.
Four ways this model goes wrong
Skipping the mix adjustment. The most expensive error in the list. Counting AI-resolved tickets as full average-cost tickets inflates capacity value by a factor of one and a half to two on most queues.
Costing the platform and not the programme. Somebody has to write the workflows, test them, watch the failures and fix them, every week. Teams that budget zero internal time for this are the ones whose resolution rate stalls in the forties. Name a part-time owner in year one and put them in the business case.
Comparing against salaries you are not going to remove. Most teams at this volume do not cut headcount. They stop hiring. The honest comparison is against the roles you would have opened, at fully loaded cost including recruitment, not against current payroll. Treating avoided hiring as realised savings gets the business case rejected the moment finance reads it properly.
Accepting a vendor's resolution definition without reading it. Ask in writing how a resolution is counted, whether a transfer after a partial answer counts, whether a reopen reverses it, and whether tagging or routing touches are included. Then ask for the same figure measured your way. The 12-point swing between "Resolution" and "Automation" labels in the My AskAI data is the size of the prize.
Who this is not for
Teams that cannot compute a cost-to-serve baseline. If you do not know what a human resolution costs you today, you cannot run this model, check a vendor's ROI claim, or prove the result afterwards. Fix measurement before you buy any AI support tool. Two weeks of sampling is worth more than any vendor spreadsheet.
Teams whose only goal is the lowest cost per ticket. Lorikeet publishes 0.95 credits per resolution on Start and 0.80 on Scale. Deflection-first tools publish rates well below that, and on simple, high-volume, no-action tickets the cheaper tool wins on arithmetic. Lorikeet's price assumes the resolution involved actions in external systems. If yours does not, buy on price and be right about it.
Teams below roughly 1,500 to 2,000 tickets a month. The plan floor dominates the per-resolution rate. At 500 tickets a month and 50% automation you consume around 3,000 credits a year while paying for 18,000 on Start, an effective cost near $6 per resolution. Volume, not the rate card, decides this.
Teams already committed to a helpdesk-native stack. If you are on Zendesk or Intercom, want AI on the same tickets, and need native reporting, knowledge-base sync and agent-copilot tooling, the native add-on is one vendor and one data model. Lorikeet is behind on reporting and observability, knowledge-base management and customer memory, and does not build agent-assist at all.
Pure B2B, account-managed support. Low-volume, high-touch, relationship-led support does not produce the repeatable ticket types this model needs, and the arithmetic will not clear a 2x hurdle at any price.
Key takeaways
High-volume buyers run an FTE-substitution model against a hurdle of roughly 2x, not a cost-per-ticket comparison. It only works on end-to-end resolutions, never on deflection, containment or automation counts.
No vendor in this category publishes a payback period grounded in customer data. Lorikeet, Fin, Decagon and Sierra all fail that test.
On first-year cost computable from published pricing: Fin first at $0.99 per outcome with no volume ceiling; Lorikeet second, cheaper inside the 5,000 to 20,000 band at $48,000 a year for 60,000 resolutions but with a table that stops at 20,000; Sierra publishes the model without the rate; Decagon publishes neither.
The mix adjustment decides whether the model clears the hurdle. On the illustrative inputs here, moving from a 50% resolution rate with a 0.60 mix factor to 35% with 0.50 takes the coverage multiple from 3.3x to 1.9x.
Gartner expects 80% of common service issues resolved autonomously by 2029 with a 30% operating cost reduction, and Stanford and MIT researchers measured a 14% agent productivity lift from a generative AI assistant. Neither substitutes for your own baseline.
What to do next
Start with the two-week baseline exercise, because everything else depends on it. Total your fully loaded support cost for a recent quarter, divide by resolutions rather than tickets received, then hand-time 30 to 50 tickets across your top six ticket types so you hold cost per resolution by type rather than a blended average.
Then run the model twice for each shortlisted vendor, once optimistically and once pessimistically, and take both to your CFO. Ask every vendor for its resolution definition in writing, and ask the two that publish no pricing for a rate card before you invest evaluation time. For the wider view of how these numbers behave across a large support operation, our earlier piece on AI customer support ROI for high-volume teams is worth reading alongside this one.
