How much of your customer service can AI automate? Start with the requests it can resolve correctly, with the data and permissions available, without work you still need a person to do.
That is a different number from the share of tickets where AI can draft an answer. It is also different from the share customers already resolve through self-service.
Our recommendation is to build your target from your own ticket mix, then test it. Here is a practical way to do that, including a hypothetical example you can replace with your own figures.
Define what counts before choosing a percentage
Pick one channel, one reporting period, and one unit of work. For example: email tickets opened during a calendar month, counted once per customer issue. Keep the definition consistent when a conversation moves between channels.
Separate these outcomes:
- Automated resolution: the issue is resolved without an agent reviewing, editing, sending, or completing the work. Define how you check correctness and how long you watch for reopening or repeat contact.
- AI-assisted handling: AI does part of the work, but a person reviews the answer or finishes the case. Measure the time saved separately.
- Self-service: the customer completes a task through an existing portal, help center, or workflow. Do not relabel existing self-service as new AI resolution.
A draft approved without edits is useful evidence about draft quality. It is not an unassisted resolution. Nor does the absence of an immediate reply prove the customer got the right answer.
For help distinguishing operating models, see the four levels of customer service automation.
Build the target from your ticket mix
Take a representative sample of recent tickets and group them by customer intent. Include difficult and reopened cases, not just the requests that are easiest to demonstrate. Estimate each group's share of the full channel volume, then make four decisions.
| Decision | What to record | How to use it |
|---|---|---|
| Current baseline | Today's resolved volume, human handling time, and quality for each intent | Separate existing automation from potential gains |
| Candidate scope | Required knowledge, system access, actions, and unresolved dependencies | Include only cases the proposed setup can support |
| Human-only scope | Cases kept with people for risk, complexity, or service reasons | Exclude them from the initial automation scope |
| Required economics | Baseline cost, added operating costs, and the improvement needed | Decide whether the opportunity is worth testing |
Different answers to the same question do not automatically make a case unsuitable. A return policy might legitimately depend on the product, purchase date, or country. The requirement is to retrieve the right context, select the applicable rule, and keep that rule current. Flattening valid differences into one answer can make service worse.
Check technical capability as well as data availability. Can the system authenticate the customer, retrieve the right record, complete the permitted action, and hand over when it cannot? A documented policy alone does not answer those questions.
Also leave room for deliberate service choices. You might keep a sensitive complaint or a high-value sales conversation with a person even if some steps can be assisted.
Calculate coverage and resolution separately
Hypothetical planning example, not a customer result or benchmark: imagine a support team with 12,000 email tickets per month and no existing automated resolution in that channel.
Its ticket review identifies 4,800 candidate tickets, or 40% of monthly volume. The team models what would happen if the AI correctly resolved 75% of those candidates without human work.
- Candidate scope: 4,800 tickets.
- Assumed automated resolutions: 4,800 × 75% = 3,600 tickets.
- Assumed automated share of the full channel: 3,600 ÷ 12,000 = 30%.
- Tickets still requiring human handling: 8,400, including 1,200 candidates that need handover.
The model's 75% within-scope rate is not a 75% overall automation rate. Both figures are assumptions until a pilot measures them using the agreed resolution definition.
If you already automate some requests, calculate the incremental gain against that baseline. Do not count the same resolved ticket twice because it touched both a bot and another self-service tool.
Check whether the economics work
Continue the same hypothetical example. Assume a baseline human handling cost of €6 per ticket and unchanged quality and volume.
- Baseline monthly cost: 12,000 × €6 = €72,000.
- Remaining human handling: 8,400 × €6 = €50,400.
- Assumed added monthly AI, monitoring, and maintenance costs: €8,000.
- Modeled operating cost: €58,400, or about €4.87 per ticket.
- Modeled difference: €13,600 per month, before one-time implementation costs.
These are invented planning inputs, not Typewise pricing or a savings promise. The example assumes that remaining tickets cost the same to handle and that the avoided handling cost is actually recoverable. In practice, escalated cases may take longer, staffing costs may stay fixed, and saved time may create capacity rather than cash savings.
Replace the inputs with measured review, rework, handover, integration, and operating costs. Include setup costs over your chosen evaluation horizon. Our guide to calculating your real cost per ticket helps establish the baseline.
Turn the estimate into a pilot decision
Your output should be a scoped hypothesis: which requests, in which channel, with what required quality, and what cost improvement would justify expansion.
Test the candidate scope before treating it as a target you can deliver. Measure correct resolution, repeat contact, handover quality, and customer experience alongside volume and time saved. Reduce or change the scope when the evidence calls for it.
Once that hypothesis is clear, the next step is agreeing how your support team will go live with an AI agent, including approval coverage and the criteria for expanding beyond a supervised pilot.
