Triage Rhythms for a Small Team

Monday, 08:30, the four-person desk at Tollgate Foods. Ingrid opens the queue, sees nineteen new tickets from the weekend, and starts reading. Bram opens the queue, sees the same nineteen, and starts reading. Yusuf is on the phone to the bakery about a scale that will not calibrate, and Ana is finishing the laptop rebuild she promised for 09:00. By 09:15 Ingrid has read twelve tickets and replied to none, because she assumed Bram was doing the replies. Bram has read twelve tickets and replied to none, because he assumed Ingrid was. Ticket 4418, logged at 07:40 by the dispatch supervisor, says the pallet-label printer in the loading bay is dead and lorries are waiting. It is the fourteenth ticket. Nobody has reached it.

The desk has four capable people, a good tool and a first-response target of one hour. What it does not have is an answer to the question "who is triaging right now?" Without that answer the other three things do not matter. A triage rhythm is the agreed pattern of when new tickets get their first touch and who gives it. That includes the times, the person, how the person changes, and what happens when they are not there. This article is part of our Ticket Intake & Triage series, and it is about the rhythm rather than the touch. What the triager does to each ticket is in First-Touch Discipline. This is about making sure somebody is doing it.

It covers why a rhythm matters more than a rule. Then come continuous triage and triage by sweeps, with the strengths and costs of each. It covers the hybrid that most small desks settle on, the triage hat and how it rotates, and the dispatcher model against everyone-triages. Then it covers how much triage time a desk actually needs and what to do on the day the triager is away. It ends with making the rhythm visible, a short war story, and a weekly triage rota with daily sweep times to copy.

Why a Rhythm Matters More Than a Rule

"Everyone keeps an eye on new tickets" is the rule most small desks start with, and it fails for a reason that has nothing to do with effort. When four people are each responsible for the same thing, each of them is reasonable to assume one of the other three has it. The assumption is correct in that all four are making it. The queue is being watched by everyone and triaged by no one. Responsibility that is shared evenly is responsibility that is held by nobody in particular, and new tickets are the first thing to feel it.

A rhythm replaces "everyone" with a name and "keeps an eye on" with a time. At 08:30, Ingrid triages. At 11:00, Ingrid triages. In between, if something Urgent arrives, Ingrid is the one who sees it, because Ingrid is the one looking. Bram, Yusuf and Ana are free to do their actual work, and free of the low-grade guilt of a queue they are supposed to be watching. That is a kind of relief that is easy to underrate. The rhythm costs one person's attention for a known number of minutes. The rule costs four people's attention all day, and produces nothing.

The rhythm also makes the first-response promise keepable. A desk that promises a human reply inside an hour needs someone to look at new tickets at least every hour, during working time, without exception. That is a schedule, and a schedule needs a name on it. Without the rhythm, the promise is kept on quiet days and broken on the days it mattered, and nobody can say afterwards why, because nobody was assigned to keep it.

Continuous Triage

Continuous triage means one person watches the new-ticket view all day and touches each ticket within minutes of its arrival. Nothing waits. The first reply goes out while the requester is still at their desk. The duplicate is merged before the second requester has finished typing. The Urgent is found at 07:41 rather than at the next sweep. For the requester, it is the best experience a desk can offer. For a desk with a tight first-response target it is the only pattern that meets the target on a bad morning.

The cost is that person's day. Watching a queue is not a background task; it is a foreground task that looks like one. The person on continuous triage cannot do a laptop rebuild, a server patch, or anything else that needs twenty uninterrupted minutes. The queue interrupts them at its own rhythm, which is random. If they try to do real work anyway, they end up with the half-eye problem. The queue is open in a second window, glanced at between steps. In that case, the glance stops happening at the exact moment the real work gets absorbing. The ticket that arrives during the absorbing part waits forty minutes, which is longer than a sweep would have made it wait.

