Recontact rate

Recontact rate is the share of conversations marked resolved where the same customer comes back about the same issue within a fixed window, typically 48 or 72 hours. It is calculated after the fact, from contact history rather than from anything the agent reports about itself, which is what makes it the cheapest available cross-check on an inflated resolution number.

Every other measure of automated support quality depends on the system's own judgment of how a conversation went. Recontact rate depends only on whether the customer came back. Digital Applied has argued that deflection and containment figures should never be published without a paired 48-hour recontact rate for exactly this reason, describing it as the one quality signal a more aggressive bot cannot improve.

How recontact rate is calculated

The denominator is conversations that were closed as resolved in a given period. The numerator is the subset of those where the same customer initiated a new contact about the same issue before the window closed. The result is expressed as a percentage and read as a failure rate: lower is better, and a rising recontact rate means resolutions are being claimed that did not hold.

The arithmetic is worth doing explicitly because it is unforgiving. Helply illustrates the point with a system reporting 85% resolution where 30% of those customers return within 72 hours, which leaves roughly a quarter of the claimed resolutions unearned once the recontacts are subtracted out. That correction is large enough to change a build-versus-buy decision, and it costs nothing to compute for any team that already stores contact history with stable customer identifiers.

Two design choices matter before the first number is produced. The denominator should include only conversations the system claims to have resolved, or the metric becomes a diluted measure of general contact frequency and stops being comparable to resolution rate. And the clock should start at conversation close rather than at conversation start, so long conversations are not penalized twice.

Choosing the window

A 48-hour window is the most common default. It is long enough to catch the customer who tried the suggested fix, found it did not work, and came back the next morning, and short enough that most returns inside it are plausibly about the same issue rather than a new one.

A 72-hour window catches weekend spillover and suits consumer businesses where contact patterns cluster around evenings and weekends. A seven-day window catches slow-burn failures such as a refund that was promised and never arrived, but it also sweeps in a large volume of genuinely new issues, pushing the metric toward noise. Teams that want both usually report the 48-hour figure as the headline and the seven-day figure as a secondary series.

Whatever the window, it should be fixed and published. A window that changes between reporting periods makes the series uninterpretable, and shortening it is the easiest way to make recontact rate look better without any underlying improvement.

Why it resists gaming

Most support metrics can be moved by changing configuration rather than capability. Narrowing scope raises containment. Suppressing the escalation path raises deflection. Relabeling closure reasons raises resolution. Recontact rate is immune to all three, because the numerator is generated by the customer and the denominator shrinks as the numerator would otherwise grow.

The mechanism is worth stating plainly. An agent that becomes more aggressive about closing conversations without solving them adds those conversations to the denominator as claimed resolutions, and the customers in them come back, adding the same conversations to the numerator. The ratio gets worse. This is the opposite of how containment rate behaves under the same change, and it is why the two belong on the same dashboard.

The metric is not entirely beyond manipulation. A team that excludes certain intents from the resolved denominator, or that treats a returning customer as new because identity was not resolved across channels, can produce a flattering figure. Both distortions are detectable by anyone who reads the definition.

The attribution problem

The hard part of recontact rate is deciding what counts as the same issue. A customer who asks about a delayed order on Monday and about a promo code on Wednesday has not recontacted in any meaningful sense, but a naive implementation that counts any return contact within the window will record it as a failure.

The usual approach is to compare intent labels produced by intent detection or by automatic tagging on both contacts, and to count a recontact only when the labels match or fall in the same category. This is approximate. Label granularity that is too coarse merges unrelated issues; granularity that is too fine splits the same issue across two labels when the customer describes it differently the second time. Teams usually calibrate by sampling a few hundred flagged pairs and reading them, then adjusting the matching rule until the sampled precision is acceptable.

Cross-channel returns are the second attribution difficulty. A customer resolved in chat who calls the next day is a recontact, but only if the two contacts can be joined to the same person. Without unified identity across channels, recontact rate systematically understates failure, and it understates it most in exactly the accounts where the customer had the worst experience and switched channels out of frustration.

Acting on a high recontact rate

A high aggregate figure is not actionable on its own. The first move is always to break it out by intent, because recontact almost never distributes evenly. A handful of intents typically account for most of the volume, and they usually fall into one of three shapes.

The first is a knowledge problem: the agent gave an answer that was correct according to a stale article. The fix is upstream in the knowledge base rather than in the agent. The second is a capability problem: the agent explained what needed to happen but could not do it, so the customer returned once they discovered nothing had changed. The fix is a tool integration, not better prompting. The third is a handoff problem: the conversation should have gone to a human and did not, which points at the escalation policy rather than at the answer itself.

Because the diagnosis differs so sharply by shape, recontact rate is most useful when it feeds a review queue rather than a report. Routing a sample of recontact pairs into quality review each week, and reading the first conversation in each pair, surfaces the specific failure faster than any aggregate trend line will.