Linking Repeat Chats to the Same Case

Decide what makes two chats the same case

A repeat contact is the same underlying problem, not the same customer or the same order. Write the matching rule: same customer, same issue, within a defined window, and no intervening resolution. Two chats about different items in one order are related but not the same case.

Use reason codes to distinguish a follow-up on an open case, a reopened resolved case, and a genuinely new issue. The code drives the workflow. Mixing them distorts the repeat-contact rate and sends the customer to the wrong queue.

Verify identity before merging records

Match on an authenticated account, order, or case reference, not on a name and a postcode. If the customer cannot verify, keep the conversations separate and link them as suspected duplicates for review. A false merge can expose one customer's details to another.

Record the verification method and the evidence used. If the customer contacts from a new channel, follow the destination channel's identity rule rather than assuming the chat verification carries over. The link between cases should show why the merge was allowed.

Use the specialist service role as a starting point for scope, sources, and evidence.

Choose reopen versus new case deliberately

Reopen when the original issue is unresolved or recurred within the warranty or service window. Create a new case when the customer has a different request, even if it references the old one. Attach the prior case as context so the agent does not have to ask for the whole history again.

Set a rule for cases closed by customer silence. A customer returning after the auto-close may need a reopen, not a new case, especially if the promised follow-up never happened. The record should show the original commitment and the new contact.

Measure repeat contacts with a clear denominator

Divide repeat contacts by eligible resolved cases in the same period, not by all chats. State the window, for example seven or thirty days. A rate that includes unrelated new issues will look worse than the service actually is, and a rate that counts only the same queue will miss cross-channel repeats.

Segment by issue type and agent or team. A high repeat rate on delivery exceptions may reflect an external carrier problem; a high rate on refunds may reflect an unclear first answer. The segmentation tells you where to look.

NIST SP 800-63B digital identity guidelines provides public guidance that can help your team test workflow assumptions.

Review a sample of merges and non-merges

Pull cases that were merged, cases that were left separate despite a similar customer, and cases reopened after auto-close. Check whether the identity evidence supported the decision and whether the customer had to repeat information. Both false merges and missed links are defects.

Look for patterns in the reason codes. If agents use other for a large share of repeats, the code list does not match the work. If one team never merges, the rule may be unclear or the tool may be hard to use.

Compare this approach with the next related workflow guide.

Close the loop with the customer

When a repeat contact is linked, tell the customer what happens next and whether they need to do anything. If the case is reopened, confirm the owner and the next update time. A silent merge may look efficient internally but leaves the customer unsure whether anyone is working on the issue.

After resolution, check whether the customer contacts again about the same problem. That is the outcome measure. A low merge rate with a low repeat rate is fine; a high merge rate with a high repeat rate means the case is being linked but not solved.

Common questions

Ready to create a clearer support role?

Bring the workflow that consumes the most attention. We will help shape the role, handoff, and review points.