Summarizing Long Tickets and Handoffs Without Losing the Facts

Monday, 08:15, at Harbourview Clinic. Nadia has inherited ticket 8206 from Farah, who is on leave for a fortnight. The ticket has forty-three replies across sixteen days and three technicians. The reception workstation at the Westgate site keeps losing its connection to the patient-records application, a few times a day, for a minute at a time. The assistant has produced a summary. And it is a good one: "Intermittent loss of connection to the records application on reception workstation WG-RC2 at Westgate. Network cable and switch port replaced on day four; workstation network adapter driver updated on day nine; application reinstalled on day twelve; fault persists. Vendor case open since day thirteen, awaiting response. Requester: Joan, reception lead." Nadia reads it and knows exactly where the ticket stands. What she does not know is that on day eleven, in reply thirty-one, Joan wrote: "FYI it only seems to do it when the big scanner on the other desk is warming up." Nobody answered that line. The summary does not contain it. It is the only fact in the ticket that matters.

A summary is a short account of a long ticket. It covers what was asked, what has been tried and with what result, and where it stands now. It also covers what is waiting on whom, and what happens next. A handoff is the moment a ticket passes to someone who was not there for it. And it is where summaries earn their keep and where they do their damage. An assistant produces summaries quickly and well, and that is the problem rather than the solution. A good summary reads as complete, and the fact it dropped leaves no gap where it used to be. This article is part of our AI Assistants in Support series. It is about using summaries without being used by them.

It covers where a summary earns its place, then the five parts every summary has. Next come why summaries drop facts, and which facts they drop, then the stale summary and the tense problem. We cover checking the summary against the ticket history, which is the whole discipline, then turning the checked summary into a handoff note. Next come the two other audiences, the requester and the manager. A worked example from ticket 8206 follows, then a short war story, and the summary check to copy.

Where a Summary Earns Its Place

A summary is worth having whenever someone must act on a ticket they did not live through. The first case is the handoff. A shift ends, someone goes on leave, or a ticket is transferred between people or departments. And the receiver needs to know where it stands before the requester asks. The routine for the handover itself, what is said and what is written, is in The Shift Handover. The summary is the first thing the receiver reads. The second case is the escalation: a senior technician or a vendor is being asked to pick up a hard ticket. And their first read decides how seriously they take it. An escalation that arrives as "see ticket, it's all in there" is the dump that The Handoff That Does Not Dump describes. An escalation that arrives with a checked summary is a handoff.

The third case is the forty-reply ticket itself, with or without a handoff. Any ticket longer than a screen has stopped being read by the person working it. They read the last two replies and remember the rest, approximately. A summary written at reply twenty and checked at reply thirty gives the technician back the ticket they thought they had. Forty-three replies is not a ticket. It is a novel with a status field, and nobody rereads a novel to find out what was on page nine.

The fourth case is the question from outside. It might be a manager asking "where are we with the Westgate reception problem?" or a requester asking for an update. Or it might be a monthly review that wants one line per old ticket. Each of these wants a different summary, which is the subject of a later section. But each starts from the same checked account of the ticket. Write it once, check it once, and cut it to fit the audience.

The Five Parts of a Summary

Every useful summary has the same five parts, and a summary missing one of them is a story rather than a record. The ask: what the requester wanted, in roughly their words, with their name and site. What has been tried: each attempt, in order, with its outcome, including the ones that did nothing. Where it stands: the status, who owns it, and when it was last touched. What is waiting on whom: every open dependency, with the date it was asked and the date it was promised. And the next step: the one thing that should happen next, and who does it.

Dates are what turn the five parts from narrative into evidence. "Vendor case open, awaiting response" is a sentence. "Vendor case opened on day thirteen, no response by day sixteen, chase due on day seventeen" is something the receiver can act on at 08:15 on a Monday. Insist on dates in the "tried" and "waiting" parts especially, because those are where a summary goes vague first. I have written "vendor engaged" on a handoff note when what I meant was that I had found the vendor's phone number. A date would have exposed me, which is the point of the date.

The ask in the requester's words is the part most often rewritten and most often damaged by rewriting. "Intermittent loss of connection to the records application" is a tidy paraphrase of what Joan said. What Joan said, across several replies, was that it drops a few times a day, for about a minute. She said that the other reception workstation is fine, and that it seems to do it when the scanner is warming up. The tidy version is shorter. The original version has the clue in it. Keep at least one quoted line from the requester in every summary, and prefer the strange one.

Why Summaries Drop Facts

A summary is a selection, and the selection is made by prominence. What is repeated, structured, headed or emphasised survives. What is said once, briefly, in passing, by someone other than the requester, in a reply that was mostly about something else, does not. This is as true of human summaries as of assistant ones; the assistant is simply faster and smoother at it. And the smoothness is what removes the gap where the fact used to be. A human summary that forgot the scanner would read as thin. The assistant's summary reads as complete.

