"Our customers see 80% autonomous resolution." You will see claims like this in every AI support vendor's marketing. What you won't see is what that number means, how it's measured, what ticket mix generates it, and whether the same number would apply to your support queue.
Resolution rate is real and meaningful — but it is not a single number. It is an output of a specific combination of ticket mix, KB quality, confidence threshold settings, and integration depth. Before you set expectations with your team or leadership, you need a framework for what your realistic ceiling looks like. This is that framework.
Why the same system produces different resolution rates
Autonomous resolution rate varies dramatically across deployments because the inputs vary dramatically. The three biggest drivers:
Ticket mix. A support queue where 70% of tickets are high-volume Tier-1 (password resets, billing clarifications, feature how-tos, account status questions) will support much higher autonomous resolution rates than a queue where 50% of volume is account-specific Tier-2 or escalation cases. The ticket mix is determined by your product and customer profile — it is not something you can optimize directly, but it sets a ceiling for what autonomous resolution can achieve.
KB coverage and quality. We have documented this extensively in a separate post on KB quality. At the summary level: if your knowledge base has good coverage of your high-volume ticket categories, resolution accuracy is high and autonomous rate climbs. If KB coverage is patchy — articles that are outdated, missing edge cases, or not organized in a way that retrieval can use them effectively — accuracy drops and the system escalates more tickets rather than resolving them incorrectly. KB quality is the single most controllable variable in resolution rate.
Confidence threshold settings. The threshold at which Replixa escalates rather than resolves is configurable. A lower threshold means more tickets get resolved autonomously, but also means more low-confidence resolutions, which increases error rates and customer reopens. A higher threshold is more conservative but also more accurate. The resolution rate number you produce is a function of where you set that threshold — which means comparing raw resolution rates across organizations with different threshold settings is not meaningful.
What 60 percent autonomous resolution looks like
A 60% autonomous resolution rate is a common starting point for teams deploying AI support automation for the first time. It is not a failure mode — it is what you should expect if you have average KB quality, a standard SaaS or e-commerce ticket mix, and conservative threshold settings on a fresh deployment.
At 60%, for a team handling 500 tickets per day: 300 resolve autonomously, 200 go to human agents. Human agents are no longer handling password resets and billing questions that make up a large fraction of volume. Their queue is composed almost entirely of Tier-2 and escalation cases plus the ~40 tickets per day where the system escalated due to low confidence or category rules.
The operational picture: MTTR (mean time to resolution) for the autonomous 60% is measured in seconds to 2 minutes. For the human 40%, MTTR is whatever it was before automation — probably 2-6 hours. Average MTTR across all tickets drops significantly because of the bimodal distribution.
The right question at 60% is not "how do I get to 80%?" but "what is preventing the other 40% from resolving autonomously?" The answer is almost always KB gaps for the escalated portion and appropriately set category rules for the explicitly routed portion. Audit the escalation queue: which ticket categories are escalating at the highest rate? Those are your KB improvement targets.
What 80 percent autonomous resolution looks like
Reaching 80% autonomous resolution requires deliberate KB work and usually takes 4-8 weeks of iteration after initial deployment. The teams that get here have done three things consistently: they've filled KB gaps identified from the escalation queue analysis, they've tuned confidence thresholds per category rather than globally, and they've been operating Replixa long enough that the feedback loop from human corrections has improved accuracy on their specific ticket vocabulary.
At 80% on a 500-ticket-per-day queue: 400 resolve autonomously, 100 go to human agents. Those 100 tickets are genuinely complex — they are not low-hanging fruit that was missed. They require account-specific judgment, escalation decisions, or handling that involves external teams.
The staffing implication at 80% is significant. A team that needed 6 agents to stay current with a 500-ticket daily volume can likely maintain service quality with 3-4 agents at 80% autonomous resolution, depending on how complex and time-intensive the remaining 20% is. The remaining agents are doing higher-value work — they are handling the cases that actually need human judgment — but they are doing far less repetitive processing.
To be direct about limits: 80% is achievable for most SaaS and e-commerce support queues with good KB investment. It is not achievable in 48 hours. Anyone claiming "go live today, 80% resolution immediately" is either measuring something different from autonomous resolution of real tickets, or they are applying the resolution label to deflection events — sending a link to an FAQ article and calling it a resolution.
What 95 percent autonomous resolution looks like
95% autonomous resolution is achievable but describes a specific situation: a product and customer base where the ticket mix is heavily weighted toward standard, predictable Tier-1 categories; the KB is comprehensive and well-maintained; confidence thresholds have been tuned over several months; and the product itself is relatively stable (not constantly shipping features that generate new ticket types).
Consider a horizontal SaaS with a mature product and a support queue where 80% of inbound tickets are billing questions, account access issues, and usage how-tos — categories that have been well-documented for years and generate essentially no novel content. In that environment, 95% autonomous resolution is a realistic target after a few months of KB refinement.
At 95% on a 500-ticket day, only 25 tickets reach human agents. Those agents exist primarily for edge cases and relationship management — the 5% that falls through is a deliberate decision that some ticket types always warrant human handling, not a failure of the system to resolve them.
What 95% is not: the right target for every support team. Some ticket mixes will never support 95% autonomous resolution because the remaining ticket types are inherently complex and account-specific. Setting 95% as a target when your ceiling is realistically 75-80% due to ticket mix characteristics will lead to overly aggressive threshold tuning that inflates the resolution number while degrading resolution quality.
A framework for setting your realistic target
Before deploying autonomous resolution, run through this input assessment:
Estimate your automatable fraction. Pull 100-200 recent tickets and categorize them manually. What fraction are standard Tier-1 with no account lookup required? What fraction are Tier-2 that need API data? What fraction are genuine escalations? The sum of Tier-1 and automatable Tier-2 is roughly your ceiling for autonomous resolution rate at high accuracy settings.
Rate your KB quality honestly. On a 1-5 scale: do you have articles that cover your top 20 ticket categories? Are they current? Are they written from the customer's perspective or the internal agent's perspective (the latter is harder for retrieval to use effectively)? A 2/5 KB quality score means you're probably starting at 50-60% and need significant investment before reaching your structural ceiling.
Factor in your accuracy tolerance. Some support operations have very low tolerance for incorrect autonomous responses — high-value customer relationships, sensitive billing contexts, heavily regulated industries. In those cases, you set higher thresholds that reduce the autonomous rate but increase accuracy. Plan for a resolution rate 10-15 points below your structural ceiling to account for the accuracy floor you need to maintain.
The output of that assessment is a realistic starting estimate and a realistic ceiling. Work from there, not from vendor marketing numbers that represent best-case scenarios in favorable conditions.