When Should Customer Support Merge Two Cases

A customer emails about a damaged parcel, then contacts support again because the first reply has not arrived. The queue now shows two cases, but the customer still has one unresolved problem.

Merge the cases only when they describe the same customer outcome and the surviving record can keep the full evidence. Do not merge simply because the customer, subject line, or product is the same. A merge is a case management decision, not a quick way to make the queue look smaller.

Merge only one unresolved outcome

Start with the outcome the customer is waiting for. If both cases end when the same damaged parcel is replaced, they are probably duplicates. If one case is about the damaged parcel and the other is about a refund that has not arrived, they may be related, but closing one into the other could hide separate work.

Microsoft documents case merging for multiple cases about the same issue, including cases opened through different channels. It also explains that activities, emails, and attachments are associated with the surviving case. That is useful, but it does not remove the need for judgment. Two messages can sound similar while requiring different owners, deadlines, or proof.

The safest question is not “Do these cases look alike?” It is “Would one verified resolution satisfy every open promise in both records?” If the answer is uncertain, keep them separate and link them for visibility.

Check the evidence before touching either case

Use the same preflight whether the duplicate was found by a person or flagged by automation. Confirm customer identity, affected order or asset, requested outcome, current status, owner, promised update, attachments, and any privacy restriction. Review the complete timeline, not only the newest message.

This is where a visible support workflow and one shared inbox matter. The person deciding can see whether two agents are already acting, whether the customer received conflicting promises, and whether one case contains information the other lacks. A matching email address is not enough when a household shares an account or a company has several contacts.

Choose the surviving record deliberately

The surviving case should not be whichever record is easiest to click. Prefer the record with the clearest customer identity, the earliest still valid promise, the correct owner, the most complete timeline, and the right service commitment. Before merging, copy or reconcile any field that the system will not move automatically.

This warning is practical, not theoretical. Microsoft's parent and child case guidance describes a separate relationship for tracking multiple issues for one customer or the same issue affecting several customers. It also lets an administrator decide whether closing a parent closes its children or whether every child must close first. That is a different operating choice from collapsing records into one case. Your preflight should therefore decide whether to merge, relate, or keep work separate before anyone clicks.

Record the source case identifiers, the destination case, the reason for the merge, who approved it, what was preserved, and what required manual reconciliation. Keep the customer identity in the customer record, but keep the case outcome in the case. Those are related records with different jobs.

Tell the customer what changed

The customer should not receive two agents, two reference points, and two promises after the merge. Send one plain update from the surviving case. Say that the two contacts concern the same request, name the next action, give the next expected update, and tell the customer which conversation to use.

Do not expose internal cleanup language or imply the customer caused the duplicate. They may have contacted again because the first channel was silent. If the two cases contained different promises, acknowledge the conflict and state which promise now applies. A merge without a customer update can leave the database tidy while the real experience stays confused.

Automation can help flag likely duplicates and pause parallel replies. It should not perform an irreversible merge from a loose subject match. Use workflow automation for evidence collection and a human decision for ambiguous cases. Restrict merge authority through clear security controls, especially when records contain sensitive information or different requesters.

Measure the merge without rewarding closure

Do not celebrate a higher merge count. A healthy process may reduce duplicates upstream, which makes the count fall. Review whether duplicate work stopped, all evidence remained available, the right owner completed the outcome, the customer avoided repeating information, and no second contact appeared because the merged case went quiet.

Track merged closures separately from solved outcomes. Microsoft marks the source case as cancelled with a merged status, while the surviving case continues. Your platform may use a different marker. The principle is the same: merging two records is not resolving the customer problem.

Use inbox reports to sample merges by channel, team, and source of duplication. When one form, mailbox, or automation keeps creating duplicates, repair that entry point. The best merge workflow is one that becomes less necessary over time.

Frequently Asked Questions

When are two support cases true duplicates?

They are true duplicates when they concern the same customer or affected account, the same underlying issue, and the same unresolved outcome. One completed action should satisfy every open promise in both records.

Should cases from different channels be merged?

They can be merged when identity and outcome match and the platform preserves the required history. Different channels alone do not make cases separate, but a channel match alone does not prove they are duplicates.

Which case should survive the merge?

Keep the case with the clearest identity, correct owner, valid service commitment, complete timeline, and earliest still active customer promise. Reconcile fields and attachments before the irreversible action.

Should duplicate detection merge cases automatically?

Automatic detection can create a review queue, but the final merge should require strong evidence or human confirmation. Subject lines and customer identifiers often produce false matches when two outcomes only look similar.