Resolution rate vs deflection rate: reconcile the numbers

Separate conversations that avoided a handoff from customer issues you can prove were solved.

One report says 90% deflected. Another says 40% confirmed resolved. Both describe the same illustrative support cohort below, not an industry finding.

The resolution rate vs deflection rate distinction starts with what enters each numerator. A no-handoff count measures routing. A confirmed-resolution count requires evidence that the customer’s job is done. The denominator tells you whose outcomes either rate describes.

Before you replace a dashboard number, reconcile its underlying cases. You need a declared population, a completion rule, and enough time to catch returning issues. Otherwise, changing the metric’s name can leave the measurement unchanged.

What do the metric names actually count?

Treat each label as a question, not a standard definition. Ask what events and population sit behind it.

For each reported rate, ask whether its denominator covers all incoming issues or only sessions entering one automated channel. Then check whether its numerator requires completion evidence or merely the absence of a handoff.

A session that ends without escalation may be resolved, abandoned, or still unverified. Don't infer the customer’s outcome from the session ending alone.

These labels describe different events; none substitutes for another without checking its definition.

For your operation, write the rule next to the rate. A resolved issue might involve a human. An autonomous-resolution measure must separately exclude human assistance, rather than hiding that condition inside “resolved.”

One cohort, three very different headlines

Start with the same cases before comparing percentages. This example is illustrative, not a customer result or product test.

You select 1,000 distinct refund issues first entering AI chat during one reporting week. Every issue has one initial session and a stable identifier. Later tickets about that refund stay attached to the original issue.

For this example, completion evidence means a matching refund record marked completed before the initial AI session ends. You then observe each issue for 48 hours after that session ends. Wait until every issue has its full window before finalizing the cohort.

The rows below are mutually exclusive. Each issue appears once.

Figure: the same fictional cohort as the table above, read as a funnel. The frames track 1,000 incoming issues to 900 with no handoff, 520 with completion evidence, and 400 confirmed, with 120 evidence-plus-return issues excluded. Illustrative method, not product UI or a customer result.

No human assists the 900 initially contained sessions in this example. The 200 issues with neither evidence nor returns remain unverified, not necessarily unsuccessful. Customer silence doesn’t establish either result.

Now calculate three rates without changing the cohort:

• Initial no-handoff rate: 900 ÷ 1,000 = 90%. A report might label this “deflection”; here, it only establishes initial chat containment.
• Provisional, evidence-backed autonomous completion: 520 ÷ 1,000 = 52%. That includes the 400 without returns and the 120 subsequently reopened.
• Confirmed autonomous resolution under this example’s rule: 400 ÷ 1,000 = 40%. Completion evidence survives the full observation window without a same-issue return.

The 90% figure says nothing about portfolio-wide deflection.

This cohort excludes people using only other support channels or self-service pages.

Nor should you subtract every returning issue from the provisional successes. There are 300 returns: 120 + 180. Only 120 had completion evidence, so the valid reconciliation is 520 − 120 = 400, not 520 − 300.

Changing the denominator creates another headline: 400 ÷ 900 = 44.4%, rounded to one decimal place. That measures confirmed resolution among initially contained issues, not among all 1,000 issues.

Here, humans also accept all 300 returning issues. Human fallback therefore covers 400 distinct issues: 100 + 300. Acceptance isn’t resolution; their eventual outcomes need a separate check.

Reject 90% as the resolution result.

Keep its narrower routing meaning, report the 40% outcome, and review the 200 unverified issues.

Write the resolution rule before choosing the rate

Define the customer job and its evidence first. Then choose a denominator that includes every issue within your declared scope, including failed attempts and handoffs.

Use this worksheet to agree on your reporting rules. It’s a proposed method, not an industry standard; the filled entries continue the illustrative cohort.

Ask your vendor to fill these same rows, disclose excluded issues, and separate silent endings from evidenced outcomes. Check who can correct classifications and whether those classifications affect billing.

The worksheet separates outcome evidence from the absence of a complaint. Don’t label a no-recontact proxy as confirmed completion unless your stated method supports that inference.

