Deflection vs Resolution vs Automation: What AI Support Really Measures

This matters more than a glossary argument, because metrics drive money. The number you optimize for becomes the number your AI vendor optimizes for too — and the number they bill you on. A tool paid per deflection is rewarded for ending conversations. A tool paid per resolution is rewarded for closing tickets its own model gets to mark "resolved." Neither captures the full range of work an AI agent actually does in a modern support stack. This post pulls the three apart, shows where each one lies to you, and explains why we built Macha to bill for automation — the work done — rather than a single predefined outcome.

The one-line definitions

Start here, because most confusion is just these three definitions blurring together:

• Deflection — the share of incoming queries that never reach a human agent. A containment metric. It counts avoidance, not success.
• Resolution — the share of queries where the customer's actual problem was solved (refund processed, address changed, answer that held up). An outcome metric.
• Automation — the share of support work an AI performed end to end, across every step: summarizing, tagging, triaging, routing, looking up data in another system, drafting, replying, taking an action. A work metric.

Why deflection flatters and lies

Deflection is the oldest self-service metric, and it's the easiest to game. The problem is structural: deflection counts an abandoned conversation and a confidently wrong answer exactly the same as a genuine fix. If a customer asks a question, gets a plausible-sounding but incorrect reply, sighs, and closes the chat without escalating — that's a deflection. The dashboard goes green. The customer churns three weeks later.

The data backs this up. Gartner's research found that only 14% of customer service issues are fully resolved in self-service — roughly one in seven — even as AI deflects a far larger share of queries away from human queues (Gartner, Aug 2024). That gap between "deflected" and "resolved" is the grey zone where customer frustration lives. Audits of retrieval-based ("RAG") chatbot deployments routinely find that 15–25% of deflected tickets were deflected with incorrect or incomplete answers (digitalapplied). A bot can post a 90% deflection rate while sitting on a 40% real resolution rate, because the two numbers measure entirely different things.

There's a second, subtler trap: deflection rewards deploying AI only on the easy stuff. If you point the bot at password resets and store-hours questions and keep it away from anything hard, your deflection rate looks fantastic — and you've automated the cheapest tickets while the expensive ones still hit humans. Teams that optimize for deflection alone tend to plateau at 30–40% of volume; teams that optimize for genuine resolution push to 70–85% (usefini).

Rule of thumb: if a vendor leads with a deflection or "containment" number and won't show you re-contact rate, treat the figure as marketing. The honest audit metric is re-contact within 72 hours — if a quarter of your "resolved" tickets generate a follow-up within three days, your real resolution rate is much lower than the headline.

Why resolution is better — and still has a catch

Resolution is the right direction. It measures outcomes, not avoidance, and the best AI vendors have rallied around it for good reason: it aligns the tool with the customer. Fin reports an average resolution rate of 67% across 7,000+ customers, with top performers at 80–84% (fin.ai). Resolution-first design — measuring whether the refund actually processed, whether the address actually changed — is genuinely harder to fake than deflection.

But "resolution" hides a question that decides whether the metric is trustworthy: who gets to define "resolved"?

