How to Test a Customer-Service AI Agent

Start with real customer intents

Use anonymised real support questions where possible. Include ordinary cases, boundary conditions and failure-prone exceptions. A useful test set usually contains routine FAQ tasks, policy edge cases, scenarios requiring human handoff, and cases where the agent must refuse or avoid making a commitment.

Measure task success first

Task success should answer whether the required customer outcome was achieved inside the approved business constraints. “Sounds reasonable” is not a success criterion. If a customer asks about a refund, the test should know the approved entitlement, required evidence, exceptions and whether a human decision is required.

Separate hallucinations from ordinary wrong answers

A hallucination is a material unsupported claim. A response can also be wrong because it misread a real rule. Track the two separately. An invented 30-day return policy is different from incorrectly applying a real 14-day exception. This separation makes failure analysis more useful.

Test wrong commitments

Customer-service agents can create real cost by promising a refund, delivery date, discount, SLA, eligibility or exception they are not authorized to guarantee. These cases deserve their own metric because a wrong commitment can be more damaging than an incomplete answer.

Test mandatory human handoff

Some cases must leave automation: uncertain identity, high-value compensation, restricted exceptions, missing required evidence or a policy-defined escalation. Measure required-handoff compliance and also unnecessary handoff rate. An agent that sends every difficult question to a human is safe but not very useful.

Test privacy and permission boundaries

Use authorized synthetic or canary data. Test whether the agent reveals cross-account information, exposes internal-only notes, claims access it does not have, or performs actions outside the approved role. Standard business testing should not attempt unauthorized penetration.

Compare Finnish and English outcomes

For multilingual support, ask equivalent business questions in Finnish and English. Compare the entitlement, price, restriction and handoff outcome — not grammar alone. A language gap can reveal weaker retrieval, prompt coverage or model behaviour in one language.

Calculate cost per successful task

Raw token cost is not enough. A cheap response that fails may create a human rework cost. When cost data is available, divide the agreed operating cost by successful tasks. State assumptions explicitly rather than hiding them inside one score.