🛠️ How-to tutorials

Merging duplicate tickets without breaking your reports

Updated 2026-09-24 · 5 min read · By the Convo360 team

In short

Merge duplicates rather than closing one and hoping. Notes and history should move to the surviving ticket, tags should combine, and the duplicate should be kept with a pointer to the survivor. Crucially, merged tickets must be excluded from your counts or every metric inflates.

Key takeaways

Duplicates are usually one person on two channels, not two problems.
Never delete the duplicate; keep it and point it at the survivor.
Merged tickets must be excluded from volume, timing and SLA numbers.
Merge early, before two agents have both invested work.

Where duplicates come from

Almost never from the system. They come from the customer, and usually from anxiety.

Somebody writes on WhatsApp about a delayed order. Two hours later, having had no reply, they send an email to your support address. The next morning they fill in the contact form on your website. To them this is one problem, escalated. To your desk it is three tickets, quite possibly with three different owners.

The second source is channel preference inside a household or a business. A purchase manager emails, and the person who actually needs the delivery messages your WhatsApp number. Same order, two threads, no obvious connection between them.

Both cases are worth understanding because they hint at the fix. A customer who writes on a second channel is usually telling you the first one was too slow.

A third source is your own routing. If a ticket is closed too early and the customer replies after the reopen window has passed, the reply opens a fresh ticket rather than reviving the old one. That is correct behaviour most of the time, and it does mean an aggressive closing habit quietly manufactures duplicates.

Why closing one is not good enough

The instinct is to close the duplicate and carry on in the other thread. It looks tidy and it loses information.

Whatever was written in the closed ticket, and whatever internal notes an agent left there, becomes invisible to whoever works the surviving one. If the duplicate was closed as resolved, your first-time-fix and resolution-time figures both quietly improve for a ticket nobody solved. And if the customer replies to the closed thread, you now have a fourth conversation.

Deleting it is worse still. An audit trail with holes in it is not an audit trail, and support records are exactly the thing you need intact when a dispute arrives months later.

There is a customer-facing cost too. Two open tickets means two agents forming two views of the problem, and sooner or later the customer receives two different answers. That is far more damaging than a slow reply, because it tells them nobody is really in charge of their issue.

It also doubles the satisfaction surveys. Asking somebody twice how you did on one problem is a small thing that reads as carelessness.

How merging works on Convo360

Open the duplicate, choose Merge into, and pick the ticket that should survive. Convo360 puts tickets from the same customer at the top of that list, since that is almost always the case you are handling.

What happens next is deliberate. The internal notes and the full event history move across to the surviving ticket, so nothing is stranded. The tags of both are combined. The duplicate is closed and marked as merged into the survivor rather than deleted, so the record remains. And the duplicate's link to its conversation is released, which keeps the one-open-ticket-per-conversation rule intact for whatever that customer writes next.

It all runs as a single transaction with both tickets locked, so two agents merging at once cannot produce a half-finished state.

Convo360 also refuses to merge into a ticket that was itself merged somewhere else. Without that rule you end up with chains, where a ticket points at a ticket that points at a third, and nobody can tell where the history ended up. Refusing the second hop keeps every merge one step and every trail readable.

Both tickets have to be in the same workspace, which sounds obvious and matters in a reseller or multi-brand setup where one login sees several.

The part that quietly breaks reports

This is the detail most teams discover late. If a merged duplicate still counts in your reports, every number moves in the wrong direction the moment your team starts merging properly.

Metric	What a counted duplicate does to it
Tickets opened	Inflated; one issue counted twice
Resolution time	Dragged down by a duplicate closed instantly
First-time fix	Overstated
SLA adherence	Distorted in both directions
Backlog	Overstated

Convo360 excludes merged tickets from every one of these: opened, resolved, backlog, reopened, first-response and resolution averages, SLA adherence, channel mix, the daily trend and per-agent performance. The duplicate still exists and can still be read; it simply stops being counted as a separate issue.

The effect is largest exactly when you least want it. Teams tend to start merging properly during a busy period, because that is when duplicates multiply. If merged tickets were still counted, your worst month would look artificially busy and your resolution time artificially good, which is the opposite of useful.

Merging early, and the habits that reduce duplicates

Merge as soon as you spot it. Once two agents have each replied and each made a promise, merging produces a confusing thread and the customer receives two different answers anyway.

A quick daily scan of the worklist for repeated customer names or numbers catches most duplicates within hours. It takes a minute and it is the highest-value minute in a support supervisor's day.

Reducing them is better than merging them. Two changes do most of the work: reply quickly enough that people do not try a second channel, and acknowledge on the channel they used so they know they were heard. Most duplicates are a customer checking whether their message landed anywhere at all.

If one channel generates duplicates far more than others, look at that channel's response time rather than at the customers. It is usually email, and usually because nobody owns the mailbox.

Watch the merge count itself as a signal. A month with many merges is telling you something about first response time on one channel, not about your team's tidiness. If merges fall after you speed up email replies, that confirms the diagnosis and is worth noting in the monthly review.

One habit is worth building: when you merge, leave an internal note saying why. Six weeks later, reading the surviving ticket, it is not always obvious that two threads were combined, and one sentence saves the next person a confused five minutes.

Step by step

Scan the worklist dailyLook for the same customer name, number or email appearing on more than one open ticket.
Decide which survivesKeep the ticket with the most history or the clearer channel, usually the one the customer used first.
Merge from the duplicateOpen the duplicate, choose Merge into, and pick the survivor. Notes, history and tags move across.
Tell the customer onceReply on the surviving channel confirming you have everything, so they stop chasing on the other one.
Check your response time on that channelRepeated duplicates from one channel usually mean that channel is too slow, not that customers are careless.

Keep one issue as one ticket

Start free in minutes — no code, no credit card. Bring your own AI keys and pay no per-message markup.

Start 14-day free trial →See pricing

Frequently asked questions

Can a merge be undone?

The duplicate is kept rather than deleted, so nothing is lost, but the notes and history have moved to the survivor. Treat a merge as a decision to make deliberately rather than something to experiment with.

What happens to the customer's conversation on the duplicate?

The conversation itself is untouched and the customer sees no change. The duplicate ticket releases its link to that conversation, so any new message opens a fresh ticket normally.

Can I merge tickets from different customers?

It is allowed, because two people sometimes write about one shared problem such as a company order. Both must be in the same workspace, and the surviving ticket must not itself have been merged.

Does merging affect satisfaction surveys?

The survey follows the surviving ticket, so the customer is asked once rather than twice. That is a meaningful improvement on closing duplicates, where two surveys for one issue is a common annoyance.

How do I spot duplicates automatically?

Sort the worklist by customer and scan for repeats, which catches most of them in under a minute. Automatic detection is harder than it sounds, because the same person often writes from a different address than the one on file.