Threading Replies to the Right Ticket: Numbers, Headers and Merges

Thursday, 14:10, at Stonebridge Insurance. Omar is triaging and finds three tickets about one laptop. Ticket 5310, opened on Monday by Grace in claims: "laptop freezes when docked". Ticket 5347, opened on Wednesday, requester Hal, Grace's manager, subject "FW: laptop freezes when docked", body "Grace is still having this, can someone look?" Ticket 5360, opened an hour ago from Grace's own address, subject "Laptop", body "Any news? Still freezing." Lena owns 5310 and asked Grace on Tuesday which dock she has. Ben owns 5347 and has ordered a new dock. Nobody owns 5360. Grace has one laptop, one problem and three ticket numbers. The desk has two technicians working on it in different directions and one message from the requester that neither has seen.

Threading is the tool's act of recognising that an incoming message belongs to a ticket that already exists. The tool attaches the message there, as the next entry in that ticket's history, instead of creating a new one. When it works, one conversation is one ticket, however many messages it takes. When it fails, the conversation is cut into pieces with different numbers, different owners and different ideas about what has been agreed. The failures have a small number of causes that can all be tested in advance. This article is part of our Email-to-Ticket Done Right series. It is about the matching step. We cover how the tool decides a message is a reply, what breaks the decision, and what to do with the pieces.

It covers why one conversation must be one ticket, then how the tool recognises a reply, by number and by header. Next comes what breaks a thread, with a table, then the forward that loses both. We cover the reply that starts a second ticket, and how to merge it, then replies to resolved and closed tickets. Next come two numbers in one subject when a vendor's desk is involved, and the habits that keep threads whole. A short war story follows, then the threading test sheet to copy, in that order.

Why One Conversation Must Be One Ticket

A ticket is the record of one problem from the first message to the last, and everything the desk does with tickets assumes that is true. The owner is the person who has read the history; the priority was set by someone who read the first message. The status says what the desk is waiting for; the response time is measured from the first message to the first reply. Cut the conversation in two and every one of those is wrong on at least one of the halves. Ticket 5360 has no owner because it looks new. It will get a priority from someone who has not read 5310. Its response clock started an hour ago on a problem that is four days old.

The requester feels the split before the desk does. Grace replied to Lena's question on Tuesday, in her head. What she actually did was start a new message. So Lena is waiting for an answer that is sitting unowned in the new-ticket view. Grace is waiting for Lena. Both are patient people, and patience is exactly what makes a broken thread expensive, because nobody raises it until a manager forwards it. The parts of a ticket that make it the record, and why each one matters, are in The Anatomy of a Ticket. Threading is what keeps those parts attached to the right conversation when the conversation travels by mail.

The numbers go wrong too, more quietly. Three tickets for one problem is three in the volume count. Two of them are resolved in minutes when merged, which flatters the resolution time. And one requester receives three satisfaction surveys about one laptop. A desk that does not thread well reports more work, faster, than it does. It is the only kind of reporting error that nobody is in a hurry to fix.

How the Tool Recognises a Reply

The first mechanism is the number in the subject. When the tool sends anything about a ticket, it writes a marker containing the ticket number into the subject line, usually in brackets. That goes for the acknowledgment or a technician's reply. A requester who replies keeps the subject, because mail programs keep it. When the reply arrives the tool reads the subject, finds its own marker, and attaches the message to that number. It is simple, visible, and works across any mail system in the world, because every mail system in the world preserves the subject of a reply. It fails the moment someone edits the subject, which some people do, and the moment someone starts a fresh message, which everyone does eventually.

The second mechanism is hidden in the message headers. Every e-mail carries a unique identifier, assigned by the system that sent it, in a header the reader never sees. Every reply carries, in another hidden header, the identifier of the message it is answering, and often the whole chain of identifiers back to the start. The tool records the identifier of every message it sends and every message it receives on a ticket. When a new message arrives claiming to answer one of them, it threads by that claim. Headers survive an edited subject, a deleted number and a translated subject line. They do not survive a forward, a fresh message, or a mail gateway that rewrites them, and a few do.

Most tools use both, and the order matters. Some check the subject first and the headers second; some the reverse; a few trust only one. Some add a third test. They treat a message from the same sender with the same subject within a short time as a reply even with neither marker. Find out what yours does, in that order, by sending the test messages at the end of this article rather than by reading the documentation. The documentation describes the design and the test describes the behaviour. The two are usually the same. "Usually" is the word that justifies the afternoon.

