Evalgent
Back to Blog
Voice AI Evaluation

How to Measure Resolution Rate for Voice Agents

Deepesh Jayal
12 min read
How to Measure Resolution Rate for Voice Agents

# How to Measure Resolution Rate for Voice Agents

Quick answer

> Quick answer: Resolution rate for voice agents is the share of calls where the caller's issue was actually resolved, divided by all handled calls. Count a call resolved only when the outcome is verified, not when the agent claims success. Resolution is stricter than containment or task completion.

Most teams track a resolution rate. Few can defend the number. The gap is not the arithmetic. It is the definition of "resolved."

A voice agent will happily end a call by saying the problem is fixed. Saying so does not make it true. The caller may hang up confused. They may call back an hour later. That second call is the evidence your first number was wrong.

This guide fixes the definition first. Then it walks the numerator and denominator choices. Then it shows a step-by-step measurement method. Evalgent is an independent evaluator, so we care about one thing here: a resolution rate you can trust because the outcome was verified on real calls.

What resolution rate means for a voice agent

Resolution rate is a simple ratio. It is resolved calls divided by handled calls, over a defined window. The math is easy. The words hide the work.

A rate) is one quantity measured against another. Here the numerator is resolved calls. The denominator is the calls in scope. Both need strict definitions. Otherwise the ratio compares nothing to nothing.

Treat resolution rate as a true key performance indicator, not a vanity stat. A KPI is only useful when its inputs are stable. If "resolved" drifts month to month, the trend line lies. So the definition has to be written down and applied the same way every time.

The concept is close to first call resolution in a traditional contact center. First call resolution asks whether one contact settled the issue. Resolution rate for a voice agent asks the same question of the machine. The difference is who does the resolving, and how honestly you check it.

How "resolved" should be defined

Here is the rule that matters most. A call is resolved when the caller's intent was satisfied. It is not resolved because the agent said so.

> Verified resolution: A call outcome is verified when evidence outside the agent's own claim confirms the caller got what they needed. Evidence includes the transcript, a downstream system record, or a human review.

Self-reported success is the trap. An agent can complete every step of a script and still fail the person. It can book the wrong date. It can quote the wrong balance. It can promise a callback that never fires. Each of those is a "success" in the agent's log and a failure in real life.

So verification needs a source of truth outside the model. Three sources work well. The first is the downstream record: did the order actually get placed. The second is the transcript, read against the intent. The third is a human reviewer who judges the outcome. Good measurement uses more than one.

This is also where customer service intuition helps. Ask the plain question a supervisor would ask. Did the caller leave with the thing they came for? If you cannot answer yes with evidence, it is not resolved. Our guide on how to score a voice agent conversation breaks the judgment into repeatable criteria.

Choosing the numerator and denominator

The ratio has two knobs. Both change the answer. Set them on purpose, not by accident.

The numerator is resolved calls. Use the strict, verified definition above. Do not fold in "the agent finished the flow." Fold in only calls where the outcome held up.

The denominator is the harder choice. It is the set of calls in scope. Several options exist, and each tells a different story.

  • All calls that reached the agent, including immediate hang-ups.
  • Only calls where the caller stated an intent the agent is meant to handle.
  • Only calls within a supported topic, excluding out-of-scope requests.
  • Only calls that passed authentication or another entry gate.

There is no single right denominator. There is a right disclosure. State it next to the number. "Resolution rate of 71 percent, over authenticated in-scope calls" is honest. A bare "71 percent" is not. When you compare vendors, force the same denominator on all of them, the way you would when you benchmark voice agents on your own data.

Watch the denominator games. A vendor can inflate the rate by shrinking the denominator. Drop the hard intents and the number climbs. Exclude abandoned calls and it climbs again. That is why the scope has to be fixed before anyone sees the result.

Resolved, escalated, abandoned, and repeat: sorting every call

Every handled call lands in exactly one outcome category. You cannot compute a resolution rate until each call is sorted. The four categories below cover the common cases. Only one of them counts as resolved.

Outcome categoryHow to detect itHow it counts
ResolvedVerified evidence the intent was met: downstream record, transcript, or human review agreesCounts in the numerator (a success)
EscalatedCall transferred or handed to a human, by request or by fallbackNot resolved by the agent; stays in the denominator
AbandonedCaller hangs up before the intent is met, no transfer, no confirmationNot resolved; stays in the denominator
Repeat contactA later call on the same issue within the window, linked to the originalReverses the earlier "resolved" tag; net success only

