AI Voice Agent Accuracy: A Practical Evaluation Framework

Why one accuracy number is useless

Ask how accurate a voice agent is and you will get a single percentage. It is always meaningless, because 'accuracy' on a phone call is at least five different things that fail independently and are fixed by different work.

A call can go wrong because the system misheard a word, because it understood the words and misread the intent, because it retrieved the wrong fact, because it called the wrong system or passed the wrong parameter, or because everything worked and the caller still did not get what they needed. A single number averages these into something that cannot be acted on.

The framework below separates them into five layers, each with its own test set and its own remedy. The value of the separation is diagnostic: when the number moves, you know which team's work moved it.

Layer 1: recognition accuracy

Did the system correctly hear what was said? Everything downstream inherits this, so it is measured first and independently.

• Build a test set from real call recordings, transcribed by a person as ground truth. A few hundred utterances per language is enough to be useful.
• Measure word-level accuracy overall, and separately for the elements that carry risk: numbers, dates, names, reference codes and product terms. Overall accuracy can look healthy while digit accuracy is poor, and digits are what produce wrong outcomes.
• Measure per language, per accent group and across line conditions — mobile, hands-free, background noise.
• Test code-switching explicitly if your callers mix languages, because it is common in multilingual markets and degrades most systems.
• Track it over time. Recognition can regress when a vendor updates a model, and nothing announces it.
• Remedy: domain vocabulary hints, streaming recognition, audio path improvements, and confirming risky elements back to the caller.

Layer 2: intent accuracy

Given what was heard, did the system correctly identify what the caller wanted? This is measured from text, so it can be tested without audio.

• Build a labelled set of real utterances mapped to your intent taxonomy, including the ambiguous ones rather than only the clear cases.
• Measure accuracy per intent, not overall. A rare intent performing badly is invisible in an aggregate figure and may be the expensive one.
• Measure the confusion pairs specifically — which intents get mistaken for which. This is where taxonomy problems surface, and the answer is often to merge two intents rather than to improve the classifier.
• Include out-of-scope utterances and measure whether they are correctly rejected rather than forced into the nearest intent.
• Measure behaviour below the confidence threshold: does it ask a clarifying question rather than guess?
• Remedy: taxonomy revision, better examples, threshold tuning, and a clarification path.

A common finding here is that the taxonomy is the problem rather than the model. Two intents that humans cannot reliably distinguish from a single sentence will never be distinguished by a classifier either.

Layer 3: factual accuracy

Given the correct intent, was the answer factually right and drawn from approved sources? Voice adds a specific difficulty: the caller cannot see a citation, so there is no visible signal of where an answer came from.

• Test against a question set with verified correct answers, reviewed by whoever owns that content area.
• Measure grounding: what share of factual answers traced to an approved source passage. Ungrounded answers are suspect regardless of whether they happened to be correct.
• Measure refusal behaviour on deliberately unanswerable questions. A system that never declines is not accurate, it is confident.
• Pay particular attention to answers containing numbers, prices, dates and timeframes. These are published commitments and a wrong one has consequences beyond a poor call.
• Measure per language separately — content coverage differs and a shared figure hides the weaker one.
• Remedy: content correction, retrieval tuning, relevance thresholds, and tightening the scope boundary.

Because there is no visible citation on a call, the grounding rate matters more here than in text channels. It is the only mechanism by which a wrong answer becomes traceable after the fact.

Layer 4: tool execution accuracy

Did the system call the right system, with the right parameters, and handle the result correctly? This layer produces the most expensive failures because its errors persist after the call ends.

• Measure whether the correct tool was selected for the situation.
• Measure parameter accuracy — the right order number, the right date, the right customer. A correctly selected tool with a misheard parameter produces a confidently wrong action.
• Measure confirmation behaviour: were risky values repeated back before being used?
• Measure failure handling: when a lookup timed out or a write failed, did the system degrade honestly, queue the write, and avoid claiming success?
• Measure idempotency under retry — that a repeated attempt did not create a duplicate booking or record.
• Reconcile periodically: do the actions the system believes it performed actually exist in the destination systems? Discrepancies here are the most serious finding available and are invisible otherwise.
• Remedy: parameter confirmation, tighter tool definitions, timeout and retry behaviour, and audit logging.

Layer 5: outcome accuracy

Everything above can pass while the caller still ends the call without what they needed. This layer is the only one that measures the thing the business actually cares about.

• Measure task completion: of calls with a clear goal, how many achieved it within the call.
• Measure repeat contact: how often the same caller returned about the same issue within a few days. This is the honest counterweight to a flattering containment figure.
• Measure escalation appropriateness in both directions — calls that should have escalated and did not, and calls that escalated unnecessarily.
• Measure abandonment mid-conversation, which usually indicates a conversational rather than a factual failure.
• Sample calls that passed every technical layer and still failed. These are the most informative recordings you have and they require human listening to understand.
• Remedy: usually conversation design, pacing or scope rather than any technical layer.