What Breaks a Thread

A thread breaks when a message arrives with neither marker the tool can use, or with a marker the tool declines to trust. The table below lists the ways that happens, roughly in order of how often I have seen each. It shows what the tool is left to work with and what most tools do. "Most tools" is doing honest work in that column; the last column is the fix that works whatever your tool does. Every row is also a test case on the sheet at the end.

Two rows deserve a second look. The different-address row is where tools are most cautious, for a good reason. Consider a message from an address the ticket has never seen, claiming to be part of the ticket. That is exactly what a stranger adding themselves to someone else's conversation would look like. So some tools refuse to thread it and make it a new ticket or hold it. The gateway rows are where the mail system between the requester and the desk, which the desk does not control, changes the message in transit. Warning banners, external-sender tags and encryption gateways are all common, and each changes the subject or the headers or both. Where the gateway strips headers, the number in the subject is the only thread left, and the desk's job is to make sure it is always there.

The Forward That Loses Both

A forward is not a reply, and the whole difference is in the headers. When Hal forwarded Grace's thread to the desk, his mail program created a new message with a new identifier. It had no reference to anything Lena had sent and a subject beginning "FW:". It had no ticket number anywhere in it, because Grace had forwarded him her original message rather than the acknowledgment. The From line said Hal. The tool did the only thing it could: a new ticket, requester Hal, title "FW: laptop freezes when docked". Nothing malfunctioned. A forward looks to a mail system like a brand-new letter that happens to quote an old one.

Even when the number survives the forward, the requester does not. If Hal had forwarded the acknowledgment, the subject would have carried the number. Many tools would then have threaded his message onto 5310, with Hal appearing as a new participant on Grace's ticket, which is better. A few would still have made a new ticket because the sender did not match. Either way, the person who wrote the message is not the person with the problem. The ticket now has a requester who will receive every reply and forward it to Grace, until the day he does not. The hiding place this creates, a ticket filed under the wrong requester, is one of the four in Keeping Tickets From Hiding.

The fix is at first touch, and it is a habit rather than a setting. Any ticket whose title starts with "FW:" or "Fwd:" gets read to the bottom before anything else. The real requester and the real question are in the quoted text. The triager searches open tickets by the quoted sender's address and by the obvious words, finds 5310, and merges the forward into it. The triager corrects nothing about the requester because 5310 already has the right one. They reply once from 5310 to both Grace and Hal: "Hal, thanks; this is Grace's ticket 5310 and Lena has it; Grace, Lena needs to know which dock you have." Thirty seconds. The forward was a reasonable thing for Hal to do. And the only thing wrong with it is that mail has no way to say what it was.

The Reply That Starts a Second Ticket, and the Merge

The fresh message is the commonest break and the easiest to catch, because it looks like what it is. It has the same sender, the same words or nearly, a few days after an open ticket. Grace's "Laptop" from her own address with "still freezing" in the body is a reply in every sense except the technical one. The check that catches it is a search by sender before any e-mailed ticket is treated as new. That takes ten seconds and is part of the first-touch routine in Triage by Channel. The new-ticket view, sorted by requester, catches it too: two tickets from one person in one week are one problem until proven otherwise.

Once found, the second ticket is merged into the first. A merge folds one ticket into another so that there is one ticket, with one number, one requester and one history containing every message from both. The older ticket survives, because its number is the one the requester has been given and the one with the history, owner and priority already on it. Decide that rule once and never argue it at the desk: the older number wins, unless the older ticket has the wrong requester. In that case fix the requester first and then merge. Merging is for one conversation that was cut in two. Two different people reporting the same outage are linked, not merged, so that each still gets their own reply. The difference is drawn in the triage article and not repeated here.

What happens to the number that disappears is the part to test. In some tools, the merged-away number becomes an alias, so that a reply carrying it still lands on the surviving ticket. In others it simply stops existing, and a reply carrying it creates a third ticket. The requester, meanwhile, has an acknowledgment for 5360 in their mailbox and will reply to it. Tell them once, from the surviving ticket: "I've added this to your earlier request, 5310; please reply to messages with that number from now on." If you run QuerySolv, merging, linking and splitting are all ordinary operations on a ticket, and every ticket keeps its complete event history. That is what you want when the requester asks in a month what happened to the other number. In any tool, write one internal note saying "merged from 5360". That way, the stranger reading the ticket later is not puzzled by a reply to a question nobody asked.

