A Triage Checklist You Can Laminate

Hana's first solo week on triage at Stonebridge Insurance begins at 08:40 on a Monday. Marcus, who trained her, is on a beach with his phone off. She has read everything. She knows the three questions, the four steps of the first touch, the five facts, the sweep times and the per-channel table. She could explain any of them to a new starter. What she has in front of her is twenty-six tickets and a feeling that all of it has quietly left her head. It is familiar to anyone who has done a thing for the first time without the person who taught them. She opens the first ticket. It says "Quote tool slow". She looks at it for a while.

What Hana needed at 08:40 was not more knowledge. It was something to hold: a page beside the keyboard that says what to do next, in order. That way, the knowing can happen on the page instead of in her head on a Monday. That is what a checklist is for. Pilots use one before every flight not because they have forgotten how to fly but because they have not. The day they are tired is the day the list earns its place. A triage checklist is the whole discipline of intake on one page. It is read top to bottom for every ticket until it is a habit and glanced at on bad mornings forever after. This article is part of our Ticket Intake & Triage series. This article is the last one, because it is the other five folded into a page.

This article covers why a checklist, and why it should be laminated. Next comes the checklist walked through in prose, with a pointer to the article that owns each line. Then come five real-looking tickets triaged step by step against it, and the four triage mistakes that every desk makes. We show the line on the page that stops each one. Then come how to introduce the list and keep it honest, a short war story, and the laminated checklist itself.

Why a Checklist, and Why Laminated

A checklist removes one decision from every ticket, which is the decision about what to do next. That is the decision that costs the most on a busy morning. The triager with a list does not wonder whether to reply first or set the priority first, whether to check for duplicates, or whether the time box has run out. The list says. The attention that would have gone on remembering goes on the ticket instead, which is where it was needed. On a quiet Tuesday the saving is small. At 08:40 on a Monday with twenty-six tickets and no Marcus, the saving is the morning.

The list is on paper, beside the keyboard, because a list in a document is a list that has to be found. A list that has to be found is consulted on the first day and never again. Paper is in the way, which is the point. Laminated, because it lives on a desk where coffee is drunk and will otherwise be illegible by the end of the month. One page, because the second page is never turned to. Everything on it is a line a tired person can read in two seconds, not a paragraph. The explanations live in the other five articles; the page is the index to them that fits under a mug.

The list is also a shared standard, which is its second job. When three people take turns at the triage hat, the list is the reason their first replies look alike, and their priorities mean the same thing. The owner who picks up a ticket cannot tell who triaged it. A desk whose triage changes with the triager has three desks. The laminated page is how it becomes one. (It is also, in my experience, the only document on a help desk that is never out of date, because nobody can edit it without a new sheet of plastic.)

The Checklist in Prose

The page has three parts: before the pass, per ticket, and after the pass. Before the pass is three lines. Say that you have the triage hat, in the chat tool or out loud, so the rest of the desk stops watching the queue. Open the new-ticket view sorted by time so the oldest is at the top. Read the subject lines of everything, without opening anything, so that the Urgent in position fourteen is found before position one is touched. Those three lines are the subject of Triage Rhythms for a Small Team. They are the lines Hana's twenty-six tickets needed first.

Per ticket is the long part, and it follows the first touch in order. Read the whole ticket, the attachment and the quoted history. Glance at the queue and search by the requester for the same thing. Decide what it is: incident, request, question, duplicate, not ours, or cannot tell. Decide who owns it: claim it only if you will work it before the next pass, otherwise route or assign by name. Decide how bad it is from how many are affected and how fast it grows. Set the priority from the desk's scale, never leaving the default. Send one human reply that says what you saw, what happens next and when they will hear again. Ask for every missing fact in one numbered list in that reply. Record the channel if the tool did not. Then stop, and move to the next ticket, under two minutes from opening this one. The three decisions are the subject of What Triage Actually Is. The reply and the time box are in First-Touch Discipline. The missing facts are in Gathering the Right Information Up Front. What each channel leaves out is in Triage by Channel.

