The Handoff That Does Not Dump the Ticket

Thursday, 17:58. Lukas, who looks after the mail servers, gets the e-mail that says a ticket has been assigned to him, and opens 8812. The last internal note reads, in full: "Escalating, user says it's still broken. See ticket." He sees the ticket. It has fourteen entries. Three are from the requester asking whether anyone is looking at it, and two are internal notes that say "tried restart". There is a screenshot of an error dialog at a size where the text is a grey smear. There is a reply from the desk that says "we're looking into it" twice, three days apart. Lukas does the only thing he can, which is to write to the requester: "Could you describe what happens when you try to open the mailbox?" Her reply, at 18:20, begins "As I have already explained twice". She is right. She has. None of it reached him.

A handoff note is the paragraph that travels with an escalated ticket so that the person receiving it can start where you stopped instead of where the requester started. Dumping is transferring a ticket without one: the assignee changes, the work does not move, and the receiver inherits a history instead of a summary. This article is part of our Escalation Done Right series. The two kinds of escalation and the mechanics of moving versus flagging are in What Escalation Means. When to escalate is in Escalation Paths and Criteria. This article is about what goes with the ticket when it goes.

It covers the four shapes of a dump and why each happens, then the five things every receiver needs. Those are a summary, what was tried, what is being asked, the deadline, and the requester's state of mind. We cover each of the five in turn, with the sentence that does the job. Next we cover where the note goes in the tool and what the requester hears. Then comes the receiver's acknowledgment, which is the other half of the handoff. A short war story follows, then the escalation note itself, as a template you can paste into any ticket.

What Dumping Looks Like

Dumping comes in four shapes, and every desk has a favourite. The first is the empty transfer: the assignee changes and nothing else does. No note, no reply, no sign that a human was involved beyond the click. The receiver finds out from the tool's e-mail, opens the ticket, and begins reading from the top. That is the requester's original message, which is where the desk began three days ago. Everything the desk learned since is either in the technician's head or nowhere.

The second is "see ticket", which is the empty transfer with a note attached to make it look like a handoff. The note points at the history. And the history is fourteen entries that were written to the requester, to the technician's future self, or to nobody. A history is a record of what happened in the order it happened. A handoff is what the receiver needs to know in the order they need it. Pointing at one and calling it the other is like answering "where is the fault?" with "in the building".

The third is the novel: every detail the technician has, in paragraphs, with no summary at the top and no question at the bottom. The receiver reads four hundred words to discover that the ask is "please check the server side", which could have been the first line. Novels are written by conscientious people who were told to document everything and were never told what the reader would do with it. They are better than the empty transfer. In the same way, a map of the whole county is better than no map when you are looking for one street.

The fourth is the wrong question. "Can you take a look at this?" "Any ideas?" "Is this one of yours?" Each of those hands the receiver a ticket and a puzzle about what they are expected to do with it. Should they take it over, glance and advise, or confirm that it belongs to someone else? The receiver guesses, and the guess is usually "glance and advise", because that is the smallest commitment. So the ticket comes back with a line of advice. The technician who sent it, who wanted it taken, now has it again. The wrong question costs a round trip, and a round trip on a small desk is half a day.

What the Receiver Needs

A receiver needs five things, in roughly this order of importance. And a note that supplies all five is a handoff whatever else it leaves out. A summary: what is broken, for whom, since when, in two sentences. What was tried, with the result of each attempt, including what was ruled out. The ask: whether the receiver is being asked to take the ticket or to advise on it, and the one specific thing the sender wants done. The deadline: when the SLA clock runs out and, separately, when the requester actually needs it. And the requester's state of mind: how many times they have explained this, how they are coping, and what they have already been promised.

The table below says why each one matters from the receiver's side, and what the receiver ends up doing when it is missing. The right-hand column is the cost of the dump, and it is paid in the receiver's time, the requester's patience, or both.

The five fit in about a hundred and fifty words when written plainly. That is a two-minute job for a technician who has just spent thirty minutes on the ticket and has everything in their head. The same five take the receiver forty minutes to reconstruct from the history, if it can be done at all. The thing most often missing from a history is what was ruled out, because nobody writes down the things that did not work. Two minutes against forty is the whole economic argument for the handoff note. The ticket does not care who pays, but somebody does.

The Summary in Two Sentences

The summary says what is broken, for whom, since when, and what the symptom looks like. It does that in two sentences because the receiver is going to read it on a phone between two other things. "Hana in reception cannot open the shared mailbox Rooms; it fails with 'cannot be opened' on sign-in, for her only, since Monday morning. Everyone else in reception opens it normally." That is twenty-seven words. Before the second line, the receiver knows the scope (one person), the system (shared mailbox), the symptom (an error on open), and the time (since Monday).