The opposite operation exists too. A split takes one ticket that contains two requests and makes it two, each with its own owner and its own resolution. An example is "my laptop freezes, and while I have you, can I get access to the claims share". Split early, because the access request will be done in an hour and the laptop will take a week. A ticket that is half-resolved is a ticket nobody knows how to close. The requester gets one reply explaining the two numbers. People do not mind two numbers. They mind one number that never closes.

Replies to Resolved and Closed Tickets

A requester who replies "it's back" to a ticket the desk resolved last week is sending the most important message in the system. It must land on the ticket with the history, not in a new one. Most tools reopen a resolved ticket when the requester replies, and the reopen is counted. That is what you want, because a reopen is the desk learning that resolved did not mean fixed. What a reopen is telling you is its own subject; the threading job is only to make sure the reply arrives where it can tell you anything.

Closed is where tools diverge. Some reopen a closed ticket on any reply, however old. Some reopen within a window after closing and create a new ticket afterwards. Some always create a new ticket and link it to the old. None of these is wrong, and each has a cost. A reopen on a ticket closed eight months ago, about a problem that is really a new one, drags eight months of irrelevant history under a new fault. A new ticket with no link loses the history that would have solved it in a minute. The confirmation window is the gap between resolved and closed in which the requester is invited to say "not fixed". It is designed in Resolved vs Closed: The Confirmation Window. What your tool does with a reply on each side of that window is a thing to test, not assume. If you run QuerySolv, a requester's reply reopens a resolved or closed ticket. So the message lands on the history it belongs to and the reopen is counted. In any tool, decide what you want to happen and send the two test replies.

Two kinds of reply to a finished ticket are not reopens, and the desk should expect them. "Thanks, that's fixed" reopens the ticket in many tools, and the fix is a one-click close with a note, not a rule that ignores gratitude. An out-of-office reply to the resolution message reopens the ticket too, if it gets through the screening. That one is a screening problem rather than a threading one. It is dealt with in Loops and Auto-Reply Storms. The ticket cannot tell gratitude from a complaint. That is what the technician is for.

Two Numbers in One Subject

When the desk sends a ticket to a supplier whose support desk also numbers things, the subject line ends up with two markers. Each system must leave the other's alone. The desk's reply goes out with the desk's number. The supplier's tool reads it, issues its own number, and replies with both in the subject. The desk's tool finds its own marker, ignores the unfamiliar one, and threads. Most tools manage this, because each looks only for its own pattern. A few, when they find a marker they do not recognise, strip the subject back to plain text, and then the thread depends on headers alone. Test with your biggest supplier before the first real outage.

The practical rules are short. Write to the supplier from the ticket. That way, their reply comes back to the desk's address with the desk's number in it. A technician who e-mails a supplier from a personal mailbox has sent the thread out of the building with no way home. Put the desk's number first in the subject if the tool lets you choose. Some mail programs truncate long subjects on small screens, and a number at the end is the first thing cut. And read the two-system exchange for the loop risk. Two tools that both acknowledge new messages, each treating the other's acknowledgment as new, is the classic storm. And it starts with exactly this kind of thread.

Tickets moved between the desk's own departments keep their number in most tools, and the threading survives the move. The subject marker is the same and the headers are the same. What can change is the sending address, if the facilities queue replies from the facilities address and the ticket started at the IT one. In that case, a requester now has messages from two addresses about one number. That is harmless, as long as replies to either address reach a mailbox the tool reads. It is not harmless if the facilities address forwards to a person. Check that one too.

Habits That Keep Threads Whole

The technician's habits do more for threading than any setting, because the settings only handle the cases the tool can see. Reply from the ticket, always, so that every outgoing message carries the number and the headers the tool will later look for. Never edit the marker out of a subject, even when the subject is otherwise rewritten for clarity; rewrite the words, leave the brackets. When writing to anyone outside the desk about a ticket, a supplier, another department, the requester's manager, do it from the ticket. That way, their answer has a road back. And when a requester's fresh message arrives as a new ticket, merge first and reply second, from the survivor. That way, the requester's next reply has the right number on it.

The triager's habit is the search. Before a new e-mailed ticket is given an owner, the check is a search of open tickets by the sender's address. It includes a glance at the new-ticket view sorted by requester. That catches the fresh message, the forward and the different-address reply. Between them those are nearly every broken thread the tool will ever produce. It is ten seconds per ticket. On a desk receiving forty e-mailed tickets a day that is seven minutes. That is less time than one merge-and-apologise takes when the second ticket is found a week late.

