Published · Updated
Customer-service leaders considering AI need to know how much work it can take off their team's hands, and what that would change in costs and capacity. The answer depends on which requests the AI is equipped and permitted to handle, and how often it resolves those requests without a person completing the work. Estimating both gives you an automation target and a business case you can test in a pilot.
Establish today's workload and cost
Start with the work your team handles today. Count customer cases over a representative period, grouped by use case, channel and language. Several messages about the same unresolved issue belong to one case, including when the customer changes channels. Include difficult and reopened cases so the baseline reflects the service you actually provide.
Measure average handling time (AHT) and fully loaded hourly labor cost for each group. Handling time includes the work needed to finish the case, not just writing the first reply. Fully loaded cost means the employer's labor cost, rather than the employee's take-home pay. Keep material existing software and operating costs visible alongside it.
The baseline also needs a service standard. For an order-status inquiry, that might mean giving the correct current status and a usable next step. For an approved cancellation, it includes confirming that the cancellation happened. Record repeat contacts, missed service deadlines and customer satisfaction (CSAT) where available, so a lower handling cost cannot hide worse service.
Use this planning table to collect the inputs before choosing a target.
| Planning input | What to record | How it helps |
|---|---|---|
| Current workload | Cases per month by use case, channel and language; link repeat contacts about the same issue | Establish comparable demand without counting messages as separate problems |
| Human effort and cost | AHT, fully loaded hourly labor cost and material existing operating costs | Derive the baseline cost from measured work |
| Service outcomes | Correct completion, repeat contacts or reopenings, service deadlines and CSAT where available | Define acceptable service for each use case |
| AI scope | Use cases, share of demand, required knowledge, integrations, permitted actions and exceptions | Identify both coverage and implementation requirements |
| Human-only scope | Requests kept with people and the reason for each exclusion | Make the work outside AI scope explicit |
| Expected AI outcomes | Fully resolved, partially resolved and not resolved by AI; remaining human minutes for each path | Estimate how much work remains |
| New costs and capacity | AI pricing basis, setup and integration, monitoring and maintenance; remaining workload and spending that can actually fall | Compare total costs and separate freed capacity from cash savings |
Choose the use cases the AI should handle
A use case belongs in the proposed scope only when the setup can support the required work. Check whether the AI can retrieve the right knowledge, identify the customer, access the relevant record and complete the permitted action. It also needs a route to a person when those conditions are not met.
Different answers to the same question do not automatically make a use case unsuitable. A return policy might depend on the product, purchase date or country. The requirement is to select the applicable rule and keep it current. A single generic answer would lose information the customer needs.
Some requests may stay with people by choice, such as sensitive complaints or high-value sales conversations. Existing portals may remain part of the workflow or baseline. Count only the additional work AI removes; a request already completed through self-service is not a new AI gain.
For cases that enter AI handling, distinguish three outcomes: AI finishes the required service work, AI completes a useful part and a person finishes the rest, or AI does not resolve the request. A human-approved draft belongs in human-assisted work, even when the reviewer makes no edits. Silence alone does not establish success; agree what evidence will count as a resolved customer case.
Calculate coverage and resolution separately
Consider a hypothetical support team with 12,000 cases a month and no existing automated resolution in that workload. Its review identifies 4,800 cases that the proposed AI setup could handle. Assume all 4,800 enter AI handling and the AI fully resolves 3,600 of them.
These are planning assumptions, not measured results or an industry benchmark:
- Coverage: 4,800 AI-scope cases ÷ 12,000 total cases = 40%.
- Full AI resolution within that scope: 3,600 fully resolved cases ÷ 4,800 AI-scope cases = 75%.
- Overall AI-resolved share: 3,600 fully resolved cases ÷ 12,000 total cases = 30%.
Coverage and resolution answer different questions. The 40% says how much demand the setup covers. The 75% says how often it finishes that covered work. Together, 40% × 75% gives 30% of all demand fully resolved by AI. If a pilot routes only some eligible cases to AI, report actual AI entry separately from planned coverage.
The other 8,400 cases still need people: 7,200 go directly to the team and 1,200 need human work after entering AI handling. Some of those 1,200 may be partly completed already. Measure the remaining effort rather than assuming every handoff takes the same time.
Compare the cost and capacity before and after AI
Continue the same hypothetical example. Assume nine minutes of human handling per case and a fully loaded labor cost of €40 per hour. That gives a baseline handling cost of 9 ÷ 60 × €40 = €6 per case.
For this simplified model, assume an AI charge of €2 for each billed full resolution, with all 3,600 counted full resolutions billed on that basis. This is an invented pricing input, not Typewise pricing. Actual contracts may define billable resolutions differently from your service-quality measure.
| Item | Calculation | Monthly result |
|---|---|---|
| Baseline human handling | 12,000 cases × €6 | €72,000 |
| AI resolution charges | 3,600 full resolutions × assumed €2 | €7,200 |
| Remaining human handling | 8,400 cases × assumed unchanged €6 | €50,400 |
| Human handling plus AI charges | €50,400 + €7,200 | €57,600 |
| Difference before other incremental costs | €72,000 − €57,600 | €14,400, or 20% |
The €57,600 is not the complete cost of running AI. Add integration and setup over your evaluation period, plus ongoing monitoring, maintenance and any other incremental costs. They are excluded from this table, not silently included in the €2 charge. Account for any changes to existing operating costs too.
The table also assumes unchanged human handling time for every remaining case. A useful partial resolution may shorten that work; a failed interaction may add explanation or rework. Replace the assumption with measured time for each path during the pilot.
At the assumed nine minutes per case, 3,600 full resolutions release 540 hours of handling capacity a month: 3,600 × 9 ÷ 60. That does not automatically reduce payroll. The capacity might absorb growth, reduce a backlog or avoid future hiring. Whether cash spending falls depends on staffing decisions and costs you can actually remove. The €14,400 is a modeled workload-cost difference before the other costs and effort adjustments, not a savings promise.
Our guide to building a defensible AI business case explains how to reconcile measured workload, costs and capacity.
Test the assumptions in a pilot
The estimate should tell you which requests are worth testing and what would make the result worthwhile. Pick a bounded scope, confirm the knowledge and integrations it needs, and record the expected resolution rate, residual human effort and full operating cost.
During the pilot, check correct completion, repeat contacts, handoffs, service delays and CSAT alongside time and cost. Compare similar case groups and account for who responds to satisfaction surveys. A fast answer or a high satisfaction score alone cannot prove that the work was finished correctly.
Use the evidence to expand, revise or reject the proposed scope. The next step is planning how the team will go live, with supervision and permissions matched to each rollout stage.