Continuous triage therefore suits two kinds of desk. The first is a desk large enough to spare one person from fixing for a whole shift, which in practice means five or six people or more. The second is a desk where the triager's other work is itself interruptible: knowledge-base writing, report preparation, the kind of administration that can be dropped and picked up. A desk of three where everyone is a technician cannot run continuous triage without one of them doing nothing else. And a three-person desk cannot spare a third of itself.

If continuous triage is the goal, the tool should make the watching cheap. Three things turn a second window into something that can actually be glanced at. One is a list that updates itself without a refresh. Another is a view that shows only unassigned work. The last is a counter that says how many tickets are waiting on the desk right now. Most tools can do all three in some form. They offer a list that refreshes on its own or a saved filter for unassigned tickets. They also offer a dashboard or counter for what is waiting on the desk, overdue, or due within the hour. If yours has none of them, a saved search for "unassigned, newest first" pinned in a browser tab is the same thing with one more click. Whatever the tool, set up the view once so the glance takes two seconds and not twenty.

Triage by Sweeps

A triage sweep is a fixed time at which the person wearing the triage hat stops whatever they are doing, opens the new-ticket view, first-touches everything in it, and returns to their work. Between sweeps, the queue is not watched. Four sweeps a day, at 08:30, 11:00, 13:30 and 15:30, means no ticket waits more than about two and a half hours for a human reply during working time. The triager spends the other six hours doing the work that the sweeps assign.

The strength of sweeps is that they protect deep work on a desk too small to spare anyone. The person with the hat is a full technician who happens to also triage four times a day, for fifteen minutes each time. The whole desk knows when the sweeps are, so a colleague who sees a new ticket at 10:20 does not need to wonder whether anyone will see it. It will be seen at 11:00, by a named person, and that is enough for a Medium. The sweeps are also easy to hand over: "you have the 13:30 and the 15:30" is a complete instruction.

The cost is the gap. A ticket logged at 08:35 waits until 11:00 for a first touch. If the desk's first-response target for High is one hour, the sweep schedule has just broken the promise by design. Sweep times must be set from the first-response targets and not from the shape of the working day. The table shows how the longest gap between sweeps lines up against common first-response targets, and where a sweep-only pattern cannot keep the promise without help.

Read the table from the right. If the desk promises a fifteen-minute first response for Emergency, no sweep pattern keeps it. In that case, the honest options are continuous watching, a phone number that rings at a person, or a looser promise. If the tightest promise is an hour for High, four sweeps plus a short glance between them is enough. If the tightest promise is four hours, three sweeps a day keep it with room to spare. Setting the promise first and the sweep times second is the whole trick. The article that explains why the first-response promise is the one to protect is Response vs Resolution Targets.

The Hybrid Most Small Desks Settle On

Most desks of two to five people end up with sweeps for the ordinary work and a short glance between sweeps for the urgent. And that pattern is worth describing because it is what the rota at the end of this article assumes. The sweeps are full first touches: every new ticket read, replied to, prioritised and owned. The glance is twenty seconds, every twenty or thirty minutes. It is at a view filtered to show only new tickets at Urgent or Emergency, or the dashboard's needs-attention list. And the glance ends in one of two ways: nothing there, back to work; or something there, touch it now. Nothing else is touched at a glance. The Medium printer ticket waits for the sweep, as it should.

The glance is possible because the requester sets a priority on most forms and the mailbox has a default. And the view can filter on it. It is imperfect because requesters mark things Urgent that are not, and occasionally mark things Low that are not. The first error costs the triager a glance and a one-line reply lowering the priority. The second is caught at the next sweep, which is the price of not watching continuously, and the price is bounded by the gap. On a desk where the second error is unacceptable, because tickets come from a hospital ward or a trading floor, the answer is a phone route for emergencies, not a tighter sweep.

The hybrid has one rule that matters more than the times: the person wearing the hat is the only person doing the glance. If everyone glances, nobody does, for the reason in the opening scene. If one person glances, that person knows the glance is theirs. In that case, the rest of the desk knows that an Urgent at 10:20 will be seen by 10:40 by someone whose name they could say. (They can also stop glancing themselves, which most of them will find they were doing anyway, out of worry.)

