AI implementation Guide
AI in customer service: where it helps and where it hurts
AI in customer service brings to mind a bot that does not understand the question. Yet it delivers the most where the client never sees it. I describe six use cases, the conditions without which they will not work, and the situations where a person makes the call.
When I talk about AI in customer service, most people picture a chat window on a website that answers in generalities and will not let you reach a human. Such implementations exist and are rightly irritating. Yet the biggest benefit of AI in customer service is usually where the client never sees it - on the side of the team, which replies faster and more specifically.
For each use case I give a risk level based on the split from the article on checking AI answers: green is working material, yellow is client-facing content read by a person, red is numbers, deadlines and commitments checked against the source.
1. A knowledge base for the team
Risk: green
An employee asks the tool about a procedure, warranty terms or return rules, and the tool answers from company documents and shows where the answer came from.
Condition: up-to-date documents in one place. If the terms and conditions exist in three versions, the tool will quote each of them. Tidying up documents is half the work here - and it pays off even without AI.
2. Summarising the client’s history before replying
Risk: green
Before an employee replies, they get a short summary: what the client asked about before, what they were promised, what is still open.
Condition: contact history recorded in one system, not in individual people’s inboxes.
3. Drafting a reply to a request
Risk: yellow
The tool prepares a first version of the reply based on the request, the knowledge base and examples of good replies. The employee reads it, corrects it and sends it.
Condition: a dozen or several dozen good past replies as a model for tone, and rules on what replies must not promise.
What to measure: time to the first substantive reply and the number of corrections to the draft.
4. Sorting and assigning requests
Risk: yellow
Incoming messages are described - what they are about, how urgent they are - and routed to the right person.
Condition: written request categories and rules on who handles what. If today everyone assigns requests “by feel”, the rules have to be agreed first and only then automated.
5. Spotting recurring problems
Risk: green
Once a month the tool reviews requests and lists the topics that come back most often. That is information for the company: which questions are worth explaining on the website, in the instructions or in the product itself.
Condition: an export of requests without personal data, or a business version of the tool that covers this in its contract.
6. A bot that answers clients
Risk: red, if it answers about deadlines, prices and terms
This is the use case companies most often want to start with, and the one that should come last.
Conditions:
- an organised, up-to-date base of answers - the bot knows no more than the documents it works from,
- a limited scope - the bot answers specific kinds of questions and passes the rest on,
- an easy, visible way to reach a person,
- a test on real client questions before launch,
- regular review of conversations after launch.
Clients should also know they are talking to a bot. It is fair to the client, and the AI Act sets out transparency obligations for systems that interact with people.
What not to hand over to a bot
However good the tool, a few matters stay with a person:
- complaints and conflict situations - at least the first reply,
- decisions about refunds, discounts and exceptions to the rules,
- clients in a difficult situation - health, financial or personal,
- matters where a mistake has legal consequences.
In these cases the tool can prepare a draft or gather the history. The decision and the reply are signed off by a person.
What to measure
- time to the first substantive reply,
- the number of repeat contacts about the same issue,
- the number of corrections to drafts,
- with a bot - how often a conversation ends with a handover to a person, and what it was about.
I write more about measuring the starting point and the result in the article on measuring the effect of an AI implementation.
Where to start
If I had to point to a first step, it would be the knowledge base for the team or the client history summary. Low risk, a benefit you see straight away, and along the way the documents get tidied up, which helps every later use case. A bot for clients makes sense only once these foundations work.
I build a chosen use case and test it on real requests as part of AI implementation.
Read next