In the dominant per-resolution pricing models, the vendor does. Intercom's Fin bills roughly $0.99 per resolution, where a resolution is counted when the AI replies and the customer doesn't get handed to a human — Intercom's system decides what qualifies (Gleap). Zendesk's Advanced AI add-on (about $50/agent/month to unlock it) bills per Automated Resolution at roughly $1.50 committed or $2.00 pay-as-you-go, and as of January 2026 it added automatic overage billing with no cap or prior warning (Gleap, CorePiper). (Pricing verified via search, June 2026; treat as approximate and confirm against each vendor's current page.)

The incentive problem is the mirror image of deflection's. When the vendor both defines "resolution" and charges you for it, "the AI replied and nobody escalated" can quietly get counted as a paid resolution — which is uncomfortably close to deflection wearing a nicer label. Per-resolution pricing also collapses everything into one binary: a ticket either "resolved" or it didn't. That ignores the enormous amount of useful AI work that isn't a resolution at all.

The third category: automation (the work, not the outcome)

Here's the thing both metrics miss. In a real support operation, the most valuable AI work is often not a closed ticket — it's everything that happens around the ticket:

• Summarizing a 40-message thread so a human picks it up in ten seconds.
• Tagging and triaging by intent so the queue routes itself.
• Routing a VIP or a churn-risk to the right person instantly.
• Looking up an order in Shopify, a charge in Stripe, a record in your database.
• Drafting a reply an agent edits and sends.
• Taking an action — issuing the refund, updating the address, creating the follow-up task.
• Fully resolving, yes — but that's one outcome among many, not the whole job.

None of those except the last is a "resolution," and a chatbot deflection metric can't see most of them at all. This is the category we call automation: the AI did a unit of work, and that work has value whether or not it ends the conversation. A ticket that gets summarized, correctly tagged, enriched with order data, and routed to the right agent in two seconds is a huge win — even though a human sends the final reply and no "resolution" gets counted.

This is the layer Macha operates in. Macha is an AI agent layer on top of the helpdesk you already run — Zendesk, Freshdesk, Gorgias, Front — and it connects the commerce, knowledge, and comms tools where the real work happens (Shopify, Stripe, Notion, Slack, and more). An agent can take a real action mid-conversation, not just retrieve an article.

Because the unit of value is the action, that's what we measure and bill — not deflection, not a vendor-defined resolution.

How automation gets priced: credits per action

Macha is credit-based on purpose. One credit ≈ one AI action, and an action costs 0.5–9 credits depending on the model you choose — lighter, faster models cost less; stronger models cost more — so you control spend by matching the model to the task's difficulty. The default (GPT-5.4 Mini) is 1 credit; a heavyweight reasoning model is more. You pick the model per agent when you configure it.

The philosophy: you pay for the work the AI does, any step of it, not for a predefined outcome that may or may not happen. A summarize-and-route agent never "resolves" a ticket, but it does real, billable-for-good-reason work every single time. Per-resolution pricing would charge you nothing for that — and quietly push you toward only building bots that close tickets, because that's the only thing the meter counts. Automation pricing keeps the whole pipeline in scope. (See the full breakdown on the pricing page.)

To be clear, Macha can deflect and can resolve — those are subsets of what it does. The point isn't that resolution is bad; it's that pricing the entire category of AI support work as one binary outcome is too narrow for what these agents actually do.

What to actually measure

Categories aside, here's the practical scorecard. Track all three layers, not one:

1. Automation rate — what share of support steps (not tickets) the AI performs. This tells you how much labor you've genuinely offloaded across the pipeline.
2. True resolution rate — outcomes you can verify, gated by re-contact within 72 hours. If they came back, it didn't resolve. Audit a sample by hand; don't trust a self-reported number.
3. Deflection — as a guardrail, not a goal. Watch it alongside CSAT and re-contact. A rising deflection rate with falling CSAT is the classic "confidently wrong" signature.
4. Escalation quality — when the AI does hand off, did it hand off cleanly, with a summary and context? A good escalation is a feature, not a failure.

Macha's agent analytics surface the work side of this directly — what agents ran, what actions they took, where they handed off.

Watch-outs and when this framing doesn't help

This isn't a free pass to ignore outcomes. A few honest caveats:

• Automation is not an excuse to skip resolution. If your agents take a hundred actions and customers still come back angry, you've automated busywork, not solved problems. Automation rate is a complement to resolution, never a replacement.
• Credits can surprise you if you ignore model choice. Pointing a 9-credit model at trivial tickets burns budget. Match the model to the task — that control is the whole point, but it requires you to use it.
• If you genuinely only want a deflect-FAQs bot, a simple per-resolution or even a flat-rate tool may be cheaper and simpler than a full agent platform. Macha earns its keep when agents take real actions across connected systems — not when all you need is article suggestions.
• No metric replaces a manual audit. Whatever the dashboard says, read 30 real conversations a month. The number that matters most is the one you saw with your own eyes.

FAQ

What's the difference between deflection rate and resolution rate? Deflection rate is the share of queries that never reach a human — a containment metric that counts conversations the AI touched. Resolution rate is the share where the customer's problem was actually solved — an outcome metric. A bot can have a high deflection rate and a low resolution rate at the same time, because deflection counts abandoned and wrong answers as "handled."

Is deflection a bad metric? Not useless, but dangerous on its own. It's fine as a guardrail watched alongside CSAT and re-contact rate. As a primary goal it rewards ending conversations rather than helping people, and it makes "confidently wrong" answers look like wins.

What is automation rate in AI support? The share of support work — individual steps like summarizing, tagging, routing, data lookups, and actions — that an AI performs, whether or not any single step "resolves" a ticket. It captures value that deflection and resolution metrics miss because most useful AI support work isn't a closed ticket.

Why does Macha price per credit instead of per resolution? Because Macha is an automation platform, not a single-outcome resolution bot. A credit (≈ one AI action, 0.5–9 by model, default 1) bills for the work the AI does at any step. Per-resolution pricing only counts one kind of result and pushes you to build only ticket-closing bots; credits keep the whole pipeline — triage, routing, lookups, drafting, actions, and resolutions — in scope. See the pricing page.

How do I measure if my AI is actually resolving tickets? Gate "resolved" on re-contact within 72 hours and audit a hand-picked sample. If a quarter of resolved tickets generate a follow-up within three days, your real resolution rate is materially lower than the headline.

The takeaway

Deflection asks did it leave the queue. Resolution asks did the customer get helped. Automation asks how much of the work did the AI do. They're three different measurements of the same conversation, and the gap between them is exactly where bad AI hides. Pick the metric that matches what you're trying to achieve — and be suspicious of any vendor whose headline number is also the number they bill you on.

If you want to see what measuring the work looks like in practice, start a 7-day free trial, no credit card required, connect your helpdesk, and watch agents take real actions across your tools — or read the docs for the full picture.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-25 · Last updated 2026-06-25.