Resolution rate vs deflection rate
Resolution rate and deflection rate are two different questions asked of the same set of conversations. Deflection rate asks how many conversations never reached a human agent. Resolution rate asks how many customers ended up with their problem solved. The first is a routing statistic, the second is an outcome statistic, and they can move in opposite directions from the same change to an AI agent.
The distinction is not academic. Vendors quote whichever of the two flatters the deployment, buyers rarely ask which definition is behind the number, and the gap between them is where most disappointing AI support programs live. Understanding what each metric can and cannot see is the prerequisite for holding a system accountable.
What deflection rate measures
Deflection rate is the proportion of inbound contacts that were handled without a human agent touching them. The denominator is total inbound volume and the numerator is the subset that ended inside self-service or automation. Historically the term came from ticket deflection, where a help center article shown before a contact form counted as a success if the form was never submitted.
What deflection sees is cost avoidance. Every deflected contact is an agent-minute not spent, which maps cleanly onto headcount planning and onto unit cost per contact. What it cannot see is what happened to the customer afterward. A contact that was deflected because the customer found their answer and a contact that was deflected because the customer gave up are indistinguishable in the numerator. A closely related metric, containment rate, has the same blind spot with a narrower denominator: it counts conversations that stayed within the automated channel rather than all inbound contacts.
What resolution rate measures
Resolution rate is the proportion of conversations where the customer's issue was actually settled. The definition sounds simple and the implementation is where it gets contested, because most platforms infer resolution from the absence of a transfer rather than from evidence that the problem went away.
Done properly, resolution requires a confirming signal. That is either a customer statement, a system state change such as a refund issued or an address updated, or the absence of a follow-up contact within a window. A stricter version of the metric, verified resolution rate, makes that confirmation mandatory and counts anything unconfirmed as unresolved. Resolution also has a long-standing analogue in human support, first contact resolution, which has always been defined against a repeat-contact window rather than against a transfer event.
Where the two numbers diverge
The two metrics agree when automation genuinely solves problems and diverge in three recognizable patterns.
The abandonment gap. A customer asks a question, gets an unhelpful answer, and leaves without escalating. Deflection counts it. Resolution should not. This is the largest single source of divergence in most deployments and it is invisible unless follow-up behavior is tracked.
The channel-switch gap. The customer leaves the chat and calls the support line an hour later, or emails the next morning. Deflection counted the chat as a win and then counts the phone call as a fresh inbound contact, so the same underlying issue inflates the denominator once and the numerator once. Fin has made this point specifically about cross-channel returns, which only surface in reporting that unifies identity across channels rather than treating each channel as its own funnel.
The partial-answer gap. The agent answers the literal question and misses the underlying need. The customer accepts the answer, the conversation ends cleanly, and a follow-up contact appears two days later under a different intent label. Deflection and naive resolution both count this as success; only a recontact-aware definition catches it.
Why deflection is easier to inflate
Deflection rate can be raised without improving anything the customer experiences. Narrowing what counts as an eligible contact removes hard cases from the denominator. Removing or burying the path to a human raises the numerator. Adding friction before escalation, such as an extra confirmation step, raises it further. None of these changes require the agent to answer a single additional question correctly, and all of them show up as improvement on a deflection dashboard.
Resolution is harder to move this way because the numerator depends on something outside the system's control. The customer either came back or did not. That does not make resolution unmanipulable, since a team that defines resolution as no-transfer has effectively redefined it as deflection with a better name. The defense is to publish the definition alongside the number: what the denominator includes, what evidence promotes a conversation to resolved, and what the follow-up window is. Scope changes should be versioned and dated, so a step change in the metric can be attributed to a definition change rather than mistaken for a performance change.
Which metric to hold a vendor to
Hold a vendor to resolution, defined in the contract, with deflection reported alongside it as context. A deflection number quoted without a resolution number is a claim about routing presented as a claim about quality. A resolution number quoted without its definition is not yet a number.
Three companions make the pair trustworthy. Recontact rate within 48 or 72 hours is the cheapest check on an inflated resolution figure and the one number an aggressive bot cannot improve. Escalation rate shows whether the path to a human is intact rather than suppressed. CSAT on automated conversations catches the case where the issue was technically resolved and the experience was still bad. Read together, these five make it very hard for a system to look good while performing badly, which is more than can be said for any one of them alone.
