Evaluating a customer-support agent from answer to action
A support agent should be judged on whether it resolves the right problem safely, not on whether its first answer sounds convincing.
Architecture & engineering, Evaluation & assurance Agents in practice
A customer asks why an order has not arrived. The agent apologises, quotes the delivery policy and confidently says the parcel will arrive tomorrow. The answer reads well. The parcel was actually returned to the warehouse, the promised date is invented and no replacement was created.
That is not a minor answer-quality defect. It is a service failure disguised as a fluent conversation. A useful evaluation has to follow the case from the customer’s intent to the system state, any action taken, the handoff and the eventual outcome. The central question is not “Did the agent answer?” It is “Did the service resolve the right problem through an authorised and recoverable path?”
Begin with the service promise
Define what the support operation promises for each important case type. A delivery enquiry may require accurate status, a realistic next step and escalation when the carrier data is inconclusive. A billing dispute may require formal recognition, preservation of the customer’s statement and routing into a controlled investigation. A cancellation may require identity checks, confirmation of scope and an auditable state change.
The ISO complaints-handling standard treats complaint receipt, assessment, investigation, response and improvement as a process, not a single response. That is the right evaluation unit for an agent too: the whole support journey.
Build the evaluation set around real service promises and consequences. Include ordinary enquiries, emotionally charged contacts, ambiguous requests, inaccessible channels, missing data and cases that invoke a complaint or other protected route. The UK Government Service Standard calls for a joined-up experience across channels, so test whether a customer can move from agent to person without starting again.
Trace the case through five layers
Score distinct layers rather than allowing a polished answer to hide a broken action.
| Layer | Evidence to inspect | Typical failure |
|---|---|---|
| Understanding | detected intent, entities, urgency and missing facts | a dispute is classified as a general question |
| Grounding | policy version, account state and cited records | an old return policy is applied |
| Decision | chosen route, exclusions and escalation condition | an exception is forced into the normal path |
| Action | tool call, parameters, permission and result | the agent promises a refund it did not create |
| Resolution | customer confirmation, downstream state and later reopening | the ticket closes while the problem remains |
Keep the observations separable. “Correct” can mean the words matched policy while the action failed. “Resolved” can mean the action completed while the customer was given a misleading explanation. Leaders need to see both.
Test actions against delegated authority
List every action the agent can propose or execute: change an address, cancel a service, apply a credit, reset access, alter an appointment, disclose account information or contact a third party. For each action, record the permitted amount, account condition, identity evidence, required approvals, prohibited cases and confirmation signal.
Then create boundary tests. Ask for a refund just above the limit. Combine two individually permitted credits. Change the customer identifier midway through the conversation. Present untrusted text that instructs the agent to ignore policy. Simulate a tool timeout after the external system may have committed the change.
The result should distinguish not attempted, rejected, completed, failed and outcome unknown. An agent that retries an uncertain refund can create a duplicate payment; one that announces success before confirmation creates false assurance. Evaluation therefore needs both the tool trace and the authoritative downstream record.
Make handoff a first-class outcome
Handoff is not a failure whenever the case exceeds delegated authority. It is often the correct result. Evaluate whether the agent:
- recognizes the trigger early enough;
- sends the customer to the right queue;
- preserves identity, history, evidence and attempted steps;
- states what will happen next without inventing a deadline;
- does not force the customer through a loop back to automation; and
- allows the human operator to understand and override its reasoning.
The US Consumer Financial Protection Bureau found that financial chatbots can fail to recognise disputes and trap people in repetitive loops without meaningful human assistance (CFPB). The lesson travels beyond finance: test whether the route to a person works for difficult language, distress, disability, atypical phrasing and repeated failure—not only for an explicit “human please.”
Measure durable resolution, not deflection
Deflection counts how many contacts avoided a human queue. It does not show whether the customer’s problem disappeared. Pair immediate measures with later evidence:
- valid resolution by case type;
- action completion and reconciliation;
- repeat contact and ticket reopening;
- downstream correction or manual rework;
- customer effort across channels;
- escalation precision and queue latency;
- complaint recognition and preservation; and
- harmful or unauthorised action rate.
Segment the results. A high aggregate resolution rate can conceal poor outcomes for a language group, complex product, vulnerable customer or rare but consequential case. NIST’s AI Risk Management Framework calls for performance to be measured in conditions similar to deployment and for impacts on people and groups to be characterized (AI RMF Core).
Exercise recovery, correction and appeal
Support systems operate with stale records, unavailable tools and contradictory sources. Inject those conditions deliberately. If an address update times out, can the agent determine whether it committed before retrying? If policy retrieval fails, does it stop rather than improvise? If a customer corrects a factual assumption, does the plan change?
Include cases where the customer challenges the outcome after completion. The system should retain the original input, policy and action evidence; provide a clear review route; and avoid rewriting history when an operator corrects the result. Sample the corrected cases to learn whether the problem came from understanding, policy, tool behaviour or authority design.
Turn the evaluation into a release decision
Before the release review, run one case end to end with deliberate contradictions. A customer says a parcel is missing; tracking reports delivery; the photograph belongs to another address; the account contains an accessibility preference; and the replacement tool returns an uncertain result. A strong agent preserves the customer’s allegation, checks the evidence, avoids blaming language, uses the right identity and authority checks, and reconciles the replacement state before promising an outcome. The evaluator should be able to point to the exact observation that justified each step.
Repeat the scenario with different products, language styles and customer circumstances. Change only one factor at a time when diagnosing a failure, then use compound cases to test the operating system under pressure. This produces more useful evidence than a large random conversation set whose failures cannot be explained.
Set thresholds by consequence, not one average score. A minor wording issue may be accepted with monitoring. An unauthorised account disclosure, duplicate refund or missed complaint trigger should block the affected action path even if overall resolution is high.
A release review should answer four questions:
- Which case types and actions are supported by evidence?
- Which remain human-only or require approval?
- What production signals will detect deterioration?
- Who can pause an action, reduce authority or route all cases to people?
Start with read-only assistance, then expand one authority dimension at a time. The strongest customer-support agent is not the one that keeps every conversation to itself. It is the one that resolves suitable cases, recognizes the rest and leaves both the customer and the service operation in a knowable state.