The requester's habit is one sentence, taught by the acknowledgment and never by a memo: reply to the message with the number in it. They will do it most of the time, and the desk forgives the rest. I have watched a desk send a two-page guide on "correct ticket e-mail etiquette" to a whole company. It produced one reply, asking which ticket number to use for questions about the guide.

A Short War Story: The Receipt Printer at Northgate Retail

At Northgate Retail, a store manager called Arjun e-mailed the desk about a till receipt printer that printed blank paper. A technician called Mina took ticket 7412 and asked him by reply which of the store's three tills it was. Arjun answered by forwarding the whole exchange to his regional manager with "can you chase this?" The regional manager forwarded it to the desk. The forward became ticket 7431 with the regional manager as requester and no number in its subject. A second technician, Kwame, took it as new and urgent because it came from a regional manager. Over the next two days Mina, having had no reply, sent a replacement printer by courier from stock. During those days Kwame, having read the forward, reset the existing printer's driver remotely. So the store received a printer it no longer needed, two resolution messages that contradicted each other, and two satisfaction surveys. Arjun filled in one of the surveys. The courier cost, forty minutes of two technicians and a printer sitting in a stockroom were the small costs. The large one was that Arjun started phoning Kwame directly, and did so for a year. That was because he had concluded the desk did not know which of its own tickets was which. A forward with "FW:" in the title and the same words as an open ticket is a merge waiting at first touch. A search by store name would have found it in ten seconds.

The Threading Test Sheet

The sheet below is a set of twelve messages to send through the desk's mailbox from two ordinary mail accounts. One is inside the organisation and one outside, with a colleague playing the third person for the forwards. Each line says what to send, what should happen, and leaves room for what did. The point is not to get twelve passes. Several lines have no right answer and the sheet only asks you to record what your tool does. That way, the triage habits can be set to match. Run it once at setup, and again after any change to the mail system, the tool, or the gateway in between. Keep the completed sheet with the mailbox setup record.

THREADING TEST SHEET — ONE PAGE
Desk: ______________   Tool: ______________   Run by: ____________   Date: ________
Inside test address: ______________________   Outside test address: ______________________
Third person for forwards: ______________

Start: send one plain message from the outside address; note the ticket number: ________
       and keep the acknowledgment; it is the message most tests reply to.

#   Send                                                    Expect                    Observed   Pass
1   Reply to the acknowledgment, change nothing             Joins the ticket          ________   [ ]
2   Reply, delete the number from the subject               Joins (headers)           ________   [ ]
3   Reply, replace the whole subject with "hello"           Joins (headers)           ________   [ ]
4   Fresh message, same subject, no number                  New ticket                ________   [ ]
5   Reply from the inside address to the outside's ack      Record it:                ________   [ ]
6   Third person forwards the acknowledgment                Record it:                ________   [ ]
7   Third person forwards the original (no number)          New ticket, wrong         ________   [ ]
                                                            requester; then merge
8   Fresh message with the number typed into the subject    Record it:                ________   [ ]
9   Resolve the ticket; requester replies "not fixed"       Reopens                   ________   [ ]
10  Close the ticket; requester replies a day later         Record it:                ________   [ ]
11  Reply with a second bracketed number added, as a        Joins the ticket          ________   [ ]
    supplier's desk would
12  After merging test 7's ticket into the original,        Record it:                ________   [ ]
    reply to the merged-away number

MERGE CHECK (after test 7)
  [ ] Survivor is the older ticket      [ ] Both histories visible on the survivor
  [ ] Attachments from both present     [ ] Requester on the survivor is correct
  [ ] Can the merge be undone?  [ ] yes  [ ] no  (read both tickets first if no)

WHAT THE DESK WILL DO ABOUT EACH "RECORD IT" RESULT
  Different address (5): ______________________________________________
  Forwarded ack (6):     ______________________________________________
  Hand-typed number (8): ______________________________________________
  Closed ticket (10):    ______________________________________________
  Merged-away number (12): ____________________________________________

Signed off: ____________   Re-test after: mail system change / tool update / gateway change

Omar ran the sheet at Stonebridge the following week. That was after merging 5347 and 5360 into 5310 and telling Grace and Hal the one number in one message. Test 5 made a new ticket, which told the desk why Grace's phone replies had been going astray. Test 12 made a third ticket, which told the desk to say the surviving number plainly every time it merged. Lena got her answer about the dock from the merged history, where it had been sitting in 5360 all along. Ben cancelled the order.

Frequently Asked Questions