96% resolution is a good number to put on a page. It's also the number we'd most want a customer to read carefully rather than just repeat, because "resolution rate" isn't a standardized term across this industry, and a single percentage can hide as much as it reveals.
What "resolved" actually means, at least for us
A resolved conversation is one where the customer's need was met without a human stepping in — not a conversation where the agent said something plausible and the call ended. Those sound similar and aren't. It's the same distinction customer service teams have long drawn with first call resolution, a metric with the same trap: easy to quote as one clean percentage, easy to misread if "resolved" quietly means "the call ended" rather than "the customer's actual need was met." A caller asking "are you open Sundays" gets a clean resolution either way. A caller trying to book a specific slot, check a policy exception, and confirm a price in one conversation is resolved only if all three actually landed. That's a meaningfully higher bar than "the conversation ended without incident," and it's not the bar every vendor uses.
Three conversations, three different outcomes
It helps to see the distinction concretely. A customer asks for Thursday availability, gets offered two real open times, picks one, and gets a confirmation — that's resolved, cleanly. A customer asks about a cancellation policy the FAQ doesn't cover, the agent says it isn't sure and offers to connect them to staff — that's an honest escalation, not a failure, and shouldn't be counted as resolved even though the conversation "ended" in some sense. A customer asks a slightly unusual version of a common question, gets an answer that sounds complete but is subtly wrong because the underlying FAQ was vague — that's the dangerous case: it counts as resolved in a loose measurement, and it's the one worth catching through spot-checking transcripts, not just watching the percentage.
The average hides the categories underneath it
A business's overall resolution rate is an average across every kind of question it gets asked, and averages are good at hiding exactly the thing you'd want to see. A deployment sitting at a healthy 91% overall can still have one specific query type — a confusing cancellation policy, a service the FAQ hasn't caught up with — resolving at 60%, quietly buried under everything else that's working fine. The average tells you the system is doing well in general. It doesn't tell you where it isn't, which is the more useful question.
A healthy average can sit directly on top of one badly broken category, and never show it.
Why 100% would actually be a warning sign
It's natural to treat anything short of 100% as a gap to close, but a small share of any real call volume genuinely needs a person — an upset customer, a legal question, a request that falls outside any policy that's been written down. A system reporting 100% resolution either isn't seeing that volume at all, or is resolving things it shouldn't be resolving on its own. The goal isn't zero escalations. It's making sure the escalations that do happen are the right ones, for reasons that make sense when you read them.
Resolved isn't the same as satisfied
A conversation can be technically resolved and still be a mediocre outcome. If a customer asks a question, gets a complete and accurate answer, and calls back the next day asking essentially the same thing in different words, the first conversation counted as a resolution — but something about it didn't fully land. This is why resolution rate is a number to read alongside repeat-contact rate and CSAT, not by itself. Those catch the gap between "technically answered" and "actually helped" that resolution rate, on its own, can't see.
Why it moves during the first few weeks
Resolution rate for a new deployment is rarely at its final level on day one, and that's expected rather than a problem. The first stretch of real conversations surfaces exactly the phrasing, exceptions, and edge cases a business's FAQs hadn't anticipated — the same calibration window any pilot goes through — and each fix nudges the number up. A business that checks resolution rate once on day two and treats it as the permanent verdict is judging the system before the configuration has actually caught up to real customer behavior.
A worked example of reading the number correctly
Say a business's dashboard shows 88% resolution for the month — a reasonable, healthy number inside the 82%–96% range we publish. Read on its own, that's a fine headline. Read against the intent breakdown underneath it, the picture might show hours and pricing questions resolving above 95%, straightforward bookings around 90%, and a specific category — say, insurance or warranty questions — resolving closer to 65%, dragging the blended average down without ever standing out on its own. The fix isn't to distrust the 88%. It's to go straight to the category that's actually underperforming, rewrite the FAQ entries behind it, and watch that specific number over the next week rather than waiting for the blended average to slowly reflect the fix.
How this relates to escalation rate
Resolution rate and escalation rate are two views of the same underlying split, which makes reading them together more useful than reading either alone. A rise in escalations tagged "customer asked for a human" will show up as a dip in resolution rate that isn't actually a problem — that's the system correctly recognizing it should hand off. A rise in escalations tagged "system couldn't handle the request" shows up the same way in the top-line number, but it's a configuration gap worth fixing. The percentage alone can't tell those two apart; the reason codes behind the escalations can, which is why reading the two side by side tells you more than watching resolution rate in isolation.
Why we'd ask this of any vendor, not just us
Before comparing a headline resolution-rate number across tools, it's worth asking exactly what counts as "resolved" in that number — whether it means the customer's need was actually met, or just that the conversation ended without an explicit transfer to a human. Those are very different bars, and a system that quietly uses the looser one will always look better on paper than one that holds itself to the stricter definition. That question matters more than the number itself. It's also worth asking whether the vendor's number is measured on real customer traffic or on a curated demo set — the two can look very different.
What to actually watch
Look at your intent breakdown, not just the top-line average — the auto-categorized view of what customers are actually asking about will show you which categories are dragging the average down, which a single percentage never will. Watch the trend across your first few weeks rather than fixating on day one, since performance typically improves as configuration gets refined against real conversations. And read resolution rate next to the other KPIs that actually matter — especially escalation reasons and repeat contacts — rather than in isolation.
Check your own breakdown in AIVA's analytics, or see how voice performs day to day. For more on the terminology that comes up around this, our plain-language glossary covers the related terms — intent, escalation, NLU — that resolution rate usually gets discussed alongside.