To the question “how many tickets can be automated”, many proposals answer with a percentage. On our customer service automation page we give no such percentage, and we say that we start by counting what real tickets are about. This piece shows how to count it yourself. The basis is a sample of two hundred cases from the written channels — email, web form and chat. Phone calls are added separately, from the phone-system report. That gives five numbers, and their combination suggests which project to start with — or that it is not worth starting any for now.
One caveat up front: this is a measurement taken before automation, not a set of indicators for ongoing reporting. These five numbers answer a narrower question — what to automate first. Customer satisfaction or the time spent on one case are not enough on their own to choose the first project, but they help assess its value, and later the effect of the implementation.
How many tickets can be automated? Count it yourself
Articles with “how much will AI take over” ranges rest on data from other people’s companies, counted by other people’s definitions. The best Polish piece of this kind we found — by Piotr Wolniewicz in AIPORT.pl, 8 August 2026 — itself points out what spoils such comparisons: a conversation no human handled is not the same as a case that was resolved. A customer who closed the chat window in anger looks the same in the first tally as one who got an answer. That distinction comes back below, with repeat contacts.
Your inbox knows the answer more precisely than any industry survey, because it is about your customers, your topics and your systems. That is why we give no threshold and no “typical” result here. Every number in this piece is quoted from a source, is a number you will measure yourself, or is a convention of the method — and then we say so.
The sample: three months, two hundred cases
First decide what you are counting. The unit is a case: one thread or one ticket opened by a customer, together with all its correspondence. Not a single message — if you sampled messages, cases with a long email exchange would land in the sample more often than others. If the same matter appears in the export as two threads, count it once, as the thread it started with.
We suggest taking cases from three months across every written channel: email, the website form and chat. Such a period usually smooths out the swings of a single week — a promotion, an outage, holidays — although it does not replace comparing seasons if your industry has them. Let the window end at least as many days before the day you count as the return window described below (14 by default), because for the newest cases you cannot yet see whether the customer came back. If a first reply can take longer than that window at your company, move the end of the window back further — otherwise the newest cases will show up as unanswered only because they are recent. Before you draw the sample, write down how many cases there were in that window in total and in each channel — the sample shows shares, and only this number lets you convert them into cases per month (share × cases in the window ÷ 3). For a single channel, use the share among that channel’s cases and that channel’s case count. If the sample contains the “unknown” cases described below, give the conversion as a range: from the version in which none of them needed a system to the version in which all of them did — dividing by the whole sample in both versions. Draw two hundred cases at random from that set. Do not simply take the last two hundred, because that is often one week or one peak, not three months. In Excel it is enough to add a column with a random number (the RAND function), copy it and paste it back as values — because RAND draws again every time the sheet recalculates — then sort by it and take the first two hundred rows. If there were fewer than two hundred cases, describe all of them.
Why two hundred? It is a practical starting point, not a law of statistics. It lets you see which topics dominate, and gives tolerable precision for shares counted across the whole sample. With two hundred randomly chosen cases, a share of about one half is known to within roughly 7 percentage points either way, at the usual 95% confidence level (we give the formula in the sources). That precision covers only the random choice of the sample — it does not cover mistakes made while describing cases. The practical conclusion: a difference of a few points between two topics may be down to the random draw alone. Numbers for a single channel or a rare topic are less certain still, because fewer cases stand behind them. Those 7 points are a safe approximation for a window with many cases. If the two hundred cases are almost all the cases in the window, the sampling uncertainty is smaller, and when you describe all of them it disappears — only mistakes in the labelling remain.
How much work is it? Work it out yourself: if describing one case takes a minute or two, two hundred cases take three to seven hours, plus the time to check for returns. Ideally it is done by someone who answers customers every day, because only they know whether the answer required access to a system.
Phone calls have their own route and their own numbers — do not mix them into the written sample. How to pull the number of unanswered calls and their distribution by hour from your phone system is covered in our piece on what a voicebot costs (a voicebot is an automated system that holds telephone conversations), in the section “How to work this out for yourself”, and we do not repeat it here. Count separately only what that piece does not. Count the share of calls outside working hours from all incoming calls in the phone-system report, including unanswered ones — otherwise it would lose exactly the evening and weekend calls nobody picked up. For answered calls, record the topic and whether the customer called again about the same unresolved matter within 14 days (by the same rule as for repeat contacts below). Check returns after unanswered calls too: if the same number calls again within 14 days of an unanswered call, establish from voicemail, a note or the conversation whether it is the same matter. If it is, that is a repeat contact; if you cannot tell, record “unknown” and report such cases separately, because the same number may call about something else or belong to several people. Count the rate against cases, that is, first calls about a given matter, answered and unanswered, not against the number of phone numbers. You will find the numbers and times in the phone-system report or in the phone’s call history. An ordinary report does not give the topic, or whether a return concerns the same matter — if you do not record them anywhere during the call, then for two weeks note the time, the topic and whether the customer had already called about the matter for every answered call, and check for returns only once the full window has passed (we describe the rule and the return window in point 5). The report also does not say what the unanswered calls were about. You can only learn the topic from voicemail, a note in your system or when you call back, so for the same two weeks record it for every callback and every voicemail as well.
A ticket export is customers’ personal data. Draw and describe the sample in the tools your company already uses, and do not copy names, addresses, order numbers or message content into the sheet — the columns below do not need them. You recognise the customer in the mailbox or the ticketing system, and only the result goes into the sheet. If anyone from outside is to see the summary, including us, the numbers are enough. How we handle customer data, including what follows from the GDPR (the EU General Data Protection Regulation), is set out on our security and GDPR page.
Download the sheet template (CSV) with numbered rows and these columns:
| Column | What to enter |
|---|---|
| Channel | email, form or chat |
| Received | the date and time the case started |
| Topic | one topic from your list, or “other” when none fits; when a case holds several requests, the topic of the one that took the most work |
| What the answer needed | “knowledge”, “lookup” or “change”, or “unknown” for an unanswered case that cannot be judged; explained below |
| First reply | the date and time of the first substantive reply sent to the customer, excluding automatic acknowledgements; empty if nobody replied |
| Outside hours | “yes” if the case arrived outside customer service working hours, otherwise “no” |
| Repeat contact | “yes” if the customer came back about the same unresolved matter within 14 days, otherwise “no” |
| Reply type | “person”, “system and approval” or “automatic” — usually “person” before implementation; needed for the comparison after implementation |
| Notes | observations without customer data — no names, numbers or quotes from messages; note here if the customer chased before getting the first reply |
The file uses commas as the separator. If Excel shows everything in a single column, import the file and choose the comma as the separator. It contains no formulas: how to count each of the five numbers is described below. If you choose a return window other than 14 days, change the column header too.
Five numbers
1. How many cases required access to a system
In the customer service indicator lists we reviewed before writing this piece, this number did not appear, and in our view it says the most about which project makes sense. For each case, the person from customer service answers one question: what did the answer need? When more than one answer fits, pick the highest: “change” before “lookup”, “lookup” before “knowledge”. For cases nobody replied to, judge what the answer would have needed. If the request does not make that clear, enter “unknown”: such cases are left out of this share — you then divide by the number of sampled cases minus the “unknown” ones — and you report their number next to it.
- Knowledge — the answer follows from the company’s general knowledge: terms and conditions, price list, product description, opening hours. The same answer fits every customer who asks that question.
- Lookup — a fact about this particular customer had to be checked in a system: order status in the online shop, delivery date with the courier, balance in the accounting system, history in the CRM (the system for customer service and sales).
- Change — something had to be done in a system: issue a correction, accept a return, change a delivery address, cancel an order.
The number to record is the share of “lookup” and “change” together — these are the cases that need access to a system — and, separately, the share of “change” alone. This split is close to the test from our piece on how an AI agent differs from a chatbot. An AI agent is a system that does not only answer, but also carries out actions in your systems. The test is: what has to be done when the system makes a mistake? With “knowledge”, you correct the content of the answer. With “lookup”, the system needs access to the data but changes nothing in it. With “change”, a mistake has to be reversed in the system, which means permissions, a record of the actions taken, and human approval.
An important caveat: these labels say what access is needed, not whether the case may be handed to an automated system. That depends on whether the rules are clear, how often exceptions occur and what a mistake costs. A complaint may need only a “lookup” and still stay in human hands.
This number also translates into cost, though not directly. The work on connections to systems depends mainly on how many systems, and which ones, have to be connected, not on how many cases need a “lookup” or a “change” — for example, fifty lookups in the online shop are still one connection. The number of cases, in turn, affects running costs. The number and type of connections to systems is the first of the items we set out in our piece on what AI implementation costs.
2. The topic distribution
The service page says that we start by counting the topic distribution. Here is the rule for doing it. Before you start describing the sample, look through a few dozen cases from outside it and write down the topics, splitting them by how they are handled, plus one “other” topic. If fewer than a few dozen cases remain outside the sample — because there were two hundred, only slightly more, or fewer and you are describing all of them — first look through a few dozen cases from the sample itself (or all of them, if there are fewer) only to write down the topics, and then describe the whole sample, including the cases you looked through. We suggest eight to fifteen topics — a practical starting point, not a rule. With a very short list it is easy to merge cases that are handled differently. With a very long one, many topics get so few cases that little can be read about them from two hundred. In the end, what counts is whether the topics differ in how they are handled and how many cases each one got. Each case gets one topic. When a customer asks for several things in one thread, for example an order status and a change of address, choose the topic of the request that took the most work, and keep to that rule across the whole sample.
A control rule: if “other” is among the largest topics, look through it. If you see recurring cases handled the same way, split them out as separate topics and describe the sample again. If it really is many different, rare cases, keep “other” — that is a result too: a long tail of cases, none of which repeats.
The number to record is the combined share of the three largest named topics, without “other”. “Other” is a collection of different cases, not one topic, so it cannot be part of that top three — otherwise a large, scattered tail would look like a few repeatable matters. The denominator stays the whole sample, and you record the share of “other” separately, next to it. Together these two numbers show whether customer service is filled by a few repeatable matters or by many different ones, none of which dominates. In Excel, use the COUNTIF function to count the cases in each topic, add up the three largest results among the named topics and divide by the number of all cases in the sample.
3. The median time to first reply in each channel
Time to first reply is the time from when a case arrives to the first substantive reply sent to the customer. An automatic acknowledgement such as “we have received your message” does not count. Ticketing systems define it in a similar way — Zendesk, for example, measures the time from ticket creation to the first public agent reply and reports it both in calendar hours and in business hours.
We suggest counting in calendar hours, because that is how long the customer waits, and separately for each channel, because chat and email carry different expectations. Instead of the average, take the median, the middle value: a few cases from Friday evening that were answered on Monday can pull the average up so far that it no longer describes a typical case. In Excel, add a column with the difference “first reply minus received” multiplied by 24, because Excel subtracts dates in days — but only in rows that have a reply; where the reply is empty, leave that cell empty, because subtracting from an empty cell gives a false result. Then, for each channel, copy its times into a separate column and only use the MEDIAN function on that column.
Cases nobody replied to do not go into the median, but they must not disappear: count them separately and report them next to the median, because the median alone does not show cases left unanswered. Before implementation such replies are usually written by a person. After implementation the definition stays the same, and you record separately how the reply came about: written by a person, prepared by the system and approved by a consultant, or sent automatically. That way the before-and-after comparison measures the same thing, and the differences between the ways show up separately.
Without a ticketing system, on a shared mailbox, this is done by hand: for each sampled thread you read the time of the customer’s message and the time of the first reply sent from the mailbox. With two hundred threads it is tedious, but doable.
4. The share of cases outside working hours
First settle what your customer service working hours are — including weekends and public holidays. Then count what share of cases arrived outside them: separately in the written sample and separately for phone calls, where all incoming calls count, including unanswered ones. This number decides whether there is anything to discuss at all when someone says “after-hours service”.
If the phone system gives no report, or its report does not show the times of all incoming calls, including answered ones — for example when you take calls on mobile phones — then instead of a three-month export, log every call in a simple table for two weeks: time, topic, whether anything had to be checked in a system. Check for returns from those calls only once the full return window has passed since the last logged call. Keep that result separate and describe it as an estimate, because some after-hours calls will never be noticed at all.
5. The repeat contact rate
A repeat contact is when the same customer — recognised by address, phone number or order number — comes back about the same matter within 14 days of it starting, because it was not resolved. Not every return counts: if the customer sends back a document they were asked for, or gets in touch as agreed, that is the normal next step, not a repeat contact. You check this in the mailbox or the ticketing system, including messages from outside the sample. A customer may also come back through another channel, for example calling after an email — if you have a shared identifier, such as an order number or a phone number, check the other channel too; if not, note next to the result that such returns are not visible. The number to record is the share of sampled cases where the customer came back at least once — a case with three returns counts once.
Fourteen days is our own convention, not a standard. If cases in your industry naturally take longer, for example because a delivery is awaited, widen the window. What matters is that it stays fixed, because only then can the result be compared with a measurement after implementation.
This is where the distinction from the start comes back. A closed ticket is not a resolved case. If customers often write a second time, it may mean the answers are not solving their problem — or that the problem lies outside customer service, for example in late deliveries. Check the cause before you automate anything, because an automated system that answers faster will not remove the cause of the second contact.
What the arithmetic looks like in an example
The example below is invented to show the arithmetic. It is not any company’s result and not a reference point. Suppose that in a sample of two hundred cases, 46 were labelled “lookup” and 9 as “change”, and none as “unknown”. So 55 cases required access to a system, that is 55 ÷ 200 = 27.5%. With two hundred randomly chosen cases, such a result is known to within about 6 percentage points either way, so it lies roughly between 21% and 34%. “Change” alone is 9 ÷ 200 = 4.5%. Such a share settles nothing yet: check how many cases that is per month, how much work they take and what a mistake in handling them would cost. With numbers this small, the precision formula is also less reliable, so treat the result as a rough guide. The other shares are counted the same way. The median is one number per channel.
How to read the result: which number points to which project
None of the five numbers decides on its own, and no combination settles the project. The table gives hypotheses to check, not verdicts. It contains no numeric thresholds, because any threshold would be made up. Instead there are relative readings: whether something dominates or is marginal.
| What the sample shows | Where to start | What to check first |
|---|---|---|
| A few topics dominate and the answers are mostly “knowledge” | A knowledge base and replies prepared for approval by a consultant | Whether the answers in those topics are written down and up to date today |
| A few topics dominate, but a large part is “lookup” | Replies for approval in which the system reads facts from your systems without changing anything in them | Whether there is access to those systems and whether their data is up to date |
| A clear part of the cases is “change” | First a feature of your system or ordinary automation with a fixed list of steps; an AI agent project with granted permissions only when there are too many paths for fixed rules. In both cases a person approves every change at first | Whether these changes follow fixed steps, whether the rules are clear and what a mistake costs |
| Long median first reply, few repeat contacts | Recognising cases and routing them to the right person — if cases really do reach the wrong people | Whether tickets wait in the wrong queue, whether there are not enough people on the rota, or whether the case is waiting for an investigation, a supplier or an approval — then routing will not shorten anything |
| A clear part of the cases got no reply at all, even if the median looks good | First make sure every case reaches someone responsible for it — before you talk about faster replies | In which channel, mailbox or topic these cases get lost, and whether people are missing or the case is never assigned to a person |
| Many repeat contacts and a long median | If customers come back after the answer — first fix the answers and the knowledge base; if they chase before getting it — first the queue and case assignment; automation only after that | Whether customers come back after the answer, or chase before they get it — then the problem is the queue and case assignment, not the content of the answer; and whether it is a problem customer service cannot solve |
| A large share of cases outside working hours | An honest acknowledgement with a real reply time | Whether there are many unanswered calls and whether voicemail, notes or callbacks show they concern repeatable matters — only then does it make sense to talk about a voicebot |
| Few cases and many different topics, none of which dominates | No obvious candidate for now | How much work and risk these cases carry and whether different topics share a repeatable step; if not, it is not worth starting for now — repeat the sample in a quarter |
| Most answers need facts from a system without access or with out-of-date data | First put that system in order, and only then automate | Who is responsible for the data in that system and whether it can be connected to |
The first row is the variant in which the customer still gets the answer from a person, and the system only prepares it. With the third row, it is worth going back to the test from the piece on the AI agent and the chatbot before anyone prices the project. The row on cases outside working hours follows the same rules we set out for voicebot implementation: the automated system says it is automated, and says when a person will get back to the customer.
The last two rows are as important a result as the others. They match the conditions we gathered on our what we don’t do page, and what our implementation methodology calls the moment we say it is not worth it. The difference is that here you establish it yourself, on your own data, after a few hours of work.
What to do with the result
Five numbers are a starting point for a conversation about a specific process, not a ready project. If they suggest a first step, the next ones — from naming the number that is supposed to change to a pilot run alongside the existing work — are covered in our piece on how to implement AI in a company. More broadly, which processes in a company are suitable for automation at all is the subject of our AI automation page.
Keep the sheet, too, as a reference point. After implementation, draw a new, comparable sample and describe it in the same columns, with the same chosen return window. Draw it from the same entry point as before — all messages and forms, including those the system dealt with before they became a ticket (take these from its log). Otherwise only the harder cases remain in the sample and the comparison looks worse than it is. Without that comparison, every later conversation about results rests on impressions.
Sources, as at 12 October 2026
- Piotr Wolniewicz, “Automatyzacja obsługi klienta bez ściemy: ile zgłoszeń przejmie AI i ile to naprawdę kosztuje”, AIPORT.pl (Polish) — article of 8 August 2026; we use only its distinction between conversations no human handled and cases that were resolved, without the percentages and thresholds given there; accessed 12 October 2026.
- NIST/SEMATECH e-Handbook of Statistical Methods, 7.2.4.1 “Confidence intervals” — approximate confidence interval for a share in a random sample: result ± 1.96 × √(p × (1 − p) ÷ n), which NIST cites as the expression most frequently used. For p = 0.5 and n = 200 this gives about ±7 percentage points, and for p = 0.275 about ±6. The same section recommends the more accurate Wilson method; with these numbers it gives practically the same result: about ±7 points at one half and roughly 22–34% in the example. For very small shares the difference between the methods grows; accessed 12 October 2026.
- Zendesk — “Understanding ticket reply time” — definition of first reply time in calendar hours and in business hours; accessed 12 October 2026.
- Microsoft — the RAND function, the MEDIAN function and the COUNTIF function in Excel; accessed 12 October 2026.