AI Customer Support Automation Tools: What One Answer Costs

Every vendor in this market publishes a number. Most publish two. None publish the one a buyer actually needs. The published number is a per-agent or per-seat licence, or a per-conversation outcome fee, or both. The number a buyer needs is the cost of an automated answer once the sales claim has been stripped out of the calculation and replaced with the buyer's own ticket mix.

This page works through five tools, prints the prices they publish, then does the arithmetic that their sales pages never do: what one resolved conversation costs on each meter, at a stated volume, before and after the assumption the whole industry quietly makes is cut in half.

What the vendors publish

All five tools sell automation on top of a help desk. They meter it differently, which is the whole point of this article. Two charge per agent seat and bolt the AI on as an add-on. Two charge per seat and meter the AI on resolved conversations. One charges per ticket and meters the AI on the same ticket.

The Asyntai row is ours. Every other row is taken from the vendor's own pricing page on the date shown in the sources block. None of these prices include the implementation cost, the conversation design cost, or the time it takes to keep the answers current.

The Gorgias row is the one that makes buyers stop and re-read it. Gorgias bills the desk on ticket volume, and it bills the AI Agent on resolved conversations, and it counts an automated resolution as one of the tickets in your tier. The automation spends your allowance while saving you a response. This is not a flaw to flag. It is the meter, and it changes what one automated answer costs.

Why the published prices do not answer the buyer's question

The vendor pages answer a different question. They tell you what the tool costs when it is doing nothing. They do not tell you what the automation costs when it is doing the thing you bought it for.

To work that out you need three inputs, and only one of them is on the price page.

1. The per-event price, which the page does publish.
2. Your monthly ticket volume, which you know.
3. The share of those tickets that are genuinely repeatable, which is the number nobody publishes and which is the assumption the entire industry rests on.

The first two are arithmetic. The third is judgement, and it is where every automation case study quietly overstates the result.

The assumption everything rests on

Vendor case studies tend to lead with a percentage. Forty percent of tickets automated. Sixty percent. Sometimes seventy. The number is real, but it is the share of tickets that were closed by an automated answer in the trial, not the share that would have been closed in your queue.

Two reasons those numbers are optimistic.

The first is selection. The vendor case study usually starts with a subset of tickets that look answerable, runs the bot against that subset, and reports the resolution rate on the slice it chose. The unread messages, the angry messages, the messages with attachments that need a human eye, get filtered out before the percentage is calculated.

The second is freshness. A bot trained on the last six months of tickets works well on the next three. By month nine the catalogue has changed, the returns policy has changed, the shipping carrier has changed, and the resolution rate has dropped. The case study is a snapshot, not a steady state.

The number to use is your own: the share of tickets in the last 90 days that are about a question with a written answer that does not change often. Order status, password reset, return window, opening hours, delivery area, sizing chart. Anything that needs a judgement, a refund, a complaint escalation, or a real conversation does not belong in this number.

Working out what one automated answer costs

Pick a stated volume and a stated repeatability, then run the same calculation against each meter. The number a buyer needs is the cost per resolved conversation after the seat cost and the per-event cost are combined.

Take a team of 5 agents handling 2,000 tickets a month, of which you estimate 40% are genuinely repeatable. That is 800 conversations a month that an automated agent could resolve. You want to know what each of those 800 resolutions costs, on each meter, before signing anything.

Now run each meter against those 800 resolutions.

Zendesk: per-agent plus Copilot

Zendesk's Suite Professional tier is $115 per agent per month billed yearly. Copilot is $50 per agent per month on top. For a 5-agent team on the middle tier:

The number does not depend on whether Copilot actually automated anything. The seat spend is the seat spend, automation or not. The $1.03 is the floor.

Freshdesk: per-agent plus Freddy AI Agent

Freshdesk Pro is $55 per agent per month. Freddy AI Copilot is $29 per agent per month. The AI Agent itself is metered separately: 500 sessions included, then $0.49 per session.