The facts most often dropped have a shape. They are short, usually a clause rather than a paragraph. They come from the edge of the conversation. That might be the requester's "by the way", a colleague copied in, an internal note that contradicts the public thread, a reply from a different address. They are conditional, "only when", "except on", "since the", because conditions read like asides and are in fact the diagnosis. And they are unanswered, which means nobody in the thread treated them as important. That is the strongest possible signal to a summarizer that they were not. (The fact that mattered is nearly always short. Important facts rarely get a paragraph; they get a clause.)

The other way a summary loses the truth is by converging on the usual story. Long tickets about intermittent faults tend to go cable, port, driver, reinstall, vendor. A summary written from the general pattern of such tickets will produce that sequence whether or not it is quite what happened here. The order gets tidied. A step that was planned becomes a step that was done. An attempt that half-worked becomes one that "persisted". None of these are lies; each is the most plausible version of the text. The check, below, is what separates plausible from true, and it is the only thing that does.

The Stale Summary

A summary describes the ticket as it was when the summary was written, and the ticket keeps moving. Joan replies, the vendor replies, and a colleague adds a note. And the summary at the top of the ticket still says "awaiting vendor response". Whoever reads the summary instead of the ticket now acts on a photograph. The fix is two habits. Date every summary, with the time, in its first line. And never pin a summary anywhere without the date showing. Date the summary. Yes, with the time. A summary without a date is a rumour.

Re-summarize at every handoff and every escalation, not on a schedule. A summary is made for a reader who is about to act. And the moment before they act is the only moment it needs to be fresh. Between handoffs the ticket's own history is the record. The summary is a convenience that may be out of date. That is fine as long as it says when it was taken. The receiver's first act, every time, is to read the date on the summary and then read every reply after it.

Checking the Summary Against the History

The check is the discipline that makes an assistant summary safe to use. And it is mechanical enough to do at 08:15 before coffee. Read the summary first, so you know what it claims. Then open the ticket history and scan it, not for everything, but for three things. Look at the last message from the requester, the oldest question in the thread that nobody answered, and every internal note. Those three places are where dropped facts live, and reading them takes a few minutes on a forty-reply ticket. If you run QuerySolv, the event history on the ticket is the record you are checking against. Every reply, internal note, handoff and status change is there in order. So the check is a scroll rather than a reconstruction from three mailboxes.

Then do the matching. For each of the five parts of the summary, find the line in the history that supports it. "Switch port replaced on day four" should correspond to a reply or note on day four that says so. If the nearest thing is a note that says "will ask facilities about the port", the summary has promoted a plan to a fact. In that case, the summary gets corrected. Anything in the summary with no supporting line is deleted or marked unconfirmed. Then do the reverse. Anything in the history that would change the next step and is not in the summary gets added, in the words it was said in. Joan's line about the scanner changes the next step from "chase the vendor" to "stand next to the scanner and watch". So it goes in, quoted.

Write the corrected summary as a new internal note, with your name, the date and time. Add one line saying what the check changed: "Added requester's observation from reply 31; corrected port replacement from planned to done." That note is now the summary, and the assistant's version is the draft it was made from. The difference between them is worth keeping, because over a month it tells you which kinds of fact your summaries drop. That is a better guide to what to watch for than any general list, this one included.

From Summary to Handoff Note

A checked summary is most of a handoff note, and the rest is two lines. They cover what the receiver should do first, and what the sender would want to know if the positions were reversed. "First: ask Joan what time the scanner is switched on and be at the Westgate desk for it. If asked by the practice manager, we have not yet told Joan the vendor has gone quiet." The handoff note is written for someone who was not there, which is the whole craft of Notes for the Stranger. The summary is the part the stranger reads first.

Keep the handoff note separate from the ticket's working notes and from the resolution note at close. Working notes are written as the work happens and are allowed to be messy. The handoff note is a clean account written for a transition. The resolution note, written once at the end, says what was wrong, what fixed it and how to tell if it returns. It is a different document with a different reader, covered in Resolution Notes Worth Reading Later. An assistant summary is sometimes offered as a substitute for the resolution note. It is not one. It describes the journey; the resolution note describes the destination, and the destination is the part the next technician with the same symptom needs.

Two Other Audiences

The requester sometimes needs a summary of their own ticket, usually when they ask "can you remind me where this is?" after a fortnight. The summary they get is the five parts rewritten for them. It has no internal notes, no vendor case numbers they cannot use, no colleague's name they do not know, and a next step with a date. Have the assistant draft it from the checked summary rather than from the raw ticket. Review it as a reply under the rules in Drafting Replies With a Human Reviewer. A summary sent to a requester is a reply, with promises in it, and the last sentence rule applies.

