Verified resolution rate

Verified resolution rate is the share of customer inquiries an AI agent resolves end to end, with no human involvement, where the resolution is confirmed by evidence rather than inferred from the fact that the conversation stopped. The confirming evidence is usually a post-conversation survey response, a behavioral signal such as the customer never returning about the same issue, or a sampled quality review of the transcript. Everything that cannot be confirmed by one of those three methods is counted as unresolved.

The metric exists because the ordinary resolution rate is computed from an assumption. Most support platforms mark a conversation resolved when it ends without a transfer, which quietly treats abandonment, confusion, and silent failure as success. Verified resolution rate replaces that assumption with a check, and the gap between the two numbers is often the most useful thing a support team learns in its first quarter with an AI agent.

What the verification step actually adds

An unverified resolution number answers a narrow question: did this conversation end inside the AI agent? That is a containment question wearing a resolution label. A customer who gave up, one who got a confident but wrong answer, and one whose problem was genuinely solved all produce the same terminal state in the logs.

Verification separates those three cases. It forces the reporting system to hold a resolution claim open until something outside the conversation confirms it, which changes both the number and the incentives around it. Teams that adopt it typically find the verified figure lands well below the unverified one, and the delta concentrates in a small number of intent categories. That delta is diagnostic. It points at the specific workflows where the knowledge base is stale or where the agent lacks a tool it needs to complete the task rather than describe it.

The three verification methods and their trade-offs

Survey confirmation. A short post-conversation prompt asks whether the issue was resolved. This is the most direct evidence and the easiest to explain to an executive, but response rates are low and skewed. Angry customers and delighted customers answer; the indifferent majority does not. Survey-confirmed resolution is precise on the sample it covers and unreliable projected onto the whole population, a different weakness from the one affecting CSAT, where the question is about feeling rather than outcome.

Behavioral confirmation. The customer did not come back about the same issue within a defined window, did not open a ticket through another channel, and did not escalate. This covers every conversation rather than a self-selected slice, and it requires no customer effort. The cost is attribution difficulty: linking a later contact to an earlier one demands stable customer identity across channels and a way to judge whether the second contact is the same issue. The inverse of this signal is the recontact rate, and the two are usually instrumented together.

Quality review. A reviewer reads a sample of transcripts and judges whether the customer's problem was solved. This catches failures the other two methods miss, including answers that were wrong but confidently accepted. It is also the most expensive method and the one most exposed to reviewer inconsistency, which is why quality assurance programs feeding this metric need a written rubric and periodic calibration rather than a general instruction to use judgment.

How it differs from deflection and containment

Three metrics in this family are routinely confused, and the confusion is commercially convenient for whoever is quoting the highest one. Deflection rate counts conversations that never reached a human agent. Containment rate counts conversations that stayed inside the automated channel from start to finish. Both are measures of routing, and neither says anything about whether the customer's problem went away.

Verified resolution rate is the only member of the family that makes a claim about outcome, and the only one that can go down when the agent gets more aggressive. An agent configured to refuse transfers pushes deflection and containment up while pushing verified resolution down, because the additional contained conversations are exactly the ones that end without the problem being solved. That inversion is the practical reason to track the verified figure separately rather than treating the three as approximations of each other. The first two are compared in more depth under resolution rate versus deflection rate.

Instrumenting verified resolution rate

Instrumentation starts with a resolution event that carries a state, not a boolean. A conversation closes as pending, and a downstream job promotes it to verified or demotes it to unresolved once the window elapses and the evidence is in. Reporting the pending bucket separately is what prevents the metric from silently reverting to the optimistic default when evidence is missing.

The second requirement is a stable issue identifier that survives channel changes. Without it, a customer who chats on Tuesday and emails on Wednesday about the same order appears as two independent resolutions. Most teams approximate this by joining on customer identity plus an intent label produced by automatic tagging, then accepting some noise in the join.

The third is a stratified sampling plan for review. Sampling uniformly across all conversations spends most of the reviewer budget on high-volume, low-risk intents. Stratifying by intent and by whether a tool call was made concentrates review where the agent is most likely to be wrong in a way the behavioral signal will not catch.

What a healthy number looks like

There is no cross-vendor benchmark worth quoting, and any number presented as an industry standard should be treated as marketing. Verified resolution rate is a function of scope. An agent handling order status, returns, and password resets will verify far higher than one handling billing disputes and account closures, and both numbers can describe well-built systems. Comparing them tells you about the intent mix, not the agent.

The number is useful in two ways instead. Tracked over time on a stable intent mix, it shows whether changes to prompts, retrieval, or tools are improving outcomes rather than just improving containment. Broken out by intent, it shows which workflows to build next, which is why it belongs alongside the rest of the support KPI set rather than as a standalone headline.