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
- The metric every vendor leads with (and why it breaks)
- The framework: proxy KPIs vs outcome KPIs
- AI resolution rate (read it time-weighted)
- CSAT on AI-resolved tickets (the guardrail)
- Cost per resolved ticket (the real ROI denominator)
- Resolution-rate trajectory (the leading indicator)
- Knowledge-gap closure and escalation health (the other Engine metrics)
- What this looks like in real rollouts
- TravelJoy: 24% to 80%, and the label trap in one screenshot
- Edel Optics: 25% to 79%, earned by the customer
- YouGarden and RecruitCRM: volume and discipline
- The field benchmark: what "good" actually is
- What to track this week
- How do I get AI to audit my dashboard against the grid?
- When this framework doesn't apply
- The takeaway
- FAQs
Created time
Jun 5, 2026 12:55 PM
Title length (<60)
Author
Ecomm?
Image
Publish date
Jun 9, 2026
Slug
ai-customer-service-kpis
Featured
Type
Article
Ready to Publish
Ready to Publish
Most AI support dashboards lead with deflection rate. It tells you a ticket didn't reach a human, never whether the problem got solved. Here are the KPIs that actually predict ROI, and the five to stop leading with.
If your weekly AI support report leads with deflection rate, I'd bet your AI is making your customer experience worse, and the number on the slide is hiding it.
Every AI vendor pitches the same headline KPI: deflection rate, containment rate, tickets handled without a human. Open any "customer service KPIs to track" guide and you get a flat list of eight to twenty-one metrics, led by the ones that count activity. The Zendesk version runs to 21 KPIs; JustCall lists 14.
Almost none of them stop to ask the question I care about: which numbers actually predict whether the AI is paying for itself?
So here's the take I'd argue: the KPIs that predict ROI all measure one thing (a problem actually solved), and they're close to worthless unless you also measure how easy it is for a stuck customer to reach a human.
Most dashboards track the opposite. They lead with proxies for activity that can climb while satisfaction quietly craters, because an AI agent can close a ticket prematurely and book it as a win.
I'm Mike, co-founder of My AskAI. We help 200+ ecommerce and SaaS businesses run AI customer service inside Intercom, Zendesk, Freshdesk, HubSpot and Gorgias, and our agents have resolved over 1,000,000 tickets so far. We also compiled a first-party benchmark of AI resolution rates across roughly 55 vendors and 195 deployments (no competitor has published an equivalent).
So I'm not reciting another listicle here. This is the set of numbers I'd put in front of a CX leader, in the order I'd put them, with the data from real rollouts behind each one.
The metric every vendor leads with (and why it breaks)
TL;DR: Deflection, containment and tickets-handled measure activity rather than a solved problem. They can climb while CSAT falls, and the metric label alone swings the number more than capability does (resolution reads about twelve points higher than automation across the field).
Deflection rate, containment rate, average handle time, tickets-handled: these are the legacy contact-center KPIs, and the consensus guides still lead with them. They're not useless; I still want a couple of them for staffing maths.
The problem is what they don't measure. A deflected ticket is one that didn't reach a human. A contained conversation is one that stayed in the chat widget.
Neither tells you whether the customer's problem got solved. That gap is the whole game.
We've watched teams celebrate an 80% deflection number while their CSAT slid, because the bot was closing conversations the customer had simply given up on. Mavenoid put it bluntly: a basic chatbot is "incentivized to show off a higher deflection rate" without resolving anything. Even Intercom's own Fin team admits it in their glossary: "A high deflection rate could mean excellent automation—or it could mask customer dissatisfaction and eroded trust… What matters is whether the issue was resolved, regardless of who handled it."
There's a deeper reason these numbers mislead, and it jumps out of the benchmark data. Across the field, the label a vendor puts on its headline metric moves the number more than the underlying capability does.
Deployments that report "resolution" sit at a median of 72.5%; deployments reporting "automation" sit at 61% (roughly twelve points lower for the same kind of work, because each label counts a different event). These are aggregate field figures and directional rather than a like-for-like ranking, since every vendor defines its own numerator.
When the metric name alone can swing a number by twelve points, leading your board report with whichever label flatters you most is marketing dressed up as measurement.
One more thing worth flagging. The old human-rep benchmark for first contact resolution sits around 70%, with top teams near 85% (per SQM Group). Notice that "70%" shows up twice (once for human FCR, once as the AI resolution-rate field median), and they're completely different events with different numerators.
The surface number is the same; what it means is not. That's exactly why a flat list of KPIs, with no organizing idea behind it, leads teams astray.
The framework: proxy KPIs vs outcome KPIs
TL;DR: Sort every KPI on two axes (activity vs outcome, lagging vs leading). ROI lives in two boxes: Scoreboard (resolution rate, CSAT on resolved tickets, cost per resolved ticket) and Engine (resolution-rate trajectory, knowledge-gap closure, escalation health). Most dashboards live in the other two.
Sort every KPI on two questions:
- Does it measure activity, or an outcome? Activity metrics count what happened (a ticket was deflected, a reply was sent). Outcome metrics count whether the customer got what they came for.
- Does it report the past, or predict the future? Lagging metrics tell you about last month. Leading metrics tell you where next month is heading.
Put those two axes together and every metric on your dashboard lands in one of four boxes. I call it the Vanity / Theater / Scoreboard / Engine grid.
ㅤ | Lagging (reports the past) | Leading (predicts next month) |
Activity | Vanity: deflection rate, tickets handled, average handle time | Theater: response-time SLAs, automation-rate trend |
Outcome | Scoreboard: AI resolution rate, CSAT on resolved tickets, cost per resolved ticket | Engine: resolution-rate trajectory, knowledge-gap closure, escalation health |
ROI lives in two boxes: Scoreboard (what you've actually earned) and Engine (what you're about to earn). Most AI support dashboards live in the other two.
The Vanity box is where vendors want your eye, because those numbers are the easiest to make look good. The Theater box feels rigorous (it has trends and SLAs), but it's still measuring activity instead of outcomes.
The five KPIs below are the Scoreboard and Engine boxes in full. These are the ones worth leading your report with.
AI resolution rate (read it time-weighted)
Resolution rate is the one to beat: of the conversations your AI handled, how many ended without needing a human?
A quick word on how to count it, because this is where vendors inflate. We count a conversation as resolved if it wasn't escalated to a person, and that's only a fair signal because we make escalation genuinely easy. A customer can ask for a human in plenty of ways; the AI also hands off on its own when it can't answer, when it spots frustration, or when a ticket hits a topic you've flagged for a person.
We deliberately don't claim to know an issue was solved without the customer confirming it (you can't know that without asking). The honesty of a resolution number is really a function of how easy it is to reach a human. A high number behind a hard-to-find escalation path is the most dangerous figure on the dashboard.
For a benchmark: across our first-party dataset of ~195 deployments, the field median resolution rate is 70%, with the middle half landing between 56% and 80%. Our own rolling rate across the full customer base is 72%. Treat those as a rough map of where the market sits, never a precise ranking, because every vendor measures resolution a little differently.
But not every point of resolution is worth the same, and in my experience this is the bit that changes how you read the number. A point you gain from knowledge is worlds away from a point you gain from a task.
Knowledge resolution is the cheapest and fastest to earn: you type an answer once and the AI uses it forever, and those are usually the quick, repetitive questions your team already has macros for. Data resolution is the next rung: expose an API so the agent can see a customer's order status or account, and you unlock a whole block of tickets at once. Often that's 5, 10, 25, even 40% of your volume in one move, and each one saves a human from going into another system to look something up.
Task resolution is the top rung: let the agent actually do something (issue the refund, change the address, update the plan), and each of those points replaces a multi-system, multi-step job a person used to do and then check. Those are the most valuable points of resolution you can buy.
So read your resolution rate time-weighted. Break it down by where the resolution comes from (knowledge, data, or task), because a team sitting at 70% on knowledge alone has a very different ROI profile (and a very different roadmap) from a team at 70% where a third of that is task automation.
CSAT on AI-resolved tickets (the guardrail)
Resolution rate on its own can be gamed by closing tickets aggressively. The metric that catches that is CSAT, measured specifically on the tickets the AI resolved, never blended across every conversation.
If resolution climbs while CSAT-on-resolved holds or rises, the AI is genuinely solving problems. If resolution climbs while CSAT-on-resolved falls, you're force-closing tickets and the customers aren't happy about it.
The pairing is the point: resolution names whether the issue ended, CSAT names whether it ended well. Across our rollouts the two move together when things are healthy: TravelJoy holds 86% CSAT at an 80% resolution rate, and Edel Optics 92% at 79%.
The common slip is reporting CSAT across all tickets, which dilutes the signal until it tells you nothing about the AI in particular.
Cost per resolved ticket (the real ROI denominator)
If the economic buyer wants a single number from me, it's cost per resolved ticket. Cost per conversation and the raw monthly invoice both miss the point.
The reason matters, and we feel it in how we price. Under per-conversation or usage-based pricing, your bill stays roughly flat as the AI improves, so as resolution climbs, your cost per resolved ticket falls. Under per-resolution or outcome-based pricing, the opposite happens: the bill rises in lockstep with the very improvements your own team produced.
And most of that improvement is your team's work rather than the vendor's. I'd say we drive maybe a fifth of it; the rest is you connecting knowledge, exposing APIs, tuning guidance, and running a weekly QA loop. That's the case for watching cost per resolved ticket over the headline rate: it's the number that tells you whether the economics are getting better or worse as you scale, and under a usage-based model it should be getting better.
Resolution-rate trajectory (the leading indicator)
Every metric above is lagging. It tells you about tickets that already happened. The Engine box is where the leading indicators live, and the one I'd watch hardest is the slope of your resolution rate rather than its level.
The reason the slope beats the level is mechanical. Knowledge gains are stable and incremental: you add articles, you fix answers, the rate ticks up slowly. The big jumps come when you add user data or build tasks.
So a lot of teams make fast early gains on knowledge, watch the line flatten, and conclude they've hit the ceiling (we see this constantly). They haven't. They've hit the plateau trap: the point where knowledge alone is exhausted and the next gains are sitting behind an API or a task they haven't built yet.
A flattening slope isn't a sign you're done. It's the signal to climb the ladder. If you only ever watch the level, you miss the moment the trajectory is telling you to act, and I've watched plenty of teams miss it.
Knowledge-gap closure and escalation health (the other Engine metrics)
Two more leading indicators round out the Engine box. The first is knowledge-gap closure: how quickly you're turning the questions your AI couldn't answer into knowledge it can.
This is the operational input that drives the resolution-rate slope, and it's a weekly habit more than a number: review what the AI missed, write the answers, and watch the rate respond over the following weeks. (No help center to start from? You don't have to write one from scratch. Our Train on Historic Tickets feature generates starter knowledge from your past resolved tickets, defaulting to a backfill of 5,000, so a team with no docs can still get going.)
The second is escalation health, and it's a guardrail rather than a vanity figure. The mistake is treating a low handoff percentage as good. On its own it isn't good, because a low handoff rate can just as easily mean the AI is trapping people.
What you actually want to measure is whether a stuck customer can reach a person quickly. If they can, your resolution number is automatically trustworthy: anything resolved was genuinely resolved, and anything that wasn't went to a human. If they can't, every other number on the dashboard is suspect.
(For audit, our team-facing Inspect view lets you open any conversation and ask the AI "why did you give this answer?". The reasoning and sources are there for your team to check, though they're not shown to the end customer.)
What this looks like in real rollouts
TL;DR: Across My AskAI rollouts the outcome KPIs move together, and the lift comes from customer-side work. TravelJoy went 24% to 80% at 86% CSAT, Edel Optics 25% to 79% at 92% CSAT, against a 70% field median resolution rate.
The framework isn't theoretical. Across My AskAI rollouts the outcome KPIs move together, and (this is the part that matters for ROI) the lift comes from customer-side work, which is exactly what the Engine box is built to surface. Every number below is from a real, published customer.
TravelJoy: 24% to 80%, and the label trap in one screenshot
TravelJoy switched from Zendesk's own AI agent to My AskAI and went from a 24% resolution rate to 80%, at 86% CSAT, saving 193 hours a month. Their team described it as "achieving an impressive 76% AI resolution rate, versus just 24% before."
Same support operation, same tickets. The outcome metric moved because the capability genuinely improved, while the label stayed put. It's the cleanest proof I've got that resolution rate, measured properly, tracks something real.
Edel Optics: 25% to 79%, earned by the customer
Edel Optics went from 25% to 79% resolution at 92% CSAT across 4,067 tickets, saving 150 hours a month. The lift came when they plugged in the User Data API so the agent could see order and account information.
That's the data rung of the resolution ladder in action: one integration, a large block of newly resolvable tickets, and each one saving an agent a trip into another system. It's also the textbook Engine-box story. The vendor didn't make that number move, the customer's own work did.
YouGarden and RecruitCRM: volume and discipline
YouGarden runs at 66% resolution (peaking at 82%) across 11,785 tickets a month at 78% CSAT, saving 965 hours, roughly six full-time agents' worth of work. RecruitCRM climbed from about 35% at go-live to 68% at 75% CSAT, driven by a disciplined weekly QA loop.
That weekly habit is the knowledge-gap-closure metric made concrete, and it's why their slope kept climbing instead of plateauing. The boring-but-effective option, basically: show up every week and close the gaps.
The field benchmark: what "good" actually is
Want to know whether your own number is any good? The field median is 70%, with most deployments between 56% and 80%. Our 72% sits just above the center.
But the spread is wide, and resolution rate depends heavily on your industry, ticket mix and how much setup work you've done. Treat the benchmark as a map of where the market sits rather than a target you've failed to hit.
What to track this week
TL;DR: Swap your lead metric from deflection to resolution-plus-CSAT, add an escalation-health guardrail, and track the slope of your resolution rate as the leading indicator. Break resolution down by source (knowledge, data, task) and weight your roadmap toward the high-value task points.
You can act on all of this in an afternoon, plus a small weekly habit. Here's the order I'd do it in:
- Audit your current dashboard against the grid. Pull last month's report and tag every metric on it as Vanity, Theater, Scoreboard or Engine. About two hours, and you'll usually find your lead metric is a Vanity one.
- Swap your lead metric. Make resolution rate plus CSAT-on-resolved the pair at the top of the report. Resolution because it implies a problem was solved, CSAT because it catches whether it ended well. About 30 minutes in your reporting tool.
- Add the escalation-health guardrail. Measure how fast a customer who wants a human can get one (we track it as time-to-human). If that's slow or buried, treat your resolution number as suspect until you fix it. About an hour to instrument.
- Add the Engine leading indicators. Track weekly knowledge-gap closure and the slope of your resolution rate. If the slope is flattening while you're still on knowledge alone, that's your cue to climb the ladder: connect user-data APIs next, then build tasks. About 30 minutes a week, ongoing.
- Re-base your ROI number. Break resolution down by source (knowledge, data, task) and measure cost per resolved ticket instead of per conversation. Weight your roadmap toward task automation, where each point of resolution carries the most saved time.
None of this is tool-specific. The framework works whatever AI agent you run, including ones that aren't ours. I'm selling you the thinking here, and nothing else.
How do I get AI to audit my dashboard against the grid?
If you'd rather not sort your KPIs by hand, paste the prompt below into ChatGPT, Claude or Perplexity. It runs the grid on your real dashboard and tells you what to move to the top of the report. It's desk work, so it can only classify the metrics you give it; you still know your team's context better than the model does.
You are a CX analytics advisor. I'll paste the KPIs from my current AI customer
service dashboard. Sort each one into the Vanity / Theater / Scoreboard / Engine grid:
- Vanity = activity + lagging (deflection rate, tickets handled, average handle time)
- Theater = activity + leading (response-time SLAs, automation-rate trend)
- Scoreboard = outcome + lagging (AI resolution rate, CSAT on resolved tickets,
cost per resolved ticket)
- Engine = outcome + leading (resolution-rate trajectory/slope, knowledge-gap
closure rate, escalation health = how fast a stuck customer can reach a human)
My current dashboard KPIs (lead metric marked): [paste your list]
My helpdesk and monthly ticket volume: [e.g. Zendesk, 8,000 tickets/month]
Then:
1. Tell me which box my lead metric is in, and whether that's a problem.
2. List the Scoreboard and Engine metrics I'm missing, in priority order.
3. Recommend the single metric I should move to the top of my weekly report, and why.
4. Flag anything you can't determine from what I pasted. Write "ask your team"
instead of guessing.
Output a table (KPI | box | keep / demote / add) plus a three-line summary.When this framework doesn't apply
TL;DR: Activity metrics still earn their place for capacity planning, triage-first teams can lead with CSAT by design, and regulated workflows need human sign-off on top of resolution rate. Demote the Vanity metrics from the headline; don't delete them.
A few limits, because I'd rather flag them up front than ship a framework that only ever argues one side and reads like a sales deck.
The Vanity-box metrics still have a job: they're just in the wrong place on a dashboard that leads with them.
Average handle time, ticket volume and response time are genuinely useful for capacity planning and staffing forecasts (we still keep an eye on ours). Demote them from the headline; don't delete them.
Some teams legitimately report CSAT-primary with a deliberately low resolution rate. If your strategy is to triage fast and get people to a human early (a model that suits high-touch or high-stakes support), then a low "resolution" number is working as designed, and CSAT is the right headline. Sofar Sounds runs exactly this pattern: a low AI resolution rate by choice, with CSAT as the metric that matters.
In regulated or high-stakes workflows, a "resolved" ticket might still need a human to sign off, so resolution rate alone won't tell you whether you're compliant. And a team that started at a high resolution rate on day one, with great docs, has less slope left to chase than a team starting from scratch, so I'd weight the trajectory KPI most when you've got room to climb.
The takeaway
TL;DR: Track a solved problem, measured net of the escapes you've made easy to reach. ROI lives in the Scoreboard and Engine boxes of the grid; change your report's lead metric from deflection to resolution-plus-CSAT this week.
Track the event the customer actually cares about (a problem solved), measured net of the escapes you've made easy to reach. That's the whole thesis.
The Vanity / Theater / Scoreboard / Engine grid is just the tool for getting there: ROI lives in the Scoreboard box (what you've earned) and the Engine box (what you're about to earn), and most dashboards are stuck in Vanity and Theater.
If you do one thing this week, change the metric at the top of your report from deflection to resolution-plus-CSAT, and start watching the slope. The realization that does the most work here is that not all points of resolution are equal: the ones that replace real human work are worth chasing hardest, and the rate you're gaining them is a better predictor of next quarter than any number you've already banked.
If you want to see what the outcome metrics look like once the work's been done, the TravelJoy and Edel Optics numbers above are real examples, and the benchmark data tells you where your own number sits against the field.
FAQs
What are the most important customer service metrics to track?
The ones that measure outcomes rather than activity: AI resolution rate, CSAT measured on resolved tickets, and cost per resolved ticket. We'd add two leading indicators (the trajectory of your resolution rate and your weekly knowledge-gap closure), because they predict where next month is heading rather than just reporting where last month went. Deflection rate, tickets handled and average handle time are fine for capacity planning, but they shouldn't lead the report.
What customer service metrics actually matter for AI support?
The same outcome metrics, with one AI-specific twist: read your resolution rate time-weighted. A point of resolution earned by letting the agent complete a task (a refund, an address change) is worth far more saved time than a point earned from a knowledge answer, so break the number down by source rather than treating it as one figure.
How do I measure customer service performance?
Lead with resolution rate and CSAT-on-resolved as the pair, add cost per resolved ticket for the economics, and instrument an escalation-health check (how fast a customer can reach a human). That gives you the full picture: what got solved, whether it was solved well, what it cost, and whether the number is trustworthy in the first place.
How do I measure the ROI of AI customer support?
I'd use cost per resolved ticket as the denominator, alongside hours saved. Under usage-based pricing, cost per resolved ticket falls as your resolution rate climbs, because the bill stays roughly flat while the AI handles more. Edel Optics saved 150 hours a month, YouGarden 965. Avoid measuring ROI on cost per conversation or on your raw invoice, since neither tells you whether the economics are improving.
What resolution rate should I expect from AI customer support?
The field median across roughly 195 deployments is 70%, with most landing between 56% and 80%. But it depends heavily on your industry, ticket mix and how much setup work you've done, and we've watched the same kind of team sit far apart on this. A team running on help-center knowledge alone will land lower than one that's connected customer data and built tasks, so treat the benchmark as a map of where the market sits rather than a pass/fail line.
How can I use AI to improve my customer service KPIs?
Climb the resolution ladder in order of effort and value: connect your knowledge first (fastest, cheapest points), then expose user data via APIs (unlocks big blocks at once), then build tasks for the work your team does by hand (the highest-value points). Watch the slope of your resolution rate as you go: when it flattens on one rung, that's the signal to move to the next.
What's the difference between deflection rate and resolution rate?
Deflection rate measures that a contact didn't reach a human; resolution rate measures that the customer's problem was actually solved. They can diverge badly. An AI can deflect a ticket the customer abandoned in frustration, which counts as deflection but not resolution. Resolution is the metric to report on, because it names the thing the customer cares about.
What should an AI customer service scorecard include?
The Scoreboard and Engine boxes: resolution rate (read time-weighted by source), CSAT on resolved tickets, cost per resolved ticket, resolution-rate trajectory, knowledge-gap closure, and an escalation-health check. Drop the pure Vanity metrics (deflection, tickets handled, average handle time) from the lead, and keep them lower down for capacity planning only.