The Triage Hat

The triage hat is the name for the role of being the one person responsible for first touch over a defined period. That could be a day, a half-day or a week. Whoever wears it does the sweeps and the glances, sends the first replies, sets the priorities, and routes and assigns. They are the person the rest of the desk means when they say "has that been triaged?" The hat is a role, not a person. It moves.

The hat moves for three reasons. First, so that everyone on the desk can triage, which means everyone learns the queue, the owners of each system, and what the desk's priority scale means in practice. A desk where one person has always done triage is a desk with a hero, and a hero's holiday is an outage. Second, so that triage does not become the permanent job of whoever is slowest to object, which on most desks is the most junior person. That is also the person least equipped to set priorities with confidence. Third, because triage is tiring in a way that fixing is not. A day of reading other people's problems and handing them out is a day of decisions, and a week of it is enough.

Rotate daily on a desk of four or more and weekly on a desk of two or three. Daily rotation spreads the load evenly and means nobody loses a whole week of project work. Weekly rotation means fewer handovers and a triager who gets the feel of the week's queue, which matters when the same incident produces tickets on Tuesday and Thursday. Either way, the rotation is written down a month ahead, and it names a deputy for each slot. A rota with no deputy column is a rota that assumes nobody is ever ill, which is optimistic even for a rota.

Tell the desk who has the hat, visibly, every day. A line on the shared calendar, a name on a whiteboard, a message in the chat tool at 08:30 saying "I have triage today; sweeps at 08:30, 11:00, 13:30, 15:30." It sounds like ceremony and it is the ceremony that stops the opening scene. When four people know Ingrid has the hat, Bram reads the queue for his own tickets and leaves the rest alone. In that case, Ingrid replies to all nineteen by 09:10, because she knows that nobody else will.

Dispatcher Versus Everyone-Triages

The two models at the ends of the scale have names, and knowing them helps when someone proposes one in a meeting. The dispatcher model has one person who triages and assigns all day and does little else. They are like the person at the door of the emergency department, full-time. It is continuous triage with a dedicated person. It is excellent when the desk can afford it. That generally means six people or more, or a desk whose ticket volume makes triage itself a full-time job. The dispatcher knows the queue better than anyone, routes with precision, and spots the pattern across tickets that a part-time triager misses. The dispatcher also becomes a hero if the role never rotates, and a bottleneck if they are the only one who understands the routing.

Everyone-triages is the opposite: there is no hat, and each person first-touches whatever new ticket they happen to open. It is the model every small desk uses before it has a word for it. And it fails in the way the opening scene shows. On its good days it is continuous triage by four people; on its ordinary days it is a queue that four people have each read a third of. It can be made to work on a desk of two who sit next to each other and talk constantly, because the talking is the coordination. It cannot be made to work for three or more without a rule, and the rule is the hat.

The honest middle for a desk of two to five is one hat, rotating, with everyone trained to wear it. It gives the desk a dispatcher for the length of a sweep and a technician for the rest of the day. And it gives every technician a turn at seeing the whole queue. The routing designs that sit under this choice, who gets which kind of ticket and whether the tool or a person decides, are the subject of Round-Robin vs Skill-Based Routing vs Just Claiming. The rhythm is about when a person looks; the routing is about where the ticket goes when they do.

How Much Triage Time a Desk Needs

Work it out once, from the ticket count, and the right rhythm usually becomes obvious. A first touch takes about ninety seconds per ticket once the first-reply texts are predefined and the owners are known. Call it two minutes to allow for the ones that need a question. Thirty tickets a day is an hour of triage, which fits comfortably in four fifteen-minute sweeps. Sixty tickets a day is two hours, which fits in four half-hour sweeps and starts to feel like a part-time role. A hundred and twenty tickets a day is four hours, which is half a person, and the desk should be asking whether the hat has become a job.