A few notes on the edges. An escalation is not always a failure of the business. Some calls should reach a human. But it is a failure of the agent to resolve, so it belongs outside the numerator. Our guide on escalation for voice agents covers when a handoff is the right call.

An abandoned call is ambiguous on its face. The caller might have given up. They might have gotten the answer and left happy. Do not guess. Check the transcript before you decide, and default to "not resolved" when the evidence is thin.

The repeat contact is the sneaky one. It arrives after you already counted the first call as a win. When it lands, the original tag has to flip. More on that leakage below.

Resolution rate vs containment and task success

Three metrics get confused constantly. Resolution rate, containment, and task success measure different things. Mixing them is the most common reason a number looks great and means little.

Containment is the share of calls that never reached a human. It measures avoidance, not outcome. A contained call can still fail the caller completely. They stayed with the agent, got nothing, and left. That counts as contained and as unresolved at the same time. Our guide on containment versus deflection untangles those two, and neither one equals resolution.

Task success is narrower than resolution. It asks whether a specific task completed, like "did the agent read the balance." Resolution asks whether the caller's whole reason for calling was handled. An agent can nail the task and miss the intent. It reads the balance, but the caller wanted to dispute a charge.

So the hierarchy is clear. Containment is the loosest. Task success is a component. Resolution is the strict, caller-centered measure. When you report all three, label each one. Do not let a high containment number stand in for resolution. The difference between testing and evaluation shows why the strict measure is the one that predicts real performance.

How to measure resolution rate step by step

Follow this sequence once and the method becomes routine. Each step removes a way the number could lie.

1. Define resolved for each intent. Write a one-line success condition per intent. "Dispute logged with a case number" beats "handled the dispute." Vague conditions produce vague rates.

2. Fix the denominator and disclose it. Decide which calls are in scope. Write the scope next to the number. Apply the same scope to every agent you compare.

3. Pick a verification method. Choose evidence outside the agent's claim. Use the downstream record, the transcript, and human review. Do not accept self-reported success alone.

4. Set the measurement window. Choose a window long enough to catch callbacks. Seven days is a common floor. Tie the window to your own repeat-contact pattern.

5. Sort every call into one outcome. Tag each call resolved, escalated, abandoned, or repeat. One category per call. No call left untagged.

6. Link repeat contacts to the original. Match callers across calls on the same issue. When a repeat lands, flip the earlier "resolved" tag to unresolved.

7. Compute per intent, then weight. Calculate the rate for each intent separately. Weight by your real call mix. A blended average hides the intents where the agent quietly fails.

8. Re-verify on a fresh sample. Resolution drifts as prompts and models change. Re-check a new sample on a schedule. A single audit ages fast.

The order matters. Definition comes before counting. Verification comes before you trust a tag. Skip a step and the rate you publish will not survive contact with a callback.

Measurement window and repeat-contact leakage

The window is where good measurement quietly breaks. A resolution counted today can be undone tomorrow. If your window closes too early, you never see the reversal.

> Repeat-contact leakage: The error introduced when a call is marked resolved, but the caller returns on the same issue after the measurement window has closed. The original success stands uncorrected, and the reported rate overstates true resolution.

The fix is a window long enough to capture the return. Pick it from your own data. Look at how long callers usually take to call back on an unresolved issue. Set the window past that point. Too short and you count phantom wins. Too long and the report lags reality. Balance the two against your call patterns.

Linking is the other half. A callback only corrects the record if you connect it to the first call. Match on the caller and the issue, not just the phone number. One person can call about two different things. Two people can share a line. Sloppy linking creates its own error.

Beware a subtle bias here. If you only audit the calls that reached a clean ending, you inspect the survivors. That is a form of selection bias, and it flatters the agent. The calls that went wrong are exactly the ones that dropped, escalated, or repeated. Sample across all outcomes, not just the tidy ones. This is the same discipline behind a trustworthy cost per resolved call, where the resolution rate is the denominator that decides the economics.