After the pass is three lines again. Confirm that the unassigned view is empty, or that everything in it has a reply and a reason. Note the oldest unassigned ticket's age, which should be the age of the gap since the last sweep and nothing more. And write down the time of the next sweep where the desk can see it. The page then goes back under the mug until the next sweep, and the triager goes back to being a technician.

Five Tickets, Triaged Step by Step

The five tickets below are the kind that arrive at any small desk on any morning. Each is triaged against the page, line by line, with the time it took. They are chosen because each one tempts a different mistake. The first tempts a guess, the second tempts a long reply, and the third tempts a panic. The fourth tempts a new ticket where an old one exists. The fifth tempts a fix during triage, which in that one case is the right call. Read them with the page open; the laminated version is at the end.

Ticket One: "Printer not working!!"

TICKET 9147   Channel: e-mail   Logged: 08:12
From: Lena, claims team
Subject: Printer not working!!
Body: The printer isn't working again. Can someone come and look at it?
Attachment: none

Read the whole ticket: that is the whole ticket. Glance at the queue: no other printer tickets this morning; search by Lena: a ticket in the spring about a jam on the second-floor printer, closed. What is it: an incident, probably, and "again" says it has happened before. Who owns it: the desk's printers are owned by whoever claims them. Hana will claim it, because it is a screwdriver job and she will do the next pass first. How bad: one person, no deadline mentioned, Medium by the desk's scale, with a note that claims may print a lot. Three of the five facts are missing: where, what exactly, and whether anyone else is affected.

The reply goes out at 08:16 and asks for all three at once. It asks which printer, by the label on its front. It asks what it does when she prints, with a photo of the panel if it shows anything. And it asks whether colleagues are seeing the same. It says Hana has it as a Medium, will come up once she has done the morning's new tickets, and will be there by 10:00 either way. Nothing is fixed. Nothing is diagnosed. Hana did not walk to the second floor on the strength of the spring ticket. That is because the spring ticket is a guess and the label on the printer is a fact. Time: about two minutes. State at the end: incident, owner Hana, Medium, reply sent, three facts asked for once.

Ticket Two: "Access for new starter"

TICKET 9150   Channel: web form   Logged: 08:20
From: Priya, underwriting manager
Department chosen: IT    Priority chosen: High
Subject: Access for new starter
Body: Tomas starts on Monday in underwriting and needs the same access
as Sunita. Laptop is already here I think. Thanks.

Read the whole ticket: it is a request, not an incident, and the form has delivered the who and the what. Glance at the queue: there is a separate ticket from HR about Tomas's laptop, logged last week and owned by Marcus, which is the "I think". What is it: a request, for account and access, with an approval buried in it. That is because "the same access as Sunita" means someone must confirm that a new starter should see everything Sunita sees. Who owns it: the desk's accounts are set up by whoever has the hat, so Hana claims it. She links it to the laptop ticket so that both are visible from either. How bad: the requester chose High. The desk's scale says a request with a deadline of Monday, logged on Monday a week before, is Medium: nothing is broken, the deadline is real, and there is time.

The temptation on this ticket is to start setting up the account, which is forty minutes, or to write a long reply explaining the approval process, which is ten. Hana does neither. The reply at 08:24 says she has it as a Medium for Friday. It asks Priya to confirm by reply that Tomas should have the full finance share rather than the underwriting folder only, because Sunita has both. It says the laptop is already in hand under the other ticket. It also says, in one sentence, that she has logged it as Medium because nothing is blocked before Monday, and to tell her if that is wrong. Time: just over two minutes, because of the link. State: request, owner Hana, Medium, one question asked, linked to the laptop ticket, Priya told the priority and why.

Ticket Three: "URGENT whole team can't get into policy system"

TICKET 9151   Channel: e-mail   Logged: 08:31
From: Rafael, branch manager, Harbour Street branch
Subject: URGENT whole team can't get into policy system
Body: None of us can log into the policy system this morning, it just
spins. We have customers at 09:00. Please call me on 4410.

