What share of customer support requests can AI really resolve?

There is no universal percentage of support requests that AI resolves without an operator. Vendor case-study figures may be accurate, but they relate to a specific ticket flow, a specific definition of "closed," and a specific way of counting. You can transfer such a figure to your support only when all three components coincide, and this rarely happens.

So start with three questions, not a percentage. What do you consider a resolved ticket? Which tickets are included in the denominator? Are repeated contacts with the same problem taken into account? This article will help you unpack a vendor’s claim, choose request types for a pilot, and measure results using your own data. It also explains the difference between AI that assists an operator and AI that responds to customers on its own.

What "closed" means: three different events

In customer support, “resolved” has at least three meanings, and each produces very different numbers.

The conversation ended. The customer stopped writing. This is the easiest event to measure, but it says the least about the outcome. The customer may have received an answer, or may have given up, visited a competitor’s website, or called a support line.

The ticket was not handed off to a person. In the industry, this is often called containment: keeping the ticket within the bot. The metric shows that no operator joined the conversation. It does not show whether the customer got the help they needed.

The customer confirmed the resolution. The customer answered “yes, that helped” or gave a positive rating. This is the closest measure of a real outcome, but it still has limitations: not everyone confirms, and those who do may differ from those who stay silent.

There's a fourth event that's easy to miss: repeat contact. If the customer came back with the same question a day later, the previous "closed" was false, no matter how it was counted.

When someone quotes a resolution rate, first ask which of these events counts as a resolution and whether repeat contacts are excluded.

How to read supplier numbers

AI support metrics can use different denominators and counting rules. One metric, for example, may count only conversations in which the bot took part, while another counts all new tickets. Some systems count a resolution when the customer explicitly agrees, and also when the customer neither asks for an operator nor disagrees. That is an assumed resolution, not direct confirmation.

Before comparing providers or putting someone else’s result into a business plan, ask:

• what is in the numerator: confirmed resolutions only, confirmed plus assumed, or every conversation marked closed;
• what is in the denominator: all tickets, only those involving the bot, or selected categories;
• what period and ticket flow the figure covers;
• whether repeat contacts are included and over what time window;
• whether handoffs to an operator are counted separately, and what role people played in the process;
• whether the metric includes conversations that ended before a resolution, or only cases where the customer’s need was confirmed as met.

If the bot handled only part of the total flow, its share of resolved conversations cannot be presented as the share of all company tickets. Check both denominators and report coverage, confirmed outcomes, assumed outcomes, and repeat contacts separately.

Example calculation: one ticket flow, several different percentages

The numbers in this example are fictional and for illustration. A full seven days of observation have passed for each of the 360 conversations the bot marked as resolved; tickets at the end of the month are counted only after that period is complete. Otherwise, the 320 conversations with no repeat contact could not be counted fairly.

The same bot activity produces 60%, 53%, 36%, 33%, 32%, or 20%, depending on the numerator and denominator. The arithmetic can be correct in every row while the conclusion is wrong: 60% of tickets handled by the bot does not mean “AI closes 60% of company tickets.” The 40 repeat contacts also matter and should not disappear inside the total marked as resolved.

Arithmetic: 360 / 600 = 60%; 360 / 1,000 = 36%; 200 / 600 ≈ 33%; 200 / 1,000 = 20%; 360 − 40 = 320; 320 / 600 ≈ 53%; 320 / 1,000 = 32%.

Operator assistance and autonomous resolution are different outcomes

AI can support customer service in at least two ways. In one, it assists an operator by finding information, suggesting a draft reply, or helping the operator follow a procedure. A person still handles the conversation, so results are measured at the team level—for example, handling time, issues resolved per hour, answer quality, and repeat contacts.

In the other, AI responds to the customer on its own. Here, it is important to count separately the conversations the system handled, those handed off to an operator, those confirmed by the customer, and those marked resolved without direct confirmation. A customer going silent does not by itself prove that the issue was solved.

Agents can also be tested in simulated scenarios. These tests help check whether a system follows instructions, uses tools, and applies specified rules under controlled conditions. They can reveal errors and inconsistent behavior, but they do not measure the share of successful resolutions in a particular company’s real support flow.

