Practical framework / 5 MIN READ
Combine duplicate contacts without losing an unresolved issue
Build an issue ledger before merging conversations that appear to describe the same problem.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A customer may contact a store through several channels while waiting for help. Combining those records can simplify the conversation, but a shared order number does not mean every request concerns the same issue.
What you will leave with: Create a duplicate-contact review that preserves issue scope, recipients, evidence and one clear response route.
Use this when
- Several agents are responding to the same apparent customer problem.
- A merge tool is being used to reduce the visible support queue.
This does not authorize merging customer identities, exposing private conversations or deleting records outside the approved retention process.
List the requests before counting the tickets
Read the actual requested outcomes in each conversation. One customer might ask about a late parcel in one ticket and an incorrect invoice in another. They share an order, yet resolving the parcel does not resolve the invoice. Create a short list of issues and mark which ticket contains the current evidence for each.
Verify the requester and authorized participants through the established process. Similar names or email signatures are not sufficient identity evidence. Keep separate cases where combining them would expose one person’s information to another or confuse different accounts, orders or responsibilities.
Check what the merge operation really changes
Zendesk states that ticket merges are permanent and have status restrictions. Before using any platform’s merge function, check its current behavior for comments, attachments, recipients, fields and reporting. Do not assume every field or open task survives in the destination record.
Choose the continuing ticket deliberately. It should preserve the active work and an appropriate communication route. Review the proposed merge message for information that should not be shared. If uncertainty remains, link related cases internally under the approved process instead of performing an irreversible operation simply to tidy the queue.
Carry forward an explicit unresolved-issue ledger
Record each remaining issue, the next action, responsible person and promised update time. Preserve important evidence by reference to the approved case record rather than scattering copies across personal notes. A summary should reduce rereading without replacing the underlying evidence.
Tell the customer which conversation will continue and what is still being handled, when that message is appropriate and authorized. Do not tell them everything is resolved because duplicate records have been consolidated. Stop parallel automated replies only through the approved workflow, checking that genuine open work still receives attention.
Test whether consolidation improved continuity
After the merge or internal linking, inspect the destination case as the next agent would. Can they identify every unresolved request, see the last promise and reply to the correct people? Check whether a status change accidentally removed the case from a working queue.
Review a small sample of consolidated cases for lost issues, duplicate responses and inappropriate recipient exposure. Report operational cleanup separately from actual resolutions. A lower ticket count caused by merges is not evidence that more customer problems were solved, and it should not be rewarded as if it were.
Make the reasoning concrete.
A fictional retailer receives an email about a delayed desk and a chat about the same order’s business invoice. An agent proposes merging and closing both because the delivery question has been answered.
Preserve two outcomes
Opening: Link or consolidate the contacts only after recording the outstanding invoice task and its owner.
Hypothesis: The customer receives one coherent conversation without losing work.
Risk: Recipient and platform behavior still require verification.
Close the apparent duplicate
Opening: Treat the shared order number as proof that both tickets are the same request.
Hypothesis: The queue becomes smaller immediately.
Risk: The unresolved invoice disappears behind a delivery answer.
Keep the invoice request active and use consolidation only if it preserves both the evidence and the remaining action.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Identity
Are the requester and participants verified for these records?
Issues
What distinct outcomes are being requested?
Destination
Which case will preserve active work?
Visibility
What information and recipients change during merging?
Continuity
Who owns each unresolved issue afterward?
Watch for the wrong conclusion.
- Merging solely because tickets share an order number.
- Assuming all fields and tasks transfer automatically.
- Reporting merged records as solved customer problems.
Your next action
Review three apparent duplicate contacts and write their unresolved-issue ledgers before deciding whether to merge.
Sources & scope
Frameworks, worksheets and proposed tests are original editorial synthesis. Examples are hypothetical and do not report measured outcomes. Source checking is not an independent audit of effectiveness. Platform features and applicable law can change. No named human author or reviewer is claimed.
- Zendesk: Merging tickets →Primary provider guidance · Supports: Documents irreversible ticket merging and status restrictions. The proposed issue ledger and privacy review are editorial safeguards, not a guarantee that merging is appropriate.