AI agents in customer service: the value lies in separating querying, responding and acting, and in handing off well to a human

By IEBS Business School · November 8, 2026.

IEBS Business School has published a practical guide to deploying AI agents in customer service. Its starting point is a concrete case: a customer writes for the third time because the carrier shows the order as delivered and they haven't received it. The agent checks the tracking and replies "your order has been delivered." According to the article, it found the right data and answered the wrong question.

The guide's thesis is that in support, permission to look up information, permission to respond and permission to carry out an action are separate decisions. Separating them makes it possible to automate the common cases while keeping a clear way out when the procedure fails.

The text suggests starting with a queue of known, verifiable queries. Even "order status" hides three intents: finding out the expected delivery date, correcting an address or filing a claim for a shipment marked as delivered. For each, the guide details what the agent can do and when a person should step in. For example, for a return it can generate the label if the system confirms the requirements are met, but it must escalate if there are discrepancies over deadlines or the condition of the product. For a duplicate charge it can open a ticket without asking for full card details, but it cannot decide on an exceptional refund or handle signs of fraud.

There is a valuable technical detail. For an action with consequences, such as issuing a label or changing a booking, the agent must require confirmation from the target system. If the call times out after being sent, it doesn't know whether the operation went through, and retrying without checking could duplicate the transaction. The message to the customer must distinguish "I've received your request" from "the operation is confirmed."

On the evidence, the guide cites a study of 5,172 support professionals in which an AI assistant increased issues resolved per hour by 15%. It rightly points out that the tool suggested responses to people who were still handling the cases: this supports trialing assistance for the team first, but does not show that an autonomous service resolves issues better. It recommends a rollout in which the agent prepares the summary and finds the applicable policy, and the person responds.

On metrics, it proposes measuring resolution without repeat contact within a time frame suited to the issue, distinguishing abandonment from resolution (closing the window doesn't prove the customer is satisfied) and calculating the cost per resolved case by adding up the system, supervision, transfers and rework. It advises reviewing the highest-impact errors separately, such as duplicate refunds or data shown to the wrong customer, because a good average can hide a class of incidents that forces a permission to be revoked.

Our take: the guide gets the key point right—the bottleneck for agentic AI in customer service is not model capability but process design. The package example is the canonical failure of a system that optimizes for "answering" instead of "resolving." An agent that responds quickly and wrongly is worse than a slow one, because it turns a logistics issue into a second complaint about the service.

This approach ties in with an idea we advocate in agentic security: the risk lies in how permissions are governed, not in the model in isolation. Separating reading, responding and acting is essentially the same principle of least privilege applied in cybersecurity, carried over to customer experience. And the emphasis on idempotency (not repeating an action without checking its status) is basic distributed systems engineering that many agent pilots overlook.

The article should also be read with a critical eye. IEBS is a business school that sells training on these topics, and the piece ends with a course offer; it is a best-practices guide, not a study with its own data. Its recommendations are sensible, but it provides no figures from real deployments, and the only quantitative data comes from an external study on assistance, not autonomy.

Impact on jobs, honestly. In the short term, customer service is one of the most exposed sectors: routine queries will be automated and there will be fewer frontline jobs. But the guide points to a pattern we believe will prevail: the agent takes on the repetitive work and the person handles what requires investigation, deciding on exceptions and dealing with frustrated customers. In other words, less mechanical work and greater weight on judgment. The transition will be uneven and will require reskilling, but the outlook—faster services and people focused on cases where they add value—is reasonable.

Overall, the guide's criterion for scaling up a pilot—granting autonomy one action at a time and moving forward only when the customer leaves with a verifiable answer or with someone taking ownership—is a good antidote to the hype around the "agent that does everything." Months from now, when agents are more capable, it will still hold: what will change is which permissions can be safely granted, not the need to grant them gradually.