AI for duplicate case detection: is it the same incident?

Two contacts, one event

A customer writes: „I couldn't pay for my order”, then calls, and the agent records: „Customer is back about the payment error on yesterday's purchase”. Both tickets have the same order number, so they are one case. In another ticket the exact sentence „I couldn't pay for my order” appears, but the customer is describing a different purchase. That is a separate event, although the text is identical.

A useful suggestion shows both messages side by side with the order number and the time the problem occurred. The employee reads the earlier findings and confirms whether they are handling a further contact in the same case. A shared order number does not settle everything either: after shipping, a customer can report another, separate problem with the same purchase.

What a simpler change gives, and what training adds

In this count, linking channels and the order number give most of the effect for a fraction of the cost. Training makes sense at a larger scale or when the remaining errors are expensive. A manager also cares how much reading the suggestions take: if an agent goes through one similar message after another and reaches the findings no faster than today, further investment is not justified.

The set of training examples has to be maintained: when the process, the naming or the base model changes, the evaluation is repeated on the same test set. We put that cost into the quote together with the training itself.

First, what your current system can do

Start with order numbers, links between contacts and search in your current service system. If an agent cannot see the email during a phone call because the channels store data separately, you need to integrate the channels before a model even appears. When the data is available, compare search with a ready text-similarity model: Sentence Transformers describes paraphrase mining. Finding a related case and merging are separate actions, and Zendesk states that merged tickets cannot be un-merged, so the suggestion merges nothing on its own.

Where to start

The comparison covers cases not used for customisation: similar-sounding tickets about different events and real duplicates described in other words. Grouping complaints for quality analysis is a different goal, described in the article on sorting quality complaints. We run model customisation as part of private LLMs, and the application in which the employee sees the result beside its source as part of AI applications. For the free analysis, a few examples of an error that keeps coming back and a note on who corrects it today are enough.