This is the ticket the subject-line read before the pass was for. It is fourteenth in the list and Hana found it at 08:41 because she read the subjects first. Read the whole ticket: who, what, where, since when and how bad are all present, which e-mail almost never manages. The requester has given a phone number. Glance at the queue: two more tickets from Harbour Street in the last ten minutes, one saying "system down?". The monitoring tool has not raised anything. Search: nothing from other branches yet. What is it: an incident, many users, one site at least. Who owns it: the policy system is owned by Dev on the application side. Hana assigns it to Dev by name and tells him in the chat tool. That is because a ticket assigned to someone who has not noticed is a ticket assigned to no one. How bad: a whole branch cannot work and customers arrive in nineteen minutes. Urgent on the desk's scale, with Emergency held back until a second branch reports.

The temptation here is to panic, which looks like phoning Rafael immediately and spending ten minutes being sympathetic, or like trying the login herself to see the spinning. Hana does the first touch instead. At 08:43 she links the two other Harbour Street tickets to this one under an incident name. She replies to all three requesters in one message saying the problem is known, it is Urgent, and Dev has it. The message says Rafael will get a call from Dev by 08:55. She then phones Rafael for forty seconds to say exactly that, because he asked for a call and the branch opens in seventeen minutes. Dev, who has seen the chat message, is already looking. Time: four minutes, which is over the box, and the right call for the one ticket in the pass that warranted it. State: incident, owner Dev, Urgent, three requesters replied to once, incident linked, phone call made and noted in the ticket.

Ticket Four: "Re: Re: laptop"

TICKET 9153   Channel: e-mail   Logged: 08:35
From: Olu, finance
Subject: Re: Re: laptop
Body: It's happening again. Same as before.
Quoted below: a thread of six messages ending three weeks ago,
in which Marcus replaced a docking station and closed ticket 8820.

Read the whole ticket, including the quoted history, because the quoted history is the ticket. Olu has replied to the closed thread about a docking station. The tool did not match the reply to ticket 8820 because the subject lost its number somewhere in three "Re:"s. It has arrived as a new ticket with a two-line body. What is it: not a new incident. It is a reopen of 8820 in disguise, or a duplicate of it, and either way it belongs with the six messages and Marcus's note about which docking station he fitted. Who owns it: Marcus owned the original and is away; Hana claims it. How bad: one person, a laptop that will not dock, work slowed rather than stopped; Medium.

The temptation is to treat it as a new ticket and ask "what is happening again?", which is one question in a conversation that will take all day. Hana merges 9153 into 8820, because they share a requester and the tool allows a merge in that case. That reopens the old ticket with the whole history attached. In a tool that could not merge, she would close 9153 with a note pointing at 8820 and reopen 8820 by hand. Then she sends one reply, on 8820, at 08:48. In it, she says she can see the docking problem has come back three weeks after the dock was replaced. Marcus is away so she has it. Could Olu reply with what the screen shows now and whether it is the same desk and the same dock? That way, she does not repeat what Marcus tried. She will be in touch by 11:00. Time: three minutes, most of it reading the thread. State: reopen, owner Hana, Medium, history intact, two facts asked for once.

Ticket Five: "How do I set an out-of-office?"

TICKET 9155   Channel: chat   Logged: 08:38
From: Sunita, underwriting
Transcript: "hi, how do I set an out of office, I'm off from Thursday"
Visitor status: still connected

Read the whole ticket: a question, complete, from an identified person who is still in the chat. What is it: a question with a one-line answer and an existing knowledge article with pictures. Who owns it: nobody needs to; it is the one exception on the page, the fix that costs no more than an acknowledgement. How bad: Low, and about to be nothing.

Hana writes the summary line, because "hi, how do I set an out of office" is not a subject. She replies in the chat at 08:39 with the three-click path and the link to the article. She says she is marking it resolved, and says to reply to the ticket if it does not work. In her tool, that reopens it. Sunita says thanks. Time: under a minute. State: question, resolved at first touch, summary written, closed with a reply and not with a status change alone. The exception has a strict edge, which is that the complete answer fitted in one line. "how do I set up the new laptop" would have been a request with an owner, and the page says so.

Five tickets, about twelve minutes, nothing fixed except the one-liner, and every requester has heard from a person. The Urgent was found at 08:41 and had an owner by 08:43. Hana's remaining twenty-one tickets go the same way, and by 09:25 the unassigned view is empty and the page is back under the mug. Marcus, on his beach, is not needed, which is the best review a training can get.

The Four Common Triage Mistakes

Four mistakes account for nearly every bad triage I have seen or done. The page is built so that one line catches each of them. The first is solving during triage: the triager reads a ticket, sees a fix, and does it. The rest of the queue waits unread while they do. It feels like efficiency and it is the opposite, because the ticket that could not wait is in the unread part. The line that catches it is the first one under "per ticket": nothing fixed, nothing diagnosed beyond one look, and the exception only for a one-line answer. Ticket five was the exception. Ticket one, with the spring jam and the screwdriver, was the temptation.

The second is over-asking. A ticket is missing one fact and the triager asks for it, then the next, then the next, over a day and a half of e-mail. Or the triager asks for all five when the ticket already had three. Both waste the requester's attention, which is the scarcest thing in the exchange. The line that catches it is "every missing fact in one numbered reply, and only the missing ones". Ticket one asked for three at once; ticket four asked for two; ticket three asked for nothing because nothing was missing.

The third is under-acknowledging. The triager sets the priority and the owner, and does not reply. The ticket looks finished to the desk while the requester is still waiting to find out whether a person exists. The auto-reply has told them nothing, and the status, which they cannot see or do not read, has told them less. The line that catches it is "one human reply: what I saw, what happens next, when they hear again". It is on the page twice, once in the per-ticket list and once in the after-pass check that every unassigned ticket has a reply. A ticket with an owner and no reply has been half-triaged, and half-triaged is the more dangerous half.

The fourth is guessing the priority, which is the quiet one. The triager cannot tell how bad a thing is, and instead of asking, sets Medium, because Medium is the default and the middle and feels safe. A guessed priority looks exactly like a decided one in the list, and the owner trusts it. The ticket that was really Urgent waits its turn behind the font questions. The line that catches it is "how bad: who else have you heard from, has work stopped, is there a deadline; if unsure, set the higher one and ask the settling question". The table pairs each mistake with what it looks like in the queue and the line on the page that stops it.

All four mistakes are made by good technicians. They are not failures of care; they are what careful people do when they are tired, interrupted, or new. They are the reason the page exists. A desk that has never made any of them has not been running long enough to be sure. Everybody else laminates the list.

Using the List for a Fortnight, Then Keeping It

Introduce the page by using it, not by presenting it. Print one per person and laminate them. For a fortnight ask everyone who wears the triage hat to run every ticket against it, line by line, however experienced they are. The experienced ones will find it slow for two days and then find that it is not. That is because the page only makes explicit what they were already doing, with one or two lines they had quietly dropped. The new ones will find it is the thing they needed at 08:40 on the first Monday. After the fortnight the page stays on the desk and is glanced at rather than read, which is what it is for.

Keep it honest with the reports, once a month, in fifteen minutes. Three numbers say whether the page is being followed. The first-response compliance figure, the share of tickets that got a human reply inside the target, catches under-acknowledging. If it falls, the reply line is being skipped. The count of tickets with more than three entries before an owner started work catches over-asking. And the number of priorities changed after the first touch, upward, catches guessing. A priority raised at 15:00 is a Medium that should have been asked about at 09:00. Most tools can produce the first; the other two usually mean a spreadsheet export and a sort, and are worth the ten minutes. The habits that keep the rest of the queue honest after triage, the weekly sweep of what is ageing, are in the Ticket Aging pillar. The page is the daily half.

Change the page only with a new sheet of plastic, which is a deliberate obstacle. A line gets added when a mistake the page did not catch has happened twice, and a line gets removed when nobody can say what it is for. The page in this article has been through that process on three desks and has not grown in two years, which is a better sign than it sounds. The discipline is small. The page is small. The queue is where the size goes.

A Short War Story: "Quote Tool Slow" at Stonebridge Insurance