The manager wants one paragraph, and the paragraph is the next step and its date with the ask in front of it. "Westgate reception workstation dropping the records connection since the fourth; cable, port, driver and reinstall ruled out; new lead from the requester about a scanner on the same desk, being tested Tuesday morning; vendor case open as a fallback." That is four lines. It answers the question that was asked, and it contains nothing the manager will have to ask about. The longer version is in the ticket if they want it. They will not want it.

Worked Example: Checking Ticket 8206

The table below is Nadia's check on the assistant's summary of ticket 8206, line by line. The left column is what the summary said. The middle is the line in the history that supports or contradicts it. And the right is the verdict. The check took her eleven minutes, most of it reading the three places where dropped facts live. The last row is the one the summary did not have.

Three of six lines changed and one was added, which is about what a check on a long ticket finds. None of the summary's lines were invented; two were tidied past the truth and one was a plan recorded as a result. The added line changed the next step, which is the only test that matters. A dropped fact that would not have changed what the receiver did next is a footnote. A dropped fact that would have is the ticket.

A Short War Story: The Dropped Line at Bellweather Logistics

At Bellweather Logistics, a technician called Marcus handed a warehouse ticket to his colleague Elena before a week's leave. It came with an assistant summary that read "handheld scanners at dock B losing wireless connection; two scanners swapped; access point rebooted; fault persists; recommend replacing remaining scanners." The summary was accurate about everything it mentioned. It did not mention reply nineteen, from the night supervisor. That reply said the drops only happened between about two and four in the morning, when the refrigeration compressors on the dock cycled. Nobody had replied to it, and it was one line in a message mostly about overtime. Elena, acting on the summary, ordered and configured four replacement scanners over the following week. The cost was roughly a week of her time and the price of four devices. Meanwhile, the night shift counted stock by hand. The drops continued, which the night supervisor described in his next message as "not a surprise". The fault was interference from the compressor motors on the access point's channel, fixed in twenty minutes once anyone read reply nineteen. Bellweather's lesson was written into the handoff routine as one rule. Before a summary is handed on, the receiver reads every message from someone who is not the requester. The fact that mattered came from the night shift and the summary had been told to listen to days.

The Summary Check

The check is run by the receiver of a handoff or the recipient of an escalation, on the assistant's summary, before they act on it. And it should take ten to fifteen minutes on a forty-reply ticket and less on a shorter one. The first block is the three places dropped facts live; the second is the line-by-line match; the third is the corrected note. Fill it in once as a sheet while the habit forms; after a month most people run it in their head and write only the last block.

THE SUMMARY CHECK — BEFORE ACTING ON A SUMMARY
Ticket: ________   Summary dated: ________ ____:____   Checked by: ______________

1. THE THREE PLACES (read these in full)
   [ ] Last message from the requester, dated ________ : anything new? ______________
   [ ] Oldest question in the thread nobody answered: ______________________________
   [ ] Every internal note read; any that contradicts the public thread: __________
   [ ] Messages from anyone who is not the requester (colleague, supplier, night
       shift, another site): ______________________________

2. LINE BY LINE (one row per summary line)
   Summary says                       History says (reply or note, date)     Verdict
   ______________________________     ______________________________         keep / fix / drop
   ______________________________     ______________________________         keep / fix / drop
   ______________________________     ______________________________         keep / fix / drop
   ______________________________     ______________________________         keep / fix / drop
   [ ] Each "done" in the summary has a line in the history saying it was done
   [ ] Each "waiting on" has the date asked and the date promised
   [ ] At least one quoted line from the requester survives, preferably the odd one

3. THE CORRECTED NOTE (written as an internal note, signed and dated)
   Ask (requester's words): ____________________________________________
   Tried, in order, with dates and outcomes: ____________________________
   Stands: status ________  owner ________  last touched ________
   Waiting on: ____________  asked ________  promised ________
   Next step, and who: ______________________________________________
   What this check changed: ___________________________________________

Nadia was at the Westgate desk at 08:40 on the Tuesday when Joan switched the document scanner on. The records application dropped for fifty seconds while the scanner's lamp warmed. The scanner and the workstation's network adapter shared a powered hub under the desk, and the scanner's start-up draw was enough to reset the adapter. Nadia moved the adapter to a port on the workstation itself and the fault did not recur. The fix took four minutes. Finding it had taken sixteen days, forty-three replies and a summary that was accurate about everything except one line. Joan had typed that line on day eleven and nobody had answered. The assistant had summarized the ticket. Nadia had read it.

Frequently Asked Questions