The summary is written for someone who has not read the ticket and will not read it before deciding what to do. That means it does not say "the issue the user reported" or "the problem described below", because those point at the history. The history is what the summary exists to replace. The summary names the person, the system, the symptom and the time. It is rewritten by the sender, not pasted from the requester's message, because the requester wrote what they saw and the sender now knows what it means. "My e-mail is broken" becomes "one shared mailbox will not open for one user". That translation is the desk's work, and it should travel with the ticket.

Scope deserves its own sentence when it is not obvious. "For her only" and "everyone else opens it normally" are the two most valuable words in the example. They tell the mail specialist that the server is probably fine and the problem is on the account or the client. That halves the search before it starts. If the sender does not know the scope, the summary says that too: "not yet confirmed whether anyone else is affected". An honest gap is useful; a confident guess dressed as a fact sends the receiver down the wrong corridor.

What Was Tried, With Results

The list of what was tried is the part of the note that pays for itself. And the rule is that each item carries its result. "Removed and re-added her permission on the mailbox: no change. Cleared cached credentials and signed in again: same error. Rebuilt her mail profile: same error, so the profile is not the cause. Confirmed she can open her own mailbox: yes, so her account signs in." Four lines, four results, and one explicit conclusion. The receiver can see what has been ruled out, and ruling things out is most of what diagnosis is.

"Restarted" is the item that needs the most care, because it is the step most often written and least often useful. Restarted what, and when, and did the symptom change at all, even briefly? "Restarted the client at 12:30; error returned on first open" tells the receiver something. "Tried restart" tells them that something was restarted at some point, with an outcome they will have to ask about. The same goes for "checked settings": which settings, against what, and were any different. A list of verbs without objects or outcomes is the novel's cousin: it looks like work and reads like none.

Include what you deliberately did not try, and why. "Did not reset her password, because she is mid-way through a booking run and a reset would sign her out of everything." "Did not touch the mailbox's server-side settings, because that is yours." The receiver otherwise has to guess whether the obvious step was skipped by choice or by oversight. And the guess costs a message in each direction. A sentence about the thing you chose not to do is often the most senior-sounding sentence in the note, because it shows judgement rather than effort.

Gathering the right information at the start makes this list shorter and better. That is a triage subject rather than an escalation one; Gathering the Right Information Up Front covers what to ask in the first exchange so the facts are in the ticket before anyone tries anything. Consider a handoff note built on a ticket with the device name, the error text and the time of first failure already recorded. That is a different document from one built on "my e-mail is broken". The handoff inherits the intake.

The Ask: Take It or Advise Me

The ask is one line, and it answers two questions. Is the receiver being asked to take the ticket over, or to look and advise and hand it back? What is the one specific thing the sender wants done first? "Asking you to take this over; please check the mailbox's server-side permissions first." "Asking for advice only; the ticket stays with me; can you confirm whether the Rooms mailbox was migrated last week?" Each of those tells the receiver exactly what commitment they are being asked for. The receiver can say yes, no, or "yes but not until 15:00" without a round trip.

"Take it" and "advise me" are the two shapes of an escalation, and they need different things from the receiver. That is why the ask must say which. A take-it handoff is a functional escalation. The ticket moves, the receiver becomes the assignee and does the work, and the sender steps back from the technical side. An advise-me handoff keeps the ticket with the sender, who wants a specific piece of knowledge or a specific check and will carry on afterwards. In the tool the first is a reassignment and the second is often a note addressed to a person, or a brief transfer and return. Which one the sender wants decides whether the receiver should clear an hour or spend five minutes.

The specific first step is the part most senders leave out, on the grounds that the specialist will know what to do. The specialist will, eventually. But the sender has been inside the ticket for thirty minutes and the specialist has been inside it for none. The sender's best guess at the next step is worth writing down even if the specialist overrules it. "Please check the server-side permissions first" is a hypothesis, and a hypothesis is a place to start. A ticket with no suggested first step is a ticket that starts with the specialist re-reading the summary and thinking. They could have done that on the train if the note had given them something to think about.

Avoid the open question. "Any ideas?" asks the receiver to do the sender's thinking and gives them no way to know when they have done enough of it. "Is this one of yours?" asks for a ruling on ownership, which is the path table's job, and the path table is in Escalation Paths and Criteria. If the sender genuinely does not know whether the ticket belongs to the receiver, the ask says that plainly. "I think this is yours because the error is server-side; if not, please say whose" is still an ask with an answer.

The Deadline and the Clock

