Want help applying this guide?Ask the DripTell team
A repeat contact should count only when the same customer comes back about the same need because the promised outcome has not happened. A second message is not automatically a failure. It may be a planned update, a thank you, or a different problem.
That distinction sounds obvious until a dashboard has to make it. Teams often group every contact from the same person inside seven or thirty days. The rate rises when a loyal customer asks two unrelated questions and falls when the same unresolved issue returns through another channel. Neither result tells the truth.
Count a return only when the same need remains
Start with a customer need, not a ticket. Suppose someone reports that their internet connection drops every afternoon. Support closes the chat after resetting the router. Two days later, the person calls because the connection is still dropping. That is a repeat contact even if the phone call created a new record.
Now change one detail. The person calls two days later to ask about an invoice. That is a new need. It should not enter the repeat numerator.
The clean rule is simple. Count the later contact when customer identity, issue identity, and unresolved outcome all match. If one of those cannot be established, keep the event in an unknown bucket instead of guessing.
Choose the unit before the formula
Freeze a cohort of eligible first contacts. Then observe each one for a published window. The numerator is the number of those initial issues that produce at least one unplanned return about the same unresolved need. The denominator is every eligible initial issue in the cohort.
- 1Freeze the first contact cohortInclude eligible initial customer needs and give every one the same full observation window.
- 2Link the customer and issueJoin permitted identity evidence across channels, then test whether the later need is genuinely the same.
- 3Classify the later eventSeparate unresolved returns from planned updates, courtesy replies, new needs, duplicates, and unknowns.
- 4Review the earliest causeInspect linked journeys and assign the first controllable knowledge, authority, process, product, communication, or ownership failure.
This issue based rate avoids counting one frustrated customer three times because they sent three follow ups. Keep a separate contact share if workload matters. That second measure divides all repeat contacts by all contacts handled in the period.
The window should follow the work. Seven days may suit a password reset. It may be too short for a replacement part or an insurance review. Microsoft's official returning-customer routing guidance allows recency windows such as seven, ten, or thirty days. Those product choices illustrate why no single window fits every operation. Publish yours and do not change it after seeing the result.
Build the link across channels
A useful measure needs two joins. First, connect the person across email, phone, WhatsApp, web chat, and any other entry point. Second, decide whether the later contact concerns the same unresolved outcome.
A shared inbox can preserve the conversation trail, while a customer record can hold the stable identity and issue relationship. Do not join on phone number alone if numbers are shared, changed, or mistyped. Use only permitted identifiers and keep the matching logic inside your security and access rules.
Issue matching can begin with case relationships and a small reason taxonomy. It should still allow review. Two messages containing the same word may describe different needs. Two messages with different words may concern the same failed delivery. Automation can suggest a link through workflow rules, but a low confidence match should remain unknown until someone checks it.
Separate repeats from legitimate later contact
The classification rule matters more than the arithmetic.
| Later contact | Count as a repeat | Reason |
|---|---|---|
| Same need and promised outcome still missing | Yes | The original issue remains unresolved |
| Update at a time agreed with the customer | No | The later contact is part of the planned service path |
| Customer says thanks and asks for nothing else | No | There is no renewed service need |
| Same customer reports a different problem | No | Customer identity matches but issue identity does not |
| Team sends a duplicate outbound message | No | Record it as a messaging defect, not customer repeat demand |
| Evidence is too weak to tell | Unknown | Do not force uncertain events into either side |
Microsoft's official case-to-resolution guidance describes identifying customers across channels and logging, investigating, resolving, and closing cases. Those system events preserve useful evidence, but they do not decide whether a later need is a repeat. One touch, first contact resolution, reopen rate, and repeat contact rate are related. They are not interchangeable.
Read causes without blaming the agent
Once a repeat is confirmed, assign the earliest controllable cause. The first reply may have been wrong. But the customer may also have returned because a refund failed, a handoff lost context, a promised update never arrived, the product remained broken, or the policy required an unnecessary second contact.
Sample the linked journeys behind the rate. Review the original need, every promise, the visible outcome, the later contact, and the final fix. A support workflow review should distinguish knowledge, authority, process, product, communication, and ownership failures. If every repeat becomes an agent coaching issue, the report will hide the system creating the extra work.
Read the distribution too. Show how many issues returned once, twice, or more, and how long the customer waited before returning. A stable average can hide a small group trapped in a loop.
Use the metric with its neighbors
Repeat contact rate is strongest beside reopen rate, first contact resolution, customer effort, and verified completion. If first contact resolution improves while repeat contacts rise, inspect the definitions before celebrating. The first metric may rely on agent closure while the second observes customer behavior.
Use fixed cohort reporting so recent cases receive their full observation window. A weekly inbox report can show the mature cohort, the unknown matching rate, the repeat issue rate, repeat contact share, time to return, and top verified causes. Do not mix immature cases into the denominator just to publish a faster number.
The useful outcome is not a lower percentage on its own. It is fewer customers having to return because an expected result did not happen.
Frequently Asked Questions
Is repeat contact rate the inverse of first contact resolution
Not reliably. First contact resolution may use agent status, survey answers, or one touch rules. Repeat contact rate observes later customer behavior within a chosen window. Different eligibility and identity rules mean the two rates may move separately.
What is a good observation window
Use the shortest window that still captures a normal return for the issue. Publish it by issue group and keep it stable. Fast account tasks may need days, while fulfilment or external dependency cases may need longer.
Should multiple follow ups count more than once
For an issue based rate, no. Count the initial issue once in the numerator if it produces any confirmed repeat. Track the total number of repeat contacts separately to measure workload and customer looping.
What should happen when the same issue appears on another channel
Link it to the original need when identity and evidence are strong enough. The channel change should not erase the repeat. If the match is uncertain, classify it as unknown and review the matching rule.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy