Customer replies are opening new tickets instead of threading

Take one orphaned reply — a ticket whose body clearly quotes an answer you already sent — and open its raw source. Compare the Message-ID your helpdesk stamped on the outbound message against the In-Reply-To and References headers on the reply. That single comparison splits the problem into three, and only one of the three is fixed inside your helpdesk.

The distinction that matters commercially is between fixing the transport and merging afterwards. Merging is always available and always second best: it runs after a duplicate has already taken a queue slot, started its own timer and possibly been answered by a second agent. It also has the worse failure mode, because a wrong merge is visible to the customer and awkward to undo.

The confirming check: read the headers on 10 orphans

1. Collect 10 orphan tickets from the last 7 days where the body visibly quotes one of your replies. Fewer than 10 and you will generalise from a coincidence.
2. Open the raw source of each and record 7 fields: Message-ID, In-Reply-To, References, From, To, Reply-To and the subject exactly as received.
3. Find the outbound message each one is answering and record its Message-ID as your helpdesk sent it.
4. Test membership: is that outbound Message-ID present anywhere in the reply's References chain? This is the whole diagnosis, and it is a string comparison.
5. Test identity separately: does the From address exist on the requester's user record, and does the To address match the alias the thread was already on?
6. Tally the 10. A single dominant pattern means one fix. A spread across three patterns means you have three problems and should fix the transport one first.

The five signatures, and what each one means

Subject matching is a trap, and it fails in both directions

Every helpdesk offers subject-line matching as a fallback and it looks like a reasonable safety net. It is not. Reply prefixes are localised — a German client writes AW, a Swedish one SV, some clients add a space before the colon — and long subjects get truncated by intermediate systems, so the string you are matching on is not stable across the path.

The reverse failure is worse than a missed match. Two unrelated customers both sending a message titled with your product name and the word invoice will be threaded into one ticket, and now one customer can read the other's correspondence. Subject may only be used to break a tie between candidate threads that already belong to the same verified requester, inside a bounded window. It may never establish a thread on its own.

Fix the transport, or merge after the fact

These are different projects with different owners. Transport work is small, permanent and prevents the duplicate existing. Merge work is ongoing, probabilistic and cleans up after it. Do the first, and use the second only for the residue that a stripped-header path genuinely makes unrecoverable.

If you allow automatic merging at all, write the permission down as conditions rather than as a confidence score. A merge that satisfies all four of the conditions below is safe enough to run unattended; anything else is a suggestion a human accepts.

• Same verified requester. The sending address is on the same user record — not the same company, and not a fuzzy name match.
• Inside a bounded window. Something like 72 hours since the last activity on the target ticket. Beyond that, a customer writing about the same subject is more likely to have a genuinely new instance of the problem.
• No public reply yet on the newer ticket. Once an agent has answered it, merging silently deletes a conversation the customer can see.
• Same entitlement and same organisation. A merge that moves a ticket across an account boundary changes its response target and its visibility, which is a routing decision disguised as housekeeping.
• Everything else is a suggestion. Present it as a linked-ticket hint with the evidence, and let a human take 5 seconds over it.

Record the merge decision where it can be reported on and reversed — a field with a defined value set rather than a free-form tag, for the reasons argued in custom fields against tags for triage output. Without that, you cannot answer the only question that matters after three months: how often the automatic merge was wrong.

A model cannot recover a header a security gateway deleted. It can only guess, in front of the customer, at something the mail path already told you.

The decision tree

1. Do the orphans carry your Message-ID in their References chain? If yes, this is a helpdesk matching or window configuration problem. Fix it there and stop.
2. Are the headers missing on a specific set of customer domains? That is a gateway rewriting mail. You cannot change their security product, so add the plus-addressed reply-to and the visible reference token.
3. Do the References point at a message you did not send? Find the other system generating replyable notifications and either silence it or give it your token.
4. Is the From address simply unknown? Fix the identity, not the thread. Add the address to the existing user and the next reply threads on its own.
5. Is the subject the only thing you were matching on? Turn it off as a primary key today. The collision risk is a disclosure risk, not just a tidiness one.
6. Only for the residue after all of the above: enable automatic merging under the four conditions, and review a sample of merges weekly for the first month.

What this does not fix

• Runaway volume from two systems answering each other. That is a different fault with a different break, diagnosed in a mail loop between your system and theirs.
• The reported clock. One issue arriving as 3 tickets creates 3 first-reply timers, and merging afterwards does not always repair the breach already recorded — the timer's behaviour is set out in SLA breaches on tickets that arrived at 2am.
• Notifications from systems you do not control. If a support ticket has a shadow record in an engineering tracker, that tracker sends its own mail the customer may reply to — one of the costs weighed in whether support should file bugs straight into the tracker.

Threading is unglamorous plumbing, and it is worth insisting on before any conversational automation goes near the queue: an agent that answers the third fragment of a conversation without the first two will confidently contradict a colleague. Getting the transport right first is normal AI agents and automation groundwork within ticket and inbox triage and our SaaS and customer support practice. If you are evaluating someone to do it, whether they ask to see raw headers in the first conversation is a useful signal — more of those in choosing a development partner.

• email
• threading
• triage
• duplicates