The deadline line carries two times, and the receiver needs both because they bite differently. The first is the SLA due time: when the ticket's resolution target expires, according to the desk's promise and the tool's clock. The second is the requester's real deadline. That is the moment after which the fix stops being useful. Examples are the month-end run on Monday at noon, the board meeting at 14:00, or the shift change at 06:00. Sometimes the clock runs out first; sometimes the requester's need does. The note says which, in one line: "SLA due 16:20 today; Hana needs the rooms booked for tomorrow's clinic by 17:00, so the real deadline is the SLA."

The clock does not restart on transfer, and the receiver needs to be told how much of it is left rather than assuming it is full. A four-hour resolution target that started at 12:05 and is handed over at 14:20 has an hour and forty minutes left. And the receiver who thinks they have four hours will breach it with a clear conscience. In most tools the countdown travels with the ticket, visible in the list and on the ticket itself. In those tools, a breach warning goes to whoever is the assignee at the time, which after a transfer is the receiver. The handoff note should still say the due time in words, because the receiver reads the note before they open the ticket. The note is also the one place where the two deadlines sit side by side.

When the real deadline is tighter than the clock, the note says so and says what the sender has already told the requester. "I have told Hana she will hear from one of us by 15:00" is a promise the receiver has just inherited. They should know about it before 15:00 rather than after. When the real deadline is impossible, the note says that too, so the receiver and the sender can decide together who tells the requester, and when. Which of them that is belongs to the next article in this series, Who Owns the Ticket After Escalation. The note's job is only to make sure that the promise and the clock are both visible to the person who now holds the ticket.

The Requester's State of Mind

The last of the five is the one that no tool field holds and that most often decides whether the escalation goes well. It is one or two sentences about the person. Those cover how many times they have explained the problem and what they have been promised. They cover whether the person is calm, worried, or on their fourth day of working around it. "Hana has explained this three times, is polite and tired, and has been told twice that we are looking into it; please do not ask her to describe it again, and please open by saying you have the full history." That sentence costs the sender fifteen seconds and saves the receiver the "as I have already explained" reply.

This is not gossip and it is not a judgement on the requester. And the note should be written so it could be read aloud to them without embarrassment. "Frustrated, understandably, after three days" is fine. Anything that mocks or diagnoses the requester is not, and it will be read. Ticket histories are read by people who were not meant to read them at the least convenient moment. The test is simple: write the sentence you would say to the specialist across the desk if the requester were standing beside you. The specialist needs to know how to open the conversation, and that is all the sentence is for.

The state of mind also includes the practical: how to reach the requester, when they are available, and whether anyone else is speaking for them. "Hana is at reception until 17:00, extension 204, and her manager Priya has also asked about this ticket." A receiver who phones at 17:10 and gets voicemail has lost a day. A receiver who did not know about Priya is surprised by an e-mail from a manager asking why nobody has replied to her. Both are avoidable with one line, and both happen weekly on desks that think of the handoff as a technical document. It is a technical document with a person in it.

Where the Note Goes, and the Acknowledgment

The handoff note is an internal note on the ticket, and nothing else. It is not an e-mail to the specialist, which leaves the ticket's history with a hole where the handoff should be. It is not a chat message, which disappears. It is not a reply to the requester, who should not see "rebuilt her profile" and "please check the server side". In most tools an internal note is never mailed to the requester. In those tools, the note can be candid about what was tried and about the state of mind without it leaving the building. If you are not certain how yours behaves, raise a test ticket to yourself and write a note on it before you trust the field. The note is written in the ticket, and the ticket is assigned. And the assignment e-mail that the receiver gets points at a ticket whose latest entry is the note. One place, one order, one reader.

The requester gets a separate, shorter message, written at the same time, that says three things. It names who now has the ticket, says they have the full history, and says when the requester will next hear something. "I have passed this to Lukas, who looks after the mail servers. He has everything we have tried so far, so you will not need to explain it again. One of us will update you by 15:00 either way." That message is the only sign the requester will get that anything happened, because the transfer itself is invisible to them. Skip it and the ticket looks, from outside, exactly as it did before, which is to say ignored.

The receiver's acknowledgment is the other half of the handoff, and a handoff without it is not finished. Within a stated time during working hours, an hour is reasonable, the receiver writes one internal note with three parts. It says they have the ticket and when they will first look at it properly. It says whether anything is missing from the handoff note. "Got it; first look at 15:30 after the change window; nothing missing, thanks for the ruled-out list." If the receiver cannot take the ticket, the acknowledgment says so and says who should, which is still an acknowledgment, and still better than silence. Most tools e-mail an agent when someone else assigns them a ticket, which means the receiver knows. It does not mean the sender knows the receiver knows, and the acknowledgment is how they find out.