Human judgment needs consistency too. When reviewers disagree on what "resolved" means, the rate wobbles. Measure that agreement. Inter-rater reliability tells you whether two reviewers apply the same bar. Low agreement means the definition is too loose, not that the reviewers are careless. Tighten the rubric and the noise falls. Where resolution sits among your other measures is laid out in the voice agent metrics scorecard.

Why an independent measure matters

A vendor grading its own resolution rate has a conflict. The definition, the denominator, and the verification all sit with the party that benefits from a high number. That is not fraud. It is incentive. Even honest teams drift toward the reading that flatters them.

An outside check removes the incentive. The definition is fixed independently. The denominator is disclosed and held constant. The verification uses evidence, not the agent's own log. That is the case for independent voice AI evaluation, and it applies to resolution more than any other metric, because "resolved" is so easy to redefine.

Resolution also has to hold up over time, not just at launch. Prompts change. Models update. Call mixes shift with the season. A number that was true in the spring can rot by the fall. Continuous re-verification is the only guard, and it belongs in your broader voice agent evaluation program.

Frequently asked questions

What is a good resolution rate for a voice agent?

There is no universal number. A good rate depends on intent difficulty and your denominator. Simple lookups can resolve above 90 percent. Complex disputes resolve far lower. Judge the rate against your own baseline and your human agents, not a vendor's headline figure, and always check which calls the denominator includes.

How is resolution rate different from containment rate?

Containment measures the share of calls that never reached a human. It rewards avoidance, not outcome. Resolution measures whether the caller's issue was actually fixed. A contained call can still fail the caller, who leaves unhappy or calls back. So containment is always higher than resolution, and it should never be reported as if it were resolution.

What counts as a resolved call?

A call counts as resolved when the caller's intent was satisfied and confirmed by evidence. The evidence is a downstream record, the transcript, or a human review, not the agent saying it succeeded. If the caller repeats the same issue within the measurement window, the earlier resolution is reversed. One verified, non-repeated success per issue counts.

How do you verify a caller's issue was resolved?

Use a source of truth outside the agent's own claim. Check the downstream system for the action that should have happened. Read the transcript against the stated intent. Have a human reviewer judge the outcome on hard cases. Combining sources catches the calls where the agent reported success but the real-world result was wrong.

What measurement window should you use for resolution rate?

Use a window long enough to catch callbacks on the same issue. Seven days is a common floor for support lines. Set your window from your own data, past the point where most repeat contacts arrive. Too short and you count wins that later reverse. Too long and the report lags what the agent is doing now.

What is repeat-contact leakage?

Repeat-contact leakage is the error from counting a call resolved when the caller returns on the same issue after your window closed. The original success is never corrected, so the reported rate overstates true resolution. The fix is a window that captures returns, plus reliable linking of repeat calls back to the original contact and issue.

Is resolution rate the same as task success rate?

No. Task success asks whether one specific task completed, like reading a balance. Resolution asks whether the caller's whole reason for calling was handled. An agent can complete the task and still miss the intent, for example quoting a balance when the caller wanted to dispute a charge. Resolution is the broader, caller-centered measure of the two.

Should abandoned calls count against resolution rate?

Usually yes, unless evidence shows the caller left satisfied. An abandoned call is ambiguous, so do not guess. Read the transcript before deciding. Default to unresolved when the evidence is thin, because abandonment often signals frustration. Whatever rule you pick, apply it consistently and disclose it, so the denominator stays comparable across agents and over time.

How Evalgent verifies resolution on real calls

A resolution rate is only as honest as its weakest definition. Evalgent is an independent platform that measures resolution against your real call mix, using evidence rather than the agent's self-report. Five primitives keep the number defensible.

  • Scenarios encode the real intents your callers bring, so resolution is measured where it matters.
  • Profiles simulate different caller types, accents, and moods, exposing where resolution quietly collapses.
  • Metrics capture resolved, escalated, abandoned, and repeat outcomes, with the window applied consistently.
  • Evaluations run the same scenarios across agents, producing comparable rates instead of incomparable claims.
  • Reviews let trained humans confirm what counts as resolved, and track their agreement over time.

Put the definition on solid ground and the rate becomes a number finance and product can trust. To see it verified against your own agents, book a demo.

The bottom line

Resolution rate only means something when "resolved" is verified, not self-reported. Fix the definition, disclose the denominator, and hold a window long enough to catch the callback.

Related Articles