Article · Agents by Business Function
AI customer service agents: from answering to resolving the case
The question that brings a head of operations to this topic is almost never “should I add a chatbot?”. They already had one, and it is still buried on the website answering with links to a help page. The real question is different: if a customer writes “where is my order and why hasn’t it arrived?”, can the system look up the order, understand what happened, and do something about it, or can it only return a polite sentence? That is the line between a chatbot and an agent in customer service, and it is a difference of verb, not of tone.
A chatbot converses: it interprets what it is told and replies with text. An agent operates: it queries the order in the management system, checks the carrier status, processes the exchange, opens the incident, and confirms to the customer what it did. The first one takes work off a person’s plate only until the case needs to touch a system. From there it hands off. The second one closes the case. I set out the general frame for this answer-versus-execute distinction in AI agents for business.
What an agent resolves and what stays a conversation
Not all of a service desk’s volume is fit to delegate to an agent, and conflating the two is the first mistake. The good territory is the repetitive case, with known rules and data you can verify in a system:
| Case type | What the agent does |
|---|---|
| Order status | Looks up the order and carrier tracking, and replies with the real situation and estimated date |
| Exchange or return | Checks windows and terms, generates the label or pickup order, and updates the order |
| Delivery incident | Logs and classifies the incident, triggers the internal process, and tells the customer the next steps |
| Data change | Updates an address or contact detail within the rules and confirms the change |
| Billing query | Locates the invoice, explains a charge, and prepares a credit note for approval when it applies |
What stays out matters as much as what comes in. A complaint full of nuance, an angry customer threatening to leave, an exception no rule anticipates: that is not patterned work, it is judgment work. And there the agent should not improvise a decision. It should recognize that the case is beyond it and pass it to a person. I cover the internal mechanics of how an agent executes this kind of work in the AI agents in operations hub.
Escalation is designed, not improvised
The heart of a good agent-run service is not what the agent resolves on its own, but how it hands over what it does not. A badly designed escalation turns the customer into a courier: it asks them to repeat the order number, to explain the problem again, to start from scratch with a human who knows nothing about the earlier conversation. That is worse than having no agent.
Escalation that works passes the case with all its context: what the customer asked, what the agent checked, which rules apply, why it stopped. The person receives a file, not an alarm. This boundary between the automated and the human is a business decision before it is a technical one, and I treat it as such in AI agent permissions and controls and, when the question is how much supervision to keep, in AI agent governance.
The rule I apply when drawing that boundary is simple. The agent resolves where the cost of a mistake is bounded and recoverable, and escalates where it is not. It can process an in-window exchange with no risk, but it should not decide on a complaint that could end in a cancelled contract. The line is drawn by blast radius, not by what the model is “able” to reply.
Measure by resolution, not by deflection
Here is the vice that sinks these projects. The metric inherited from the chatbot era is deflection: what percentage of contacts never reached a human agent. It is a convenient, misleading number, because it rewards hiding the problem. A system that answers “thanks for your message, check our help page” deflects 100% and resolves nothing. The customer gives up, moves to another channel, or leaves altogether, and deflection looks great in the report.
The real metric is resolution: of the cases the agent accepted, how many were closed correctly without the customer having to come back. That forces you to measure three things together:
- Real resolution rate: cases closed correctly over cases accepted, checked against reopens and second contacts.
- Escalation quality: when the agent hands off, does the case arrive with context and in the right queue, or does the human start from zero?
- Operational errors: actions executed wrong (a credit note that should not have issued, an out-of-window change), counted separately because their cost is different.
Without systematic evaluation there is no serious way to say the service works. There is only a feeling. I explain how that measurement is built for agents in production in AI agent evaluation, and why a trace of every action is non-negotiable in AI agent observability.
The reputational risk of getting it wrong
Customer service is the one process on this list where the agent’s failure is seen by the customer live. In an invoice reconciliation, an error stays in-house until someone corrects it. Here, an agent that promises a refund that does not apply, gives a false delivery date, or closes an incident without resolving it, leaves the customer worse off and with the sense that the company answered them with a machine that neither understands nor takes responsibility.
That is why a customer-service deployment does not start with volume, it starts with the perimeter. First, case types where the agent only proposes and a person confirms. Then bounded, reversible actions with review. And only with accumulated evidence does autonomy widen.
The temptation to switch everything on day one to show coverage is the fast lane to a reputational incident. I have watched that pattern repeat in pilots that collapse right as they move to production, and I analyze it in why enterprise AI pilots fail.
One point I insist boards hear clearly: automating customer service well is not about firing the support team. It is about taking the repetitive work that burns them out (the “where is my order?” for the hundredth time) so their judgment goes to the cases that deserve it. The agent raises the floor on the repetitive. The person raises the ceiling on the hard. If the project is framed only as headcount cutting, it gets designed badly and measured worse.
How I tell a real service from a demo
When I assess a customer-service proposal with agents, I ask the same questions. Show it resolving a case against our real orders, not sample data. Which exact actions can it execute in our systems and which can it only propose? What happens with the case it cannot resolve, who does it reach and with how much context? How is resolution measured rather than deflection? Where is every action logged and how do we review it?
If the provider can only show a fluent conversation over a toy catalogue, they have a well-built chatbot, which is no small thing, but not an agent that operates. The conversation is the easy part. Resolving the case by touching real systems, with rules, escalation and a trace, is the actual work.
Frequently Asked Questions
How does an AI agent differ from a chatbot in customer service?
The chatbot converses: it interprets the question and replies with text or links. The agent operates: it queries the order in your systems, executes the change or return, opens the incident, and confirms the result. One offloads the conversation. The other closes the case. The difference shows the moment the customer needs something to change, not just to be answered.
Which case types should go to the agent and which should not?
To the agent, cases with a pattern and verifiable data: order status, in-rule changes and returns, typified incidents, data updates. To the person, whatever needs judgment or carries high, irreversible cost: complex complaints, customers at risk of churning, unforeseen exceptions. The line is set by blast radius, not by what the model can reply.
How do I measure whether the customer-service agent actually works?
By resolution, not deflection. Measure what share of the cases it accepted were closed without the customer coming back, the quality of escalation when it hands off, and operational errors separately. Deflection rewards hiding the problem. Resolution measures whether the customer was actually served.
What happens if the agent gets it wrong in front of the customer?
That is this process’s characteristic risk, because the failure is visible and hits the relationship. You govern it with a narrow perimeter at first: propose-with-human-confirmation, bounded and reversible actions, and autonomy widened only with evidence. An agent with broad write permission and none of that discipline can damage reputation faster than it saves.