Merge tickets and handle duplicates

Duplicates are normal in support. Someone emails, hears nothing for an hour, and opens a chat. Now there are two tickets for one problem and two agents about to answer it.

Merging is how you collapse that back into one conversation.

Who this is for

Support agents doing triage, and anyone who notices two tickets describing the same thing.

Before you start

• Permission to update tickets.
• Both tickets open in front of you — merging is easier to get right when you can see which is which.

Decide which ticket survives before you merge
One ticket is the one that continues; the other folds into it. Pick the one the customer is most likely to be watching — usually the one they got a reply on, or the one with the SLA that matters. Choosing after the fact is harder than choosing first.

Merge two tickets

1. Confirm it is genuinely the same problem
   Same customer, same issue. Two different problems from one person are two tickets, however tempting it is to tidy them together.
2. Pick the surviving ticket
   Usually the one the customer has already been answered on, so the reply they are watching stays live.
3. Merge the duplicate into it
   The history comes across, so the conversation is complete in one place rather than split.
4. Tell the customer once
   If both tickets got a reply, send one message on the surviving ticket saying you are continuing there. Silence on the other one reads as being ignored.
5. Check the assignee is still right
   After merging, make sure one person owns the result. Two agents each thinking the other has it is the failure mode merging is meant to prevent.

What you get

• One conversation with the whole history rather than two partial ones.
• No two agents answering the same customer in parallel.
• Ticket counts that reflect real problems, not duplicate submissions.
• A single clear owner for the remaining work.

Frequently asked questions

Does merging lose any of the history?

The point of merging is that the history comes together on the surviving ticket, so the conversation reads as one thread.

What if I merge the wrong way round?

Decide which ticket survives before you merge rather than after — that is the step that is awkward to undo, which is why it is worth pausing on.

Should I merge two different problems from the same customer?

No. One ticket per problem. Merging unrelated issues makes the history confusing and the reporting wrong.

How do I stop duplicates happening?

Fast first responses are the real fix — most duplicates are a customer chasing silence. An automatic acknowledgement on arrival helps a lot.