Customer support agent
Grounded in your help content and your live order data, able to take the action the customer actually needs, and honest about when it should hand over to a person.
What does an customer support agent do?
An AI support agent reads an incoming ticket, retrieves the relevant policy and the customer's live account and order state, then either resolves the issue by acting in your systems or escalates it with a written summary. The metric that matters is containment measured alongside satisfaction and reopen rate, never alone. On well-scoped queues 50-70% full resolution is realistic; agents built without an evaluation set drawn from real transcripts routinely fall short.
Today
Today an agent opens a ticket, reads it, searches the help centre or asks a colleague, switches to the order management system to look up the customer's actual state, decides what the policy permits, takes the action in one or two more tools, writes a reply, and closes the ticket. For routine issues almost all of that time is spent on lookup and context-switching rather than on judgement, which is exactly the shape of work an agent handles well.
Why it hurts
Intent-matching bots reply with help articles. Customers who already searched the help centre before contacting you find that infuriating, and the ticket arrives anyway — now with a frustrated customer attached.
Deflection metrics improve while satisfaction and repeat-contact rate get worse.
Experienced support staff spend a large share of their time switching between the help centre, the order system and the billing tool to assemble context that a machine could retrieve instantly.
Your most capable staff spend their time on retrieval instead of on hard cases.
Without an evaluation set and sampled quality scoring, nobody knows whether the automated responses are accurate. The first signal is a complaint, a chargeback or a social media post.
The failures that matter are the ones that look like closed tickets.
When the automation gives up it hands over a raw transcript. The human starts from zero, so the automation has added a delay rather than removed work — and the support team stops trusting it.
Internal adoption collapses even when the technology works.
Runtime behaviour
Every trigger, the action it takes, and whether a human stays in the loop. This is the table to send to whoever has to sign off on the agent's decisions.
| # | Trigger | Action | Oversight |
|---|---|---|---|
| 1 | A ticket arrives from email, chat or the ticketing system | Classify the issue type, urgency and required action; detect language and sentiment | Autonomous |
| 2 | Issue type is identified | Retrieve the governing policy passages from help content, with citations | Autonomous |
| 3 | Policy context is retrieved | Look up the customer's live account, subscription, order and shipment state | Autonomous |
| 4 | Full context is assembled | Decide the resolution and check it against hard business rules and value thresholds | Autonomous |
| 5 | Resolution is within autonomous limits | Execute it — reship, refund within threshold, update plan, cancel booking, correct an address | Autonomous |
| 6 | Resolution exceeds a value threshold or policy is ambiguous | Escalate to a human queue with a written summary, retrieved context and a recommended action | Human approves |
| 7 | Action completes | Write the customer reply with citations where relevant, update the ticket, log the decision | Autonomous |
| 8 | Customer replies expressing dissatisfaction | Hand over to a human immediately rather than attempting a second resolution | Human approves |
How it is built
Answers come from your help centre, internal policy documents and macros — with a citation for every claim, so a supervisor can verify what the agent told a customer and why.
The agent reads the customer's real state before deciding, because most tickets are about a specific situation rather than a general question.
Resolutions are executed in your systems, with hard limits on value and type enforced in code rather than by instruction.
Handovers arrive as prepared cases — summary, context, attempted actions and a recommendation — so the human starts from work already done.
Containment reported alongside satisfaction, reopen rate and escalation accuracy, with continuous sampling on live conversations.
Results
Containment — the share of tickets closed without a human — is the number every support automation vendor leads with, and on its own it is dangerously easy to game. An agent that confidently answers everything, correct or not, posts excellent containment. The cost shows up later as reopened tickets, chargebacks and churn that nobody attributes back to the automation.
So we report containment against three companions from day one: customer satisfaction on contained tickets, reopen rate within seven days, and escalation accuracy — how often the agent correctly recognised that it should hand over. An agent at 55% containment with stable satisfaction is a better system than one at 75% with a rising reopen rate, and only the four numbers together show that.
The common failure of first-generation support bots is that they only know your help centre. But the majority of real tickets are not “what is your return policy” — they are “where is my order”, “why was I charged twice”, “I need to change the address on order 88213”.
Answering those requires reading live state: the order, the shipment, the subscription, the billing history, the previous tickets. An agent without that access can only ever paraphrase documentation, which is why customers experience it as an obstacle between them and a person.
Whether your support team accepts the system is decided almost entirely by what an escalation looks like when it lands.
A raw transcript with a note saying the bot could not help is worse than no automation, because the human now reads a conversation before starting work. A prepared case — the issue in two lines, the retrieved policy, the account state, what was attempted, what is recommended and why it stopped — means the human resolves it faster than if they had picked it up cold.
The second version takes real engineering effort and is the reason support teams end up advocating for the agent rather than working around it.
Next Step
A 30-minute technical call with an engineer who has shipped this before — not a sales qualification round. You leave with a feasibility read, a rough shape for the build, and an honest answer about whether it is worth doing at all.