The acknowledgment is where a thin note gets corrected without anyone being blamed. "Got it; could you add which steps you tried and what each did, so I do not repeat them?" is a question. It is answered in two minutes by a sender who still has the ticket in their head. The same question asked the next morning takes twenty minutes, because the sender has moved on to other tickets and the detail has gone. Desks that acknowledge quickly write better notes within a month, not because anyone enforces it, but because the questions arrive while the answers are still cheap.

A Short War Story: Three Handoffs and a Certificate at Bellweather Logistics

Bellweather Logistics ran a depot where every driver's handheld synced its route at 05:30. One Tuesday the handhelds at the north depot stopped syncing. That put twelve vans out forty minutes late while the dispatcher printed routes by hand. Jonas on the desk took the ticket at 05:50 and found that the handhelds showed a "secure connection failed" message. He wrote that down in his third internal note along with the fact that the south depot was syncing fine. Then, at the thirty-minute box, he transferred the ticket to the systems engineer with the note "escalating, handhelds not syncing, see ticket". The systems engineer, who read the first note and not the third, spent an hour on the sync server. The engineer transferred the ticket to the network engineer with "not the server, see ticket". The network engineer spent an hour on the depot's connection before transferring it back with "network is fine, see ticket". Ingrid, the lead, opened the ticket at 09:10 after a complaint from dispatch. She read all seven notes in order and found Jonas's third note. It named the error that pointed at the depot's expired certificate, a ten-minute fix. Two delivery runs went out late, the depot paid for an afternoon of overtime, and the fault had been correctly described by the first person to touch it. The lesson that went on the depot's wall was that the note is the handoff; the transfer is only the paperwork.

The Escalation Note

The template below is the whole note, with the five elements in the order the receiver needs them and a few supporting lines. Paste it into the internal note field, fill in every line, and delete none; a line that does not apply gets "none" or "not known", which is information. It should take about two minutes for a ticket you have just been working. If it takes longer than five the ticket has more unknowns than it should, and the note is telling you so. Keep it in the knowledge base so that new technicians find it on their first day.

ESCALATION NOTE — ONE SCREEN
Ticket: ________   From: ____________   To: ____________   Time: ______

HANDOFF TYPE
  [ ] Take over (ticket moves to the receiver, who becomes assignee)
  [ ] Advise and return (ticket stays with the sender; one answer needed)

SUMMARY (two sentences: what, for whom, since when, how it shows)
  ______________________________________________________________
  ______________________________________________________________
  Scope: [ ] one person  [ ] several: ____  [ ] whole team/site  [ ] not confirmed

TRIED, WITH RESULTS
  1. ____________________________ -> ______________________________
  2. ____________________________ -> ______________________________
  3. ____________________________ -> ______________________________
  Ruled out: _____________________________________________________
  Deliberately not tried (and why): ______________________________

ASKING YOU TO
  First step I suggest: __________________________________________
  The one answer I need (advise-and-return only): ________________

DEADLINES
  SLA due: __________   Time already used: ________
  Requester's real deadline: __________   Which bites first: ______
  Already promised to the requester: "______________________ by ____"

REQUESTER
  Name / contact / hours: ________________________________________
  Times explained so far: ___   Also asking: ____________________
  State of mind in one line: _____________________________________
  Please open by: ________________________________________________

ACKNOWLEDGE BY: ______ (internal note: got it / first look at / anything missing)

Before you press the button, the thirty-second check below catches the dump at the moment it is cheapest to fix. Read it once a day for a fortnight and it becomes the way you think about a transfer. After that the template is a formality you fill in faster than you can read the checklist.

• Could the receiver act on this note without opening the history?
• Does every "tried" item have a result?
• Does the note say whether to take the ticket or advise on it?
• Is there a suggested first step?
• Are both deadlines written, with the time already used?
• Does the receiver know how many times the requester has explained this?
• Has the requester been told who now has it and when they will hear next?
• Is the note an internal note, not a reply?

Lukas's ticket 8812, from the opening, would have arrived at 17:58 with a note that took the sending technician two minutes. It would have named the mailbox, the user, the error, the three steps and their results. It would have included the ask to check the server side, the SLA due time, and the line "she has explained this three times; please do not ask her again". He would have read it on his phone and acknowledged it with a first-look time of 08:30. He would have opened at 08:35 with "I have the full history from the desk, and I think I know where this is." Her reply would not have begun "As I have already explained". It would not have needed to begin at all.

Frequently Asked Questions