Outcome accuracy is where the framework connects to the business case. The other four layers explain why it is what it is.

Running the evaluation

The framework is only useful if it runs repeatedly and cheaply.

1. 1

   Build the test sets once, from real calls

   One per layer, per language. This is the bulk of the effort and it is reusable indefinitely.

2. 2

   Automate layers 2 to 4

   Intent, factual and tool accuracy can be evaluated without audio and without people, which means they can gate every release.

3. 3

   Keep layers 1 and 5 partly manual

   Recognition needs human ground truth; outcome quality needs human listening. Budget for both rather than pretending they can be automated.

4. 4

   Gate changes on the suite

   Any model, prompt, content or integration change triggers a re-run. This is what prevents the slow accuracy decay these systems otherwise show.

5. 5

   Add a test case for every production failure

   The suite should grow from reality, not from imagination.

6. 6

   Report by layer, always

   A single headline figure recreates the problem the framework exists to solve.

Report alongside latency, since the two trade against each other — a change that improves factual accuracy by adding a lookup may make the call feel worse, which the latency instrumentation will show.

Data and tooling requirements

Modest tooling, significant discipline.

• Call recordings and transcripts with appropriate consent and retention arrangements for your markets.
• Human-verified ground truth for the recognition set.
• A labelled intent set including ambiguous and out-of-scope utterances.
• A verified question-and-answer set, signed off by content owners.
• Retrieval traces stored with calls so grounding can be checked.
• Tool call logs with parameters, outcomes and timing.
• Reconciliation access to destination systems.
• A repeatable harness that can run the automated layers on demand.

The reconciliation capability is the one most often missing and the one that catches the errors nobody else finds. Our custom software services page covers building this evaluation layer, and an AI call centre platform provides part of the logging and tracing it depends on.

Failure modes

Evaluation itself fails in predictable ways.

• Reporting one accuracy number.
• Using vendor recognition figures instead of measuring your own audio.
• Test sets written by the team that built the system, which are systematically easier than real calls.
• No out-of-scope or unanswerable cases, so refusal behaviour is never measured.
• Aggregate figures across languages.
• Measuring tool selection but not parameter accuracy.
• Never reconciling actions against destination systems.
• Evaluating once before launch rather than on every change.
• Treating outcome accuracy as unmeasurable and therefore ignoring it.

What the framework cannot tell you

Be explicit about the limits when reporting.

• Whether the tone suits your callers — that needs listening, which is the subject of a separate review discipline.
• Whether the source content is correct, as opposed to faithfully retrieved.
• Whether a category should be automated at all.
• How the system behaves under volumes or conditions you have not tested.
• What callers who hung up early would have wanted.

Layer 5 partially addresses the first and last of these, but only by prompting a human to go and listen.

Decision framework and next step

Four questions.

1. 1

   Do you have separate test sets per layer?

   If there is one test set, there is one number, and it will not be actionable.

2. 2

   Is recognition measured on your own audio, per language?

   Everything else inherits this ceiling.

3. 3

   Are tool parameters measured, not just tool selection?

   This is where the expensive failures are.

4. 4

   Can you reconcile actions against destination systems?

   Without it, a class of serious error is undetectable.

Build the recognition and intent sets first — they are the cheapest and they bound everything above them. Add factual and tool layers before widening scope, and sample for outcome quality continuously. The equivalent discipline for text channels is in the testing checklist; per-language considerations are in multilingual voice agents; our AI solutions overview covers staging.

Frequently asked questions

1. 1

   How should AI voice agent accuracy be measured?

   As five separate layers: recognition, intent, factual correctness, tool execution and outcome. Each fails independently, is fixed by different work, and needs its own test set. A single blended accuracy figure cannot be acted on.

2. 2

   Which layer should be measured first?

   Recognition, on your own call recordings and per language, since everything downstream inherits it. Measure digits, dates, names and product terms separately from overall word accuracy.

3. 3

   What data is required?

   Recordings and transcripts with appropriate consent, human-verified ground truth, a labelled intent set including ambiguous and out-of-scope cases, a verified answer set signed off by content owners, retrieval traces, tool call logs, and reconciliation access to destination systems.

4. 4

   What are the most common evaluation mistakes?

   Reporting one number, trusting vendor recognition figures, writing test sets in-house that are easier than real calls, omitting unanswerable questions, aggregating across languages, and measuring tool selection without parameter accuracy.

5. 5

   What can the framework not establish?

   Whether the tone suits your callers, whether the underlying content is correct, whether a category should be automated at all, and what callers who abandoned early actually wanted.

The point of separating the layers is diagnostic: when a number moves, you know whose work moved it and what to do next.