For an informational question, you might require explicit customer confirmation that the answer solved the problem. For a transaction, require the relevant completion event. Don’t impose the refund rule on every support intent.

Choose the observation window around the job, too. This example’s 48 hours isn’t a universal cutoff. A workflow that takes longer needs a longer completion horizon or a clearly pending outcome.

Keep broader ticket deflection strategy separate from this reconciliation. Here, you’re deciding what one outcome figure can honestly claim.

Keep returning issues attached to their first cohort

Count same-issue returns across channels, not just reopened tickets. Otherwise, a new email can conceal a failed chat outcome.

A reopen reactivates the original case. A follow-up can create another ticket about the same unresolved job. In this example, those disjoint groups contain 120 and 180 issues respectively.

The combined return rate is 300 ÷ 900 = 33.3%, rounded to one decimal place, among initially contained issues. The denominator matters: this isn’t the return rate for every support contact.

Count each returning issue once for this measure, even if it generates several contacts. Track the additional contacts separately when estimating workload.

Don’t compare a fully observed cohort with yesterday’s unfinished one. Mark incomplete windows pending, and state how you handle returns arriving after the cutoff. If you revise an earlier result, preserve the original figure and the reason for revision.

Pair the outcome with customer satisfaction, or CSAT, but show who answered the survey. Satisfied respondents don’t establish resolution among nonrespondents.

Likewise, distinguish requested, delivered, and accepted escalations before treating an escalation rate as evidence of human help.

Name the event that would let you close the job

A source-system event should prove the specific job you promised, not merely that a process started. The system of record is the authoritative system for that state.

For the refund example, retain the issue identifier, amount, completion status, and timestamp. A submitted refund request doesn’t meet the rule. Even a billing completion record may not establish that funds reached the customer’s bank.

Write that limitation into the definition. If the customer’s job is “receive the money,” billing completion alone is insufficient evidence. For a bug report, closing an engineering ticket likewise doesn’t establish that the affected customer has a working fix.

When evidence is missing, leave the outcome unverified and keep human help available. Don’t improve the rate by making that fallback harder to reach.

Apply the same test when evaluating Computer, by DevRev. Can the evaluated configuration connect a claimed resolution to the relevant source-system outcome and identify same-issue returns?

Ask for a trace from a claimed success to its evidence. Ask how unresolved issues reach an accepting human. These are evaluation questions, not assertions of native Computer analytics, resolution tracking, or writeback features.

State the denominator whenever you publish a rate

A figure is only interpretable with its population and its scope attached. That discipline applies to vendor numbers as much as your own. When DevRev's own public BILL story reports a 70% resolution rate, it names the measurement context: a proof of concept run on 200,000 real customer queries before full rollout, not a steady production figure.

Read that as a worked example of naming a denominator and scope, not as evidence that deflection and resolution mean the same thing. A pre-rollout proof-of-concept rate on one company's query set answers a different question than a portfolio-wide production rate, and neither becomes the other by sharing the word “resolution.” Hold any rate you cite to the same test you'd apply to your own: whose issues, over what window, with what completion evidence.

Put the claim back into a sentence

A resolution rate should survive being written out in full. For the illustrative cohort, the reporting statement could read:

Among 1,000 refund issues first entering AI chat that week, 400 had matching completion evidence without human assistance. None of those 400 returned about the same issue within 48 hours after the initial session ended.

Keep the 90% initial containment figure beside that statement, with its narrower meaning. Report the 200 unverified outcomes separately. Neither customer silence nor an accepted human handoff belongs in the confirmed autonomous numerator.

Now make the same reconciliation for one fully observed week of your own operation. If you can’t complete the statement, publish the narrower measure you can support.

The next reporting decision isn’t which number looks better. It’s which claim your evidence lets you make.

Bring your cohort rule into the next buyer decision. Explore customer support resolution, then ask how a proposed setup would connect your definition of a completed job to evidence and a same-issue return. The BILL PoC above is a scoped example, not your benchmark.