How to evaluate an AI phone agent

A polished demo can hide the parts that matter in production. A useful evaluation starts with real call journeys, tests the resulting business action, and checks what happens when speech, data, systems, policies, or people do not behave as expected. This scorecard helps a buying team compare products on evidence rather than presentation.

1. Define the workflow before evaluating the voice

Choose a small set of representative inbound or outbound intents. For each one, document the trigger, caller, required data, allowed actions, prohibited actions, source systems, completion signal, human owner, and fallback. Without this baseline, buyers tend to reward a natural conversation even when the business task fails.

Real call reason and caller
Start and completion conditions
Required reads and writes
Policy and permission boundaries
Exception owner and recovery path

2. Measure end-to-end action accuracy

Score the full outcome, not only transcription or conversational fluency. Did the agent identify the right record, use current availability, apply the correct rule, write the intended object, avoid duplicates, confirm the real result, and leave a recoverable trace? Separate understanding errors, decision errors, connector failures, and confirmation errors.

Correct intent and entity matching
Correct business rule
Successful system action
Truthful confirmation
Visible failure and reconciliation

3. Stress-test the conversation

Use names, addresses, dates, account identifiers, domain language, accents, background noise, interruptions, silence, corrections, code-switching, voicemail, and requests outside scope. Listen for latency and turn-taking, but also check whether the system asks sensible clarifying questions and stops instead of guessing.

Noise, accents, and interruptions
Spelled names and identifiers
Corrections and changing intent
Out-of-scope and adversarial requests
Language-specific native-speaker QA

4. Inspect integration and handoff behavior

Ask which objects are read and written, through what interface, with which permissions, limits, retries, idempotency, logging, and outage behavior. Test human transfer when the destination answers, declines, or is unavailable. The receiving person should get the reason, verified identity state, context, actions attempted, and next step.

Exact connector scope
Least-privilege access
Duplicate and retry controls
Warm transfer and asynchronous fallback
Context that survives the handoff

5. Review governance, privacy, security, and legal fit

Map the data lifecycle: audio, transcript, summaries, identifiers, credentials, analytics, vendors, training use, retention, deletion, access, export, and incident response. Determine who owns consent, recording disclosure, calling rules, sector obligations, and change approval. NIST's voluntary AI RMF offers a useful govern-map-measure-manage structure, but it is not a substitute for applicable law or your risk program.

Data and vendor map
Authentication and secrets handling
Recording, consent, and communication rules
Monitoring, approvals, and change control
Incident, deletion, and exit processes

6. Compare total operating fit

Model telephony, usage, implementation, integrations, testing, monitoring, human coverage, maintenance, languages, support, and internal ownership. Tie value to completed outcomes, recovered opportunities, reduced rework, or service improvement using your baseline. Avoid vendor ROI claims that cannot be reproduced from your data.

Comparable volume and call mix
Implementation and recurring cost
Internal owner and QA capacity
Verified business outcomes
Pilot exit criteria and scale decision

Next step

Bring three representative call journeys and the systems they touch. We will turn them into a test plan and demonstrate the measurable outcome, exceptions, and evidence.

FAQ

How many calls should we test?

There is no universal number. Build a representative set by intent and risk, include common variations and edge cases, and continue until results are stable enough for the business impact and exposure.

Is transcription accuracy the main metric?

No. It is one input. The operational metric is whether the correct action happened, unsafe actions were prevented, failures were visible, and the caller reached an acceptable outcome.

Should we use a scripted demo?

Use it only as a starting point. Add your own terminology, records, policies, interruptions, system outages, edge cases, and live handoffs before making a decision.

How do we compare vendors fairly?

Give each provider the same workflows, data assumptions, success definitions, test set, system actions, hours, languages, human coverage, and cost scope. Record dates and versions.

What should block launch?

Examples include wrong or unverifiable system actions, unsafe advice, unreliable handoff, unclear consent, excessive data access, missing failure visibility, or performance below the agreed risk threshold.

What proof should a vendor provide?

Ask for architecture and data-flow explanations, security and privacy materials, connector scope, test evidence, monitoring and incident processes, references where available, and a live workflow demonstration.