Results from an operator assistant, a simulation, and autonomous support therefore cannot be put into the same formula. A business decision needs its own pilot, using defined ticket categories and checks for answer accuracy, repeat contacts, and handoffs to people.

Which tickets to include in the pilot

The pilot should be built on tickets where the outcome can be clearly verified. Good candidates have several common traits:

• frequent and similar: order status, business hours, how to change the password, where to find the document;
• have stable rules: the answer does not depend on the mood of the manager or the exception for a particular client;
• have a source of truth: the status is taken from the order system, the rule from the current knowledge base;
• allows the outcome to be checked: you can tell if the answer was correct without interviewing the customer.

Bad candidates for the first pilot: complaints, refunds with conditions, billing disputes, anything with personal or medical data, tickets where a decision with authority is required. They can be partially automated, such as collecting information before passing it on to an operator, but not as “resolved by a bot”.

A practical method of selection: take tickets from the last few months, group them by topic, and for each topic evaluate the frequency, stability of the rules, and verifiability. Choose two or three topics that score highly on all three criteria for the pilot.

Example table for selecting topics

The table uses fictional illustrative scores. Each criterion is scored from 1 to 3.

The table does not indicate how many tickets the bot will close. It helps you avoid starting with a topic where the result cannot be checked and mistakes are costly.

How to measure your own results

To get a figure you can trust, you'll have to measure it yourself. Here is a minimal technique.

Determine the metrics before launch. Write down what the numerator and denominator of each metric is, what the repeat-contact window is (eg 7 days), and how "same question" is defined. Do not change the definition in the middle of the pilot.

Track several metrics in parallel. For each topic, measure the bot’s participation rate, the rate of tickets resolved without an operator, the rate of customer-confirmed resolutions, repeat-contact rate, and handoff rate.

Review a random sample. Each week, select a random sample of conversations the bot marked as resolved. Have a trained reviewer check whether each answer was accurate, complete, and consistent with policy. Without this check, you know only that the customer stopped replying, not that the answer was correct.

Track repeat contacts across all channels. A customer who does not get an answer in chat may call instead. If phone tickets are not associated with chat, repeat contacts will be undercounted.

Measure customer satisfaction separately. Post-conversation rating, complaints, proportion of customers who asked for a person and didn't get one. Do not fold these indicators into the resolution formula; review them alongside it.

Check the handoff quality. Part of the tickets will inevitably go to the operator. See if the operator receives a brief description of the problem and the data already collected, or if the customer has to start over. Bad handoff harms the experience even when the bot itself responded correctly, and increases the operator's time working on such tickets.

Use a comparison. If possible, compare the same ticket category before and after launch, or enable the bot for part of the ticket volume randomly. Otherwise, seasonal changes can be mistaken for a bot effect.

The decision to expand

Extending AI support to new topics is worthwhile when the pilot has shown results based on several metrics at the same time, rather than just one. An extension is justified if:

• the proportion of confirmed solutions and the proportion without repeat tickets are stable over several weeks;
• sample testing shows an acceptable level of errors in answers;
• there are no more complaints about the bot than there were about the corresponding channel before;
• operators do not receive more complex tickets without context, that is, the transfer works;
• saving operators' time exceeds the costs of maintaining the knowledge base, checking and processing bot errors.

The last point is often underestimated. The bot needs people: someone updates the knowledge base, sorts out wrong answers, configures handoff rules. This work should be included in the calculation of savings.

If one of the metrics worsened after the expansion, such as an increase in repeat contacts for a new topic, return the topic to a mode where the bot only collects information for the operator and find out why.

Conclusion: How to evaluate AI support on your own request volume

1. Record the definitions: what is a resolved ticket, what is a re-contact window, what is in the denominator.
2. Calculate the current flow of tickets by topic and choose two or three topics with frequent, stable and verified tickets.
3. Set up tracking of bot participation share, resolved without an operator, customer-confirmed, repeat and transferred tickets separately.
4. Mark a random sample of "solved" conversations each week.
5. Link contacts from different channels to see repeat contacts.
6. Compare with the period before the start or with the control part of the flow.
7. Expand only those topics where all metrics are stable and count the full cost of maintaining the bot.
8. Use the numbers from other companies' case studies only together with their definitions, and not as a forecast for your own results.

Frequently asked questions