AI agents in customer service: what they handle, what they hand over

What you actually expect from a customer service agent

An AI agent in customer service is not meant to replace your team. Its job is to answer correctly, straight away, the requests that have a clear answer, and to hand over the others cleanly. When it is well designed, customers get an answer at any hour on simple questions, and your advisers receive files that are already qualified instead of asking the same questions again.

When it is badly designed, the opposite happens. The customer goes round in circles with a bot that does not understand, or worse, gets a wrong answer delivered with confidence. They end up calling, annoyed, and the adviser has to start from scratch. The agent added a step instead of removing one.

The difference between these two scenarios rarely comes down to the language model chosen. It comes down to a few design decisions: what the agent may handle, where its answers come from, how it hands over, what it says about itself, and how its work is measured. That is what this article covers.

Drawing the scope: three zones

Before writing a single instruction, classify the requests your customer service actually receives. Start from recent tickets, emails and calls, not from what you imagine. Then put each type of request into one of three zones.

• What the agent handles alone. Questions whose answer is stable and documented: opening hours, terms and conditions, how a service works, the steps of a procedure, order tracking read from your system. The agent answers, and the conversation ends there if the customer is satisfied.
• What the agent prepares. Requests that need a human decision but can be prepared upstream: a complaint, a refund request, a contract change. The agent collects the necessary information, checks what can be checked and creates a complete file for an adviser.
• What the agent hands over immediately. Anything sensitive or out of bounds: a customer in distress, a threat, a legal or medical question, a situation unlike anything known. The agent attempts nothing and hands over.

This classification is a business decision, taken with the head of customer service. It will evolve: you often start with a narrow "handles alone" zone, then widen it as results justify. Write it down, because it then serves to design the agent, test it and explain its role to the teams.

The knowledge base, the single source of answers

An agent should only answer from what you give it. Its general knowledge of the world helps it understand the question, not answer it. The knowledge base is therefore the foundation of the project, and it is often where most of the work lies.

In most companies, the information exists but is scattered: an FAQ on the website, internal procedures, reply templates in the ticketing tool, terms and conditions in PDF, and a lot of know-how in experienced advisers' heads. It has to be gathered, de-duplicated and its contradictions settled. Two documents saying two different things about the cancellation period will produce an agent that says one or the other at random.

A few simple rules make this base usable:

• One owner per topic, who approves the content and updates it when a rule changes.
• A visible update date on each entry, to spot what has aged.
• Short, focused entries, rather than long documents the agent has to search through.
• A distinction between public information and internal instructions: the agent can rely on an internal procedure without quoting it to the customer.

The agent retrieves the relevant passages from this base and builds its answer from them. If nothing matches, it must say so and offer a handover rather than improvise. This caution instruction is one of the most important, and it is verified through tests.

Unanswered questions have value too. Every time the agent hands over for lack of information, the question is logged. Reviewed every week by the topic owner, these questions show what is missing from the base, what is poorly worded, and sometimes a shift in what your customers expect. This is the loop that improves the agent without touching the model.

Data that commits you is never produced by the model

Some information commits your company: a price, availability, a delivery date, a refund amount, a case reference, an address. If the agent gets one of them wrong, the customer may be entitled to rely on it, or at the very least will feel misled.

Our rule is strict: this data is read or calculated server-side in your systems, then inserted into the answer. The model does not invent it, recalculate it or rephrase it. In practice, when a customer asks where their order is, the agent calls a function that queries your order system and returns the exact status. The model writes the sentence around it, the data comes from the system.

This architecture has a useful consequence: if the system does not respond, the agent cannot give information, and it says so. That is better than a plausible but wrong answer. We developed this point in why an AI agent must never quote a price.

The same logic applies to actions. If the agent can change a delivery address or cancel an order, those actions go through controlled functions, with checks on the customer's identity and business rules, and they are logged. The model requests the action, your system decides whether it is allowed.

Handing over to a person, with context

The handover is where most agents fail. The customer explains everything to the agent, then has to repeat it all to the adviser. They have lost time and they let you know.

A good handover rests on three things:

• Clear triggers. The agent hands over when the request is out of scope, when it finds no answer in the base, when the customer explicitly asks, when the tone shows strong dissatisfaction, or after several exchanges without progress. These rules are written down and tested.
• A file sent with the request. The adviser receives a summary of the situation, the information already collected (verified identity, order number, problem description), what the agent has already said and the reason for the transfer. They pick up where the agent stopped.
• A promise you can keep. The agent says what will happen next: immediate transfer to an available adviser, or a call back during opening hours. It never announces a timeframe your team cannot guarantee.

On the tooling side, the file must land where your advisers already work: your ticketing software, your CRM, your internal messaging. An agent that forces the team to check one more interface will be bypassed.

Being transparent with the customer

