Duplicate Tickets: The Complete Guide

Duplicate tickets are the most tolerated inefficiency in customer support, mostly because nobody measures them.

What causes duplicate tickets

The impatient second contact. Emails, hears nothing within their patience threshold, uses the web form too. The single most common cause, and it's a symptom of your first reply time.

Reply to a closed ticket. Many helpdesks open a new ticket rather than reopening. The customer thinks they continued a conversation.

Colleagues at one company. Two people report one outage. Technically two requesters, practically one problem.

Integrations and monitoring. The same alert filed twice by a system that retried.

Forwarded internally. A sales rep forwards a customer email, which arrives as a separate ticket alongside the customer own.

Suspended then recovered. The first email sat in suspension, so the customer wrote again. Two tickets, a day apart, that look unrelated.

What they cost

Handle time is the visible cost and the smallest one. At 10,000 tickets a month, 12% duplicates and four minutes each, you're burning about 80 agent hours a month.

The rest is harder to invoice and worse. Two agents give two answers, so the customer trusts you less. Volume metrics are inflated, so cost per ticket and first contact resolution both lie. One of the pair ages and breaches SLA without anyone noticing, since the customer already got an answer on the other.

How to measure your rate

The manual sample. Export a week of tickets, sort by requester and creation time, count pairs from the same person within a few hours. Do 200 tickets and extrapolate. An hour of work, and better than any guess.

The merge tag. In Zendesk, count tickets tagged closed_by_merge. That's your caught rate, not your true rate, and the gap between them is the interesting part.

Automatic measurement. Connect a detector and read the number. This is the only method that catches cross-channel and cross-requester pairs, which are exactly the ones humans miss.

The four ways teams handle it

Ignore it. Most common. Costs the most, feels free.

Ask agents to watch for them. Free, and it catches the easy pairs only: same subject, same person, same view. The expensive ones survive.

Build detection on the API. Works. It's a real project: identity matching, similarity scoring, thresholds, exclusions, rate limits, and ongoing maintenance as the queue changes.

Use a detector that merges. Continuous comparison against the open queue, merging through the native API, with rules you control. That's what Ticket Merger is.

FAQ

Frequently asked questions

How big is the duplicate ticket problem, typically?

Between 8% and 20% of an open queue, and the duplicate ticket problem is worst in teams with several intake channels, because the same person writes in twice through two doors.

What percentage of support tickets are duplicates?

Typically 8% to 20%. Teams running several inbound channels sit at the higher end, and almost everyone underestimates before measuring.

Can duplicates be prevented rather than merged?

Partly. Faster first replies, better auto-acknowledgements and clearer forms all reduce them. You can't prevent a person contacting you twice, so a share always has to be caught.

Is merging always the right answer?

No. When many customers report one outage, each needs their own reply. Merge same-request pairs, link genuine incident groups.