Freshdesk comes out cheaper than Zendesk on this volume because the AI Agent is metered on sessions, and the seat cost is lower. The 500-session allowance is what makes the difference; a team handling 1,500 automated resolutions a month would tip the other way.

Intercom: per-seat plus Fin AI

Intercom Advanced is $85 per seat per month. Fin AI is $0.99 per resolved conversation, charged once per conversation regardless of how many messages it takes.

Intercom's number is the cleanest to read because Fin is a pure per-outcome meter. The seat cost is small relative to the usage cost at this volume. At low volume the same calculation gets worse fast: the seat cost stays put and the denominator shrinks, so the per-resolution number rises sharply. The meter punishes low volume.

Front: per-seat plus Autopilot

Front Scale is $105 per seat per month. Autopilot starts at $0.05 per conversation. Use $0.05 as the floor for the worked example, which is the published number.

The Front number is the most misleading on this page, because $0.05 is the published floor and the real per-conversation price at 800 conversations depends on Autopilot's tiered usage rate, which is not in the published figures. Treat the $0.71 as the optimistic floor and assume it rises once you cross the floor's threshold.

Gorgias: per-ticket plus AI Agent

Gorgias bills the desk on ticket volume. AI Agent is $0.90 to $1.00 per resolved conversation. An automated resolution also counts as a billable ticket, so the automation spends the ticket allowance.

Gorgias is the most expensive meter for automation at this volume, because every automated resolution is billed twice: once as a ticket, once as an AI outcome. The trade is that Gorgias removes seats entirely, so a 5-agent team is paying for tickets they would otherwise be paying for in seats. The arithmetic only makes sense if your seat cost is high.

Asyntai: per-message, automation included

Asyntai Starter is $39 per month for 800 messages, Standard is $139 for 15,000, Pro is $449 for 50,000. The plan includes the AI agent. At 800 automated resolutions a month, assume an average of 4 messages per conversation, which is your own input.

The number scales with the plan. The same volume on Starter is over the 2,500 allowance; on Pro it is well inside the 50,000 allowance. The plan tier is the only knob.

Comparing the five meters at the same volume

The Asyntai row is ours. The other rows are calculated from the published prices against the same stated inputs: 5 seats, 2,000 monthly tickets, 40% repeatable share, 800 automated resolutions, 4 messages per conversation. Change any input and every row changes. The Gorgias row uses the midpoint of the published $0.90 to $1.00 range. The Front row uses the published $0.05 floor and is therefore optimistic.

What happens when the repeatable share is half what the case study claimed

The 40% figure was generous. A more honest figure, after the vendor's selected subset and the freshness decay are stripped out, is 20%. Re-run the same five meters against half the automated volume.

The seat cost does not move. It was never going to move. Only the per-event line moves.

Zendesk at 400 resolutions

Freshdesk at 400 resolutions

Intercom at 400 resolutions

Front at 400 resolutions

Gorgias at 400 resolutions

Asyntai at 400 resolutions

What the halving tells you

Every meter roughly doubled the per-resolution cost when the volume halved, except the Gorgias meter, which rose by less because the Gorgias seat cost is the ticket allowance and the allowance does not shrink with volume. Gorgias is the most expensive at full volume and the second most expensive at half volume. Intercom and Zendesk sit close together at the top across both volumes.

Freshdesk's $0.49 per-session meter is the most volume-sensitive on the way up, because it is a per-event line with no floor. It is the least volume-sensitive on the way down, because the 500-session allowance absorbs the loss.

The per-message plan moves in the opposite direction to the per-seat tools: when the volume halves, the plan moves down a tier and the per-resolution cost falls. This is unusual in this market, where every other meter is built around seats that do not shrink.

The mistake most buyers make

The mistake is to read the published price as the cost. It is not. The published price is the cost when the assumption the vendor makes about your queue is correct. The published price is also the cost when the automation does the work, not the cost of the automation itself.