The first ticket Hana looked at on that Monday morning was the one that said "Quote tool slow". That was before she found the page under the mug where Marcus had left it. The ticket came from one broker at the Harbour Street branch, with nothing else in it. Without the page she did what felt safe. She set it to Medium and moved on, meaning to ask about it later. The quote tool was the system the branch used to price and issue policies. Every broker in the branch was seeing the same thing. By the time Hana reached the ticket again at 14:40 the branch had been quoting by phone to head office all day. Rafael, the branch manager, counted eleven quotes that were not issued because the customer would not wait. He sent the count to the IT manager with the ticket number attached. The cause was a certificate that had expired overnight on the quoting server, fixed in a quarter of an hour once anyone looked. The cost was a day of one branch's business and a guessed priority that looked, in the list, exactly like a decided one. The line on the page that would have caught it is twelve words long: who else have you heard from, has work stopped, is there a deadline. Hana laminated her own copy that evening.

The Laminated Checklist

The page below is the checklist itself. Print it on one side, laminate it, and put it beside the keyboard of whoever has the triage hat. Fill in the three desk-specific lines, the sweep times, the priority words and the named owners of particular systems, before laminating. Those are the only lines that differ from desk to desk. Everything else is the same discipline the five articles in this series describe, in the order it happens.

TRIAGE CHECKLIST — ONE PAGE, EVERY TICKET
Desk: ______________   Sweep times: ______  ______  ______  ______
Priority words, lowest to highest: ______ ______ ______ ______ ______
System owners:  ____________ owns ____________   ____________ owns ____________
                ____________ owns ____________   ____________ owns ____________

BEFORE THE PASS
  [ ] Said "I have triage" where the desk can see it
  [ ] New-ticket view open, oldest first
  [ ] Read every subject line before opening any ticket; the worst one first

PER TICKET  (under two minutes, then the next one)
  Read
  [ ] Whole ticket, attachment, quoted history
  [ ] Queue glanced for the same thing; requester searched for the same thing
  Decide
  [ ] What is it:  incident / request / question / duplicate / not ours / cannot tell
  [ ] Who owns it: claim only if worked before the next pass; else route or
      assign by name, and tell them
  [ ] How bad:     how many affected, has work stopped, deadline, grows how fast
      Priority set from the desk scale, never left at the default
      If unsure: set the higher one, ask the settling question, lower it later
  Reply
  [ ] One human reply: what I saw, what happens next, when they hear again
  [ ] Every missing fact asked for in one numbered list; only the missing ones
  [ ] Priority told to the requester if they asked for a different one
  [ ] Duplicate: merged or linked, one reply to every requester
  Record
  [ ] Channel set if the tool did not set it; summary line written if it was "hi"
  Stop
  [ ] Nothing fixed, nothing diagnosed beyond one look
      Exception: a one-line answer or a link; send it, resolve with a reply
  [ ] Next ticket

AFTER THE PASS
  [ ] Unassigned view empty, or everything in it has a reply and a reason
  [ ] Oldest unassigned ticket no older than the gap since the last sweep
  [ ] Next sweep time written where the desk can see it

THE FOUR MISTAKES THIS PAGE EXISTS FOR
  Solving during triage.  Over-asking.  Under-acknowledging.  Guessing the priority.

Two adjustments by desk. A one-person desk strikes "say I have triage" and the owner lines, because there is nobody to tell and nobody to assign to. It keeps everything else, especially the sweep times, which are the only rhythm a solo desk has. A desk that runs continuous triage with a dedicated dispatcher replaces the before and after sections with "every twenty minutes: unassigned view empty?" and keeps the per-ticket section unchanged. That is because the per-ticket section is the discipline and the rest is the rhythm around it. In both cases the four mistakes stay at the bottom. They are the reason the page is there.

Twenty-six tickets, a Monday, and the trainer on a beach. With the page, Hana's morning is twelve minutes of worked examples and an empty unassigned view by 09:25. Without it, it is a guessed Medium and eleven quotes. The difference is one laminated sheet of paper, read top to bottom, under a mug.

Frequently Asked Questions