The count that matters is the count during the busiest hours, not the daily average. A desk that takes forty tickets a day with twenty of them between 08:00 and 09:30 has a Monday-morning sweep that takes forty minutes and a 15:30 sweep that takes five. Set the sweep lengths to match, and consider a second person on the first sweep of the day, which is where the weekend's tickets are waiting. The busiest-hours pattern is visible in most tools' reports, often as a heat map of hours against days. If yours cannot draw it, export a month of tickets with their logged times to a spreadsheet and count them by hour. That takes ten minutes and tells you where the sweeps should be heavy.

A one-person desk does the same arithmetic with a different conclusion. There is no rota, because there is one name, and there are no deputies, because there is nobody to deputise. The rhythm is the sweep times alone, and the only decision is how many. The solo administrator's version of this, with the phone and the walk-ups folded in, is in Running Support Solo. The short version is three sweeps, written down and kept even on the bad days, because the bad days are when the Urgent arrives.

The Day the Triager Is Away

Planned absence is handled by the rota, which names a deputy for every slot, and the deputy takes the hat on the day without a conversation. That is the entire mechanism, and it works because the rota was written when nobody was ill. The deputy's sweeps are the same times. The first-reply texts are the same predefined replies. And the rest of the desk hears "I have triage today" from a different voice at 08:30. If the deputy is also away, the rota's third column, the fallback, is whoever is first in. The fallback column exists so that this sentence does not have to be improvised at 08:45.

Unplanned absence is the test, and the rule for it is short enough to remember: if nobody has claimed the hat by 08:45, the first person to notice takes it and says so. "Ingrid is off, I have triage" in the chat tool, and the day proceeds. The rule is deliberately unfair to whoever is most alert in the morning, because the alternative is four people each waiting for one of the others to say it. That is the opening scene again with a sick note attached.

The tool shows whether the rule is working. On a day the hat has been dropped, the unassigned view grows. That day, the count of tickets waiting on the desk climbs past its usual morning level. The first-response countdowns on the newest tickets start turning amber. Anyone on the desk can see those numbers, and the one habit that protects an unplanned day is that everyone glances at them once at 09:00. One detail is worth knowing about tools that e-mail the assignee when a target is breached, which many do. In those tools, a breach on a ticket that has no assignee e-mails nobody, because there is no one to tell, unless the tool has been set up to warn a shared address as well. Few are. A dropped hat produces exactly those tickets, which is why the 09:00 glance at the unassigned count is a habit for the whole desk and not only for the triager.

The longer absences, a week's leave or a departure, are a coverage problem rather than a triage one. And the library covers them in Vacation Coverage Without the Pile and in The Coverage Calendar. The rota in this article is the triage row of that calendar. It should agree with the rest of it. And it should be kept in the same place, because a rota that lives in a different document from the leave calendar is a rota that will one day name someone who is on a beach.

Making the Rhythm Visible

A rhythm survives when the desk can see it, and three things make it visible. The rota, posted where the desk looks every morning: a shared calendar, a wiki page, a whiteboard by the coffee. The daily claim, one line in the chat tool or said aloud, so that the hat has a voice. And the health numbers, which are the count of unassigned tickets and the age of the oldest one, glanced at by everyone at 09:00 and by the triager at every sweep. If the first two are in place, the third stays small. If the third is growing, one of the first two has slipped.

The health numbers also give the desk a way to review the rhythm without a meeting. Pull the first-response compliance figure for the last month and look at it by hour of day. If the misses cluster at 09:30, the morning sweep is too late or too short. If they cluster at 14:00, lunch has eaten the 13:30 sweep. If they are spread evenly, the sweeps are fine and the volume has grown past them. In that case, the arithmetic section above says what to do. One change a month, then look again. The weekly routine that keeps the rest of the queue honest, not just the new tickets, is in Queue Hygiene: A Weekly Routine. The triage rhythm is its daily half.

A Short War Story: "I Thought You Had It" at Tollgate Foods