Three things follow.

First, your own repeatable share is the number that decides the meter. If your queue is 20% repeatable, the per-event meters will punish you. If your queue is 60% repeatable, they will reward you. The vendor will not tell you which one you have. You have to count the tickets.

Second, the seat cost does not move with the automation. A 5-agent team pays for 5 seats whether the bot resolves 0 or 800 conversations. The seat cost is the floor, and it is the floor on every per-event meter.

Third, the per-event meter can be the cheaper line, but only at the volume the vendor's case study assumes. The buyer who assumes 800 resolutions and gets 400 is paying twice the per-event rate on every conversation, and the seat cost is unchanged.

What to measure before signing

Three numbers from the last 90 days of your own ticket queue.

The first is total tickets. Not unique tickets, not conversations; tickets. This is the number you divide by to get a per-event cost.

The second is the share of tickets that map to a question with a written answer that does not change weekly. Anything that needs a judgement, a refund, a complaint escalation, or a real conversation is excluded. Count it rather than estimating it. A number that arrives without counting is usually the vendor's, and the vendor counted a subset.

The third is the average number of messages per conversation on that repeatable subset. This is the input to a per-message plan and is the number most buyers never measure. Two messages per conversation is a tight, well-designed answer. Six is a meandering one. The plan cost changes with it.

Which meter fits which queue

None of the five tools is the right answer for every queue. The right answer depends on the three numbers above and on the size of the team.

A small team with a high repeatable share and a low message count per conversation pays the least on a per-message plan. A medium team with a moderate repeatable share and a stable product catalogue pays the least on a per-seat plan with an included AI allowance. A large team with a low repeatable share and an unpredictable catalogue pays the least on a per-event meter where the seat cost is small relative to the usage cost.

None of those generalisations is a recommendation. They are the shape of the decision, and the shape is different for every queue.

What changes the answer

Volume is the lever on every meter except per-seat. Seat-based meters do not move with volume, so a team that doubles its automation rate without changing its headcount halves its per-resolution cost on a per-seat plan.

Team size is the lever on per-seat meters and not much else. A team that grows from 5 to 10 agents doubles the seat cost on every per-seat plan and barely moves the cost on a per-event or per-message plan.

Repeatable share is the lever that the vendor case study sets for you, and the lever you actually own. The buyer who overstates it is paying more per resolution than the buyer who counted it, because the seat cost is unchanged and the denominator shrank.

Message count per conversation is the lever on per-message plans and only on per-message plans. The buyer whose bot answers in two messages instead of six pays a third of the plan cost on the same number of resolutions.

Simple tools for handling customer questions automatically

If you want a short path through this, three rules show what to look for.

1. Find the vendor that publishes the meter closest to the one you already measure. If you count tickets, look at Gorgias. If you count seats, look at Zendesk, Freshdesk, Intercom or Front. If you count messages, look at Asyntai.
2. Quote the published price against your own repeatable share, not the share in the case study. Halve the case-study number, then halve it again, and check the per-resolution cost at that floor.
3. Ask which line item moves when your volume halves. If nothing moves, you are paying for a seat you cannot shrink. If a single line moves, you have a meter that responds to your actual queue.

The tools that handle customer questions automatically are not interchangeable. They are five different meters wrapped in five different products, and the meter decides what happens to the bill when your queue changes shape.

The honest comparison

Automation in this market is sold as a percentage and billed as a line item, and the two do not appear on the same page. The page above puts them on the same page, against the same stated inputs, at two different volume assumptions. The numbers will not match your queue. The shape of the answer will.

Pick the meter that fits your queue size and your repeatable share. Read the published price as the cost at the vendor's assumed volume, not as the cost at yours. Run the arithmetic with your own numbers before signing, and re-run it every quarter, because the share that is genuinely repeatable moves with the catalogue.