Customers must know they are talking to an AI. It is a matter of trust, and it is also an obligation. The European Commission states that the AI Act introduces specific disclosure obligations, and that when using AI systems such as chatbots, people should be made aware that they are interacting with a machine. It specifies that the Act's transparency rules come into effect in August 2026. For the detail of what applies to your company, see our article on the AI Act for SMBs, and have your case checked by your legal adviser.

In practice, transparency comes down to a few simple choices:

• the agent introduces itself as an automated assistant from the first message, without a human first name that could mislead;
• the customer can ask for a person at any time, and that request is honoured;
• the agent says when it does not know, rather than giving an approximate answer;
• the privacy policy explains which conversation data is kept and what it is used for.

On that last point, conversations contain personal data, sometimes sensitive. Limit what is kept, choose suitable hosting and document the processing. Our approach is set out on the responsible AI page, and the security side, in particular attempts to hijack the agent with instructions slipped into a message, falls under the work described on the AI security and compliance page.

Measuring what matters

A customer service agent is steered with metrics chosen before launch. The most tempting one, the rate of conversations "resolved" without a person, is also the most misleading: a customer who gives up out of weariness counts as a finished conversation. We track a set of metrics instead:

• Confirmed resolution: the customer says their question was answered, or does not contact the service again on the same topic within a period you define.
• Handover quality: advisers rate whether the file received was complete and the transfer justified.
• Wrong answers: a sample of conversations is reviewed regularly by the team, and each error is classified (incomplete base, instruction not followed, out-of-scope question not detected).
• Satisfaction, measured the same way for the agent and for advisers, so they can be compared.
• Cost per conversation, tracked over time. We break down the items in what an AI agent costs in production.

Before going live, build a set of real questions with expected answers, including trick and out-of-scope questions. Every change to the base or the instructions is validated against this set before release. It is the only way to stop an improvement on one topic from quietly degrading another.

Common mistakes

• Starting with the model. The choice of model matters less than the quality of the knowledge base and the scope. An excellent model on a contradictory base gives contradictory answers.
• Trying to handle everything from day one. A wide scope at launch multiplies visible errors and erodes the trust of customers and teams alike.
• Hiding the way to a person. A customer who cannot find how to reach someone will do it anyway, through another channel, more annoyed.
• Letting the model phrase commitments. Prices, timeframes and amounts come from the system, always.
• Forgetting maintenance. A knowledge base ages as soon as your offers or rules change. Without an owner, the agent becomes wrong without anyone noticing.
• Building without the advisers. They know the real questions, how customers phrase them and the edge cases. They are also the first users of the files handed over.

How a rollout unfolds

We take these projects to production quickly, but on a narrow scope and under close watch:

• Analysis of real requests with the customer service team, and classification into the three zones.
• Building the knowledge base for first-zone topics, with one owner per topic.
• Connecting to systems for data that commits you: orders, contracts, availability.
• Designing the handover to the advisers' tool, with the format of the file sent.
• Testing against the question set, then opening to part of the traffic or a specific channel.
• Regular conversation reviews and gradual widening of the scope.

The full method is described on the AI agent page, and our guidelines for deploying an AI agent in your company apply to customer service as to other uses. The technical work is carried by a profile we present on the AI engineer page, working directly with your advisers.

Taking stock of your customer service

A customer service AI agent succeeds when it knows exactly what it handles, relies on an up-to-date knowledge base, never produces committing data itself, and hands over with a complete file. If you want to know what share of your requests can be handled this way, and what needs preparing first, start with our AI diagnostic: we start from your real requests to draw a realistic scope.

Sources

• European Commission: AI Act, regulatory framework (transparency risk)

Frequently asked questions

Can an AI agent work across all our channels: website, email, messaging?

Yes, the same knowledge base and rules can serve several channels. We still recommend starting with one, often the website chat, to adjust the scope before extending. Phone requires an extra voice layer and specific tests.

What happens at night, when no adviser is available?

The agent handles what falls within its scope and, for the rest, creates a complete file to be picked up at opening. It clearly tells the customer when they will be contacted, without promising a timeframe the team cannot keep. Genuine emergencies need a dedicated channel, which the agent points to.

Should we connect the agent to our CRM from the start?

Not necessarily for general questions. But as soon as it must give customer-specific information (order, contract, case), read access is needed. Write access, to take actions, comes later and under strict control.

How do we stop a malicious customer from manipulating the agent?

By limiting what it can do rather than hoping it resists everything. Actions go through functions that check identity and business rules, and the agent only accesses the authenticated customer's data. Hijacking tests are part of the question set before every release.

Will our advisers lose their jobs?

That is not the goal of this kind of project. Advisers take back the requests that need judgement, with better-prepared files. Their expertise also becomes essential to maintain the knowledge base and review conversations.