The pallet-label printer at Tollgate Foods was dead for two and a half hours on that Monday. The period ran from 07:40, when Hugo in dispatch logged it, to 10:10. At that point Yusuf, off the phone at last, read the queue from the top and found it fourteenth. In the meantime the loading bay hand-wrote labels for two lorries, both of which left forty minutes late. The second one missed its delivery slot at a supermarket depot and was turned away. That cost a second trip the next day and a conversation between Hugo's manager and the IT manager that Ingrid later described as "brisk". The desk's review found that all four technicians had opened the queue between 08:30 and 09:00. It found that two of them had read ticket 4418. It also found that each had assumed one of the others was triaging that morning, because each of the others usually was. The fix was a rota with one name per day and a deputy, sweep times posted on the wall, and a message in the chat tool at 08:30 every morning from whoever had the hat. The printer had needed a power cycle. The desk had needed a name.

The Weekly Triage Rota and the Daily Sweep Times

The block below is the rota for a desk of three to five people and the sweep times for the hybrid pattern, on one page. Fill in names for a month at a time, keep it beside the leave calendar, and update the sweep times only when the first-response targets change. The glance filter is the view the triager keeps open between sweeps: new tickets at Urgent or above, or whatever your tool's equivalent of a needs-attention list is. The fallback column is deliberately boring; it is there so that nobody has to decide anything at 08:45.

TRIAGE ROTA — ONE MONTH
Desk: ______________   Month: ____________   First-response targets:
  Emergency ______  Urgent ______  High ______  Medium ______  Low ______

DAILY SWEEP TIMES (full first touch of every new ticket)
  Sweep 1: 08:30   Sweep 2: 11:00   Sweep 3: 13:30   Sweep 4: 15:30
  Between sweeps: glance every 20 minutes at the Urgent-and-above view;
  touch only those. Everything else waits for the sweep.
  Longest gap for Medium and Low: about two and a half hours.

THE HAT (one name per day; the deputy takes it without being asked)
  Week 1    Hat            Deputy         Fallback
  Mon       ___________    ___________    first in
  Tue       ___________    ___________    first in
  Wed       ___________    ___________    first in
  Thu       ___________    ___________    first in
  Fri       ___________    ___________    first in
  Week 2    Hat            Deputy         Fallback
  Mon       ___________    ___________    first in
  Tue       ___________    ___________    first in
  Wed       ___________    ___________    first in
  Thu       ___________    ___________    first in
  Fri       ___________    ___________    first in
  Week 3    Hat            Deputy         Fallback
  Mon       ___________    ___________    first in
  Tue       ___________    ___________    first in
  Wed       ___________    ___________    first in
  Thu       ___________    ___________    first in
  Fri       ___________    ___________    first in
  Week 4    Hat            Deputy         Fallback
  Mon       ___________    ___________    first in
  Tue       ___________    ___________    first in
  Wed       ___________    ___________    first in
  Thu       ___________    ___________    first in
  Fri       ___________    ___________    first in

RULES
  1. The hat says "I have triage today" in the team channel by 08:30.
  2. No claim by 08:45: the first person to notice takes the hat and says so.
  3. The hat does every sweep and every glance; nobody else triages.
  4. Everyone looks at the unassigned count and the oldest unassigned
     ticket once at 09:00.
  5. Sweep times change only when the first-response targets change.
  6. Rota written a month ahead, kept with the leave calendar.

Two adjustments by desk size. A desk of two rotates the hat weekly rather than daily and strikes the deputy column, because the deputy is always the other person. It keeps the fallback rule for the week both are out, which is the week the rota should have been talking to the leave calendar. A desk of six or more can promote the hat to a full-day dispatcher who does little else, with a deputy who takes the afternoon. At that size continuous triage replaces the sweeps and the glance filter becomes the whole new-ticket view. In both cases, the one-name rule and the 08:30 claim stay exactly as written. They are the part that works.

Nineteen tickets on a Monday morning, four people, and one of them says "I have triage" at 08:30. Ingrid replies to all nineteen by 09:10. Hugo hears at 08:34 that the printer is Urgent and that Yusuf will be in the bay by 09:00 once he is off the phone. The lorries leave on time. The other three technicians do their work. The queue is watched by one person and triaged by one person, and that is one more than it was.

Frequently Asked Questions