Priority Is Not the Order of Work

At 08:35 Tom has eleven High tickets, nine Medium and forty Low, and no Emergencies. That is a good morning. He looks at the queue for a decision about where to start. The queue offers him the ticket at the top of the list, which is the one somebody most recently replied to. It is a request for a second monitor that the requester has just thanked him for acknowledging. Below it are a laptop that will not boot and a printer that a team of six has been without since yesterday. There is also a ticket marked High at 16:50 last night whose response clock has eleven minutes left on it. Tom picks the monitor. He is not lazy; it was at the top.

Priority and the order of work are two different things, and most desks only define one of them. A priority is the desk's rank for how much a ticket matters, set by impact and urgency. It decides which clocks run. The order of work is the sequence in which a technician actually picks tickets up, and priority is only the first word of it. Eleven High tickets are eleven tickets with the same rank and the same clocks. The rank cannot tell Tom which of them to open first. Something else has to. If nothing does, the top of the list does. And the top of the list is whichever ticket somebody last touched. This article is part of our Prioritization Frameworks series, and it is about the second word.

It covers why the two questions are different and what goes wrong when one is used for both. Then come the five tie-breakers that order tickets inside a priority: the clock, age, the quick win, batching, and the ticket that unblocks others. Next is the daily pick order that puts the tie-breakers on a timetable. The article covers the slow death of Low tickets and the slot that keeps them alive. It explains what the queue should be showing you, and what it is probably showing you instead. It finishes with a work-order rule set written to be pinned beside the grid. How a ticket gets its priority in the first place is in Impact Times Urgency in Practice. This article starts after that decision is made.

Two Different Questions

Priority answers "how much does this matter compared with everything else?", and the answer is a word from a short ladder. The order of work answers "what do I do next?", and the answer is a ticket number. The first is a property of the ticket, set once and changed rarely. The second is a property of the morning, and it changes every time a ticket is finished or a new one arrives. A desk that runs on priority alone has answered the first question forty times and the second question never. And the second one is the one the technician is standing there asking.

Strict priority order is a plausible rule and a bad one. "Work every High before any Medium, every Medium before any Low" sounds like discipline, and on a quiet desk it works for a week. Then a steady trickle of High tickets arrives, one or two an hour, each new one legitimately ahead of every Medium. The Mediums wait a day, then a week. Then they are forty days old and the requesters have stopped asking. Nothing in the rule was broken. The rule just never had a sentence about the tickets at the bottom, and tickets with no sentence about them are tickets nobody works.

The other failure is no rule at all, which is what most desks have. Each technician picks by instinct, and instinct has preferences. There is the interesting ticket, and the ticket from the person who was nice. There is the ticket that can be closed in five minutes to make the count go down. There is the ticket at the top of the list. None of those is wrong once. All of them are wrong as a system, because none of them mentions the clock, the age, or the person who has been waiting longest. Instinct is a fine tie-breaker for two tickets. It is a poor one for sixty.

What a desk needs is priority first and then a short, written set of tie-breakers, applied in a fixed order. That way, any two technicians looking at the same queue would pick the same next ticket. The tie-breakers are not complicated. There are five, and the first two do almost all of the work. The last three exist because a queue is not only a list of deadlines. It is a list of people, and some of them can be helped faster by being helped together.

Tie-Breaker One: The Clock

Inside a priority, the ticket nearest to breaching its target goes first. A target is the time by which the desk promised something, a first response or a resolution. And the clock is the countdown to it. Two High tickets with the same priority can have very different clocks. One opened eight minutes ago has nearly its whole response window left. One opened at 16:50 yesterday, with the business day ending at 17:00, has eleven minutes left this morning. Same priority, different next action. The clock is the tie-breaker because it is the only one with a consequence attached: miss it, and a promise is broken in writing.

Work the response clock before the resolution clock, because the response is the cheaper promise and the one the requester notices first. A ticket whose first-response target expires in eleven minutes needs a reply, not a fix. For example: "I have your ticket, I am looking at the boot failure now, and you will hear from me by ten." That takes ninety seconds, stops the clock that was about to breach, and starts the longer one. Which clock means what, and why the response one matters more than it looks, is the subject of Response vs Resolution Targets. The order-of-work rule is simply: among equals, the nearest deadline first, and a response deadline is nearer than it feels.

The clock has one trap, which is the hold. On some tools, placing a ticket on hold pauses its clock. In those tools, a technician under pressure learns to park tickets to stop the countdown. On others, hold does not pause anything. Only non-working hours and holidays are excluded, and a ticket on hold breaches on schedule. Know which kind you have (put a test ticket on hold over a weekend and read its due time on Monday). A desk that believes hold stops the clock and is wrong will discover it in the breach report. In either case, the hold status is for tickets genuinely waiting on something, not a place to put tickets you would rather not look at. The clock can see them there.

Tie-Breaker Two: Age

When the clocks are equal, or nothing is close to breaching, the oldest ticket goes first. Age is simply how long the ticket has been open, and it is the plainest measure of how long a person has been waiting. Consider two Medium tickets with four days left on both resolution clocks. They are not equal if one was opened this morning and one was opened eleven days ago and has been bounced between two technicians since. The eleven-day one goes first, not because its clock says so, but because its requester has already been patient for eleven days. Patience is a resource the desk is spending.

Age is the tie-breaker that protects the desk from its own preferences. Every instinct in the queue pulls towards the new ticket. It is fresh, the requester is engaged, the problem is clear, and it can be closed quickly while the memory is warm. The old ticket is the opposite on every count, and so it ages further. The further it ages the less anyone wants to open it. The ones nobody wants to open are a subject of their own, in The Tickets Everyone Is Avoiding. The order-of-work rule is the small daily habit that stops them forming. Oldest first, among equals, every time, even when the oldest is the one you have been not-looking-at for a week. Especially then.

Measure age from when the ticket was opened, not from when it was last touched, because a ticket that is touched is not necessarily moved. A technician who adds "still looking into this" every three days has kept the last-update date fresh and the requester's wait exactly as long as it was. Some tools sort by last update by default, which hides age in plain sight. The fix is a view or a filter that shows opened date. Or it is the simple discipline of reading the date at the top of the ticket before deciding it can wait.

Tie-Breaker Three: The Quick Win

A quick win is a ticket that will take under ten minutes from opening to closing reply. A handful of them, done together at a fixed time, clears more people's problems per hour than any other use of the hour. Password resets, a mailbox permission, a printer re-added, a shortcut restored. Each is trivial; together, six of them in forty minutes is six requesters who stop waiting before lunch. The rule is to batch them, at a time of day chosen in advance. Do not let them interrupt the clock-and-age order the rest of the time.

The trap with quick wins is that they are pleasant. Each one closes, the count goes down, and the requester says thank you. And the technician gets a small clean feeling that the laptop-that-will-not-boot does not provide. A desk that works quick wins whenever it likes becomes a desk that works nothing else. Its closed count looks superb while its hard tickets age to the point of embarrassment. (A queue of only solved easy problems is a very tidy way to fail.) The fixed slot is the defence. Quick wins have a time, usually one slot in the morning and one after lunch. Outside the slot they wait like everything else.

Quick wins also have a limit per slot, and the limit should be written down. Eight in a slot is plenty. If there are twenty, the slot is not a slot but the morning. In that case, the question is why twenty trivial tickets are arriving a day. That is a question for the knowledge base or the self-service form, not for the order of work. A desk that is mostly quick wins has a demand problem dressed as a sequencing problem, and no pick order will fix it.

Tie-Breaker Four: Batching Similar Tickets

Tickets that share a system, a site or a requester are cheaper worked together than apart. The order of work may group them even when their clocks and ages differ a little. Three tickets about the same shared drive are one investigation with three replies. Four tickets from the same branch office are one visit instead of four. Two tickets from the same requester about a laptop that is misbehaving in two ways are, in all likelihood, one laptop. The tie-breaker is to pull the batch together when you pick up the first of them. Send every requester in the batch the same honest update at the same time.

Batching has a tool shape, and it is worth using. Where several tickets are the same fault, link them under one incident name. That way, one investigation feeds every ticket and one update reaches every requester. Most tools offer some way to link or relate tickets, which keeps each requester's ticket separate while tying them to a shared name. Merging is a different act, meant for duplicates from the same requester. In many tools it cannot be undone, so link when in doubt. The linked set then behaves, for order-of-work purposes, like one ticket with the nearest clock of any of its members.

The limit on batching is the clock. A batch is worth forming when it saves real time and no member of it breaches while waiting for the others. Holding a ticket with twenty minutes on its clock so that it can be worked with two others due tomorrow is not batching. It is a breach with a tidy explanation. Batch the ones whose clocks allow it, work the tight one now, and fold it into the batch afterwards. The tie-breakers are in order for a reason, and the clock is first.

Tie-Breaker Five: The One That Unblocks Three Others

Some tickets are standing in the way of other tickets, and those go before their clock or age alone would place them. The new starter cannot be set up until the account ticket is done. The account ticket cannot be done until the manager's approval ticket is answered. The approval ticket is a Low that has been sitting quietly for four days while two Highs wait on it. The Low goes first, because finishing it finishes three things. A ticket's own priority measures its own impact. The order of work also gets to notice what is queued up behind it.

Finding these tickets takes one question at pick-up time: "is anything waiting on this, and is this waiting on anything?" The second half matters as much. A ticket that is waiting on a part, a supplier, or another team's reply cannot be advanced by being opened. Opening it anyway is a way of feeling busy. Mark it as waiting, with a date to chase, and spend the time on a ticket that can move. The first half finds the unblockers. Between them, the two halves turn a flat list of tickets into something closer to a map, and a map is what the order of work needs.

The unblocker rule is also the honest answer to the question every technician eventually asks, which is "why am I doing this Low before that High?". Because the Low is holding the High up. Write that in the note, so that the review sees the reason and not just the sequence. A Low worked out of turn with no reason is a preference. A Low worked out of turn because three tickets were queued behind it is the rule, working.

The Daily Pick Order

The tie-breakers become a routine when they are attached to the clock on the wall. The table is one working day on a desk with ordinary hours. And the shape matters more than the times; shift it to fit your own hours and your own quiet periods. An Emergency interrupts every slot, and an Urgent is worked ahead of whatever the slot says, because that is what Urgent means. Everything else lands in its slot and stays there.

On a desk of one, the slots shrink and the shape holds. The order is overdue first, triage, hard work, a quick-win slot, protected Medium time, a Low slot, and an end-of-day sweep for promised updates. On a desk of four, the slots can be staggered. That way, one person is always in a triage or quick-win slot while the others are in deep work. This is the small-team version of a rota. The point of the timetable is not the times. It is that every priority, including the lowest, has a place in the day where it is the thing being worked. It also means that the technician never has to invent the next ticket from nothing.

The last slot is the one most often skipped and the one that matters most to requesters. Every ticket that was promised an update today gets one, even if the update is "no change, next update Thursday". Every ticket waiting on a supplier or another team gets a chase if its chase date has arrived. And the first three tickets for tomorrow morning are written down, so that 08:30 starts with a decision already made. A technician who starts the day by choosing is a technician who starts the day with the monitor request.

Starving the Low Tickets

Low tickets starve by arithmetic, not by neglect. Every day brings a few new High and Medium tickets, each of which legitimately goes ahead of every Low. The Low tickets move to the back of the day, and the day ends before the back is reached. Nobody decided not to work them. The rule just never reached them. And the forty Low tickets on Tom's queue are the accumulated result of a hundred days on which that was true. By the time a Low ticket is ninety days old, its requester has bought the thing themselves, worked around it, or stopped believing the desk. All three are worse for the desk than the ten minutes the ticket would have cost in week one.

The cure is a reserved slot and a rule inside it. And the slot above is the reserved one: at 15:00, the oldest three Low tickets, every day, no exceptions short of an Emergency. Three a day is fifteen a week, which is more than most small desks receive, so the pile shrinks. Inside the slot, each ticket gets one of three outcomes. It is done, or it is scheduled with a date the requester is told. Or it is closed honestly with a reply that says the desk will not be doing it and why. The third outcome is the one desks avoid and the one requesters prefer to silence. "We are not going to replace the mouse, because the current one works; if it fails, raise a new ticket and we will" is a better answer than ninety days of nothing. Low is a priority. It is not a euphemism.

Two numbers tell you whether Low is starving: the age of the oldest Low ticket, and the count of Low tickets older than thirty days. Look at both on Friday. If the oldest is under three weeks and the over-thirty count is near zero, the slot is working. If the oldest is a season and the count is a page, the slot is being skipped. In that case, the honest conversation is with whoever keeps skipping it, which, on most desks, is everyone. How a pile like that forms, and how to dig out once it has, is the subject of How a Ticket Mountain Forms. The slot is how you avoid needing that article.

There is a quieter way to starve Low tickets, which is to raise them. A technician who wants to work a Low ticket now, and has no slot for it, raises it to Medium, with a note saying "to get it done". The ticket gets worked. The Low priority gets a reputation as the one that never moves. And the next requester picks Medium, as any sensible person would. Work Low tickets as Low, in the Low slot, and the priority keeps its meaning. Raise them to get around the slot, and within a quarter there is no Low, only Medium with a story.

What the Queue Should Show You

The queue should show the technician the next ticket, and most queues show them the most recent one instead. A list ordered by last update puts the ticket somebody just replied to at the top, whatever its priority or clock. That is useful for seeing what is moving and useless for deciding what to pick. A list ordered by created date shows age and hides the clock. A list ordered by priority shows the rank and hides both. No single sort order is the order of work, because the order of work is a rule, not a column. What a queue can do is give the technician the three views the rule needs: what is about to breach, what is oldest, and what is in which priority.

Know what your own tool does, because the honest answer is often "less than you assumed". In many small-team tools the ticket list is a single list ordered by last update, and the columns do not sort at all. The order of work there is not a sort but a filter and a set of counters. Take a filter that narrows the queue to one priority or one SLA state, ideally with a live count beside each choice. Such a filter shows the eleven High tickets and the ones already over. A countdown or due time shown on each row makes the nearest clock visible without opening anything. And a dashboard counter for tickets that are overdue or due within the hour is the 08:30 slot, ready-made. Most tools can do some version of each of these; find them before you need them. None of it is a magic sort, and a technician who expects one will be disappointed and then, after a week, will be faster.

Whatever the tool, the technician should be able to answer three questions in under a minute at the start of each slot. Those questions are what is about to breach, what is oldest in this priority, and what is unowned. The first is a filter on SLA state or a counter. The second is a filter on priority with the opened date read off each ticket. The third is a standing view of unassigned tickets, which most tools can save as a filter. What a queue is for, and why a ticket in a queue nobody reads is a ticket nobody owns, is the subject of What a Queue Is For. For the order of work, the queue's job is to answer those three questions quickly and then get out of the way.

A Short War Story: Forty Low Tickets at Tollgate Foods

Tollgate Foods, a frozen-goods wholesaler with a desk of two, ran strict priority order for most of a year. By the autumn it had forty-one Low tickets open with the oldest at a hundred and forty days. One of them, from Hana in invoicing, asked for a second monitor. She wanted to stop switching between the order system and the invoice template. The ticket waited eleven weeks, during which she keyed every invoice twice, slowly. The invoicing run that should have taken a morning took most of two days each week. The finance manager, Owen, did the arithmetic. He worked out that the desk had been saving ten minutes of technician time per week by not fitting a monitor. That came at the cost of a day of his clerk's time per week. He sent the figures to the IT manager with a short covering note that the desk still talks about. The desk introduced a daily Low slot of three tickets the next Monday and cleared the forty-one in a fortnight. It found that nineteen of them took under ten minutes each and six were no longer wanted at all. The lesson was not that Low tickets are secretly important. It was that a Low ticket that is never worked is a promise never kept. The lesson was also that the requester is paying for the wait whether or not the desk is counting it.

The Work-Order Rule Set

The block below is the rule set as a page, written to sit beside the grid where the technician can see both. It is deliberately short; a rule set longer than a page is a rule set nobody applies at 08:35. Adjust the slot times and the Low count to your own desk, and leave the order of the tie-breakers alone.

WORK-ORDER RULE SET — ONE PAGE
Desk: __________________   Hours: ________ to ________   Reviewed: __________

RULE 0 — PRIORITY FIRST
  An Emergency interrupts everything. An Urgent is worked before any slot.
  Otherwise, inside a priority, apply the tie-breakers below in order.

TIE-BREAKERS, IN ORDER
  1. CLOCK   Nearest target first. Response clocks before resolution clocks.
             Hold does not pause the clock here: [ ] true  [ ] false (check)
  2. AGE     Among equal clocks, oldest opened date first. Not last update.
  3. QUICK   Under ten minutes, worked in the quick-win slot only, up to ____
             per slot, oldest first.
  4. BATCH   Same system, same site or same requester: pull together, link
             under one name, one update to all. Never hold a ticket past its
             clock to wait for the batch.
  5. UNBLOCK A ticket that others are waiting on goes ahead of its clock and
             age. Write the reason in the note.

THE DAY
  ____:____  Overdue and due-within-the-hour, response clocks first
  ____:____  Triage of new tickets: priority, owner, first reply
  ____:____  High tickets by clock, then age
  ____:____  Quick-win slot (max ____)
  ____:____  Second triage pass
  ____:____  Medium tickets by age; batch where it saves time
  ____:____  LOW SLOT: oldest ____ Low tickets; each one done, dated or
             closed honestly
  ____:____  Second quick-win slot, then High by clock
  ____:____  Promised updates sent; waiting tickets chased; tomorrow's first
             three written down

LOW-TICKET RULES
  Never raise a Low to get it worked. Work it in the slot, as Low.
  Every Low ticket in the slot leaves with one of: done / scheduled with a
  date told to the requester / closed with a reply that says why.
  Friday check: oldest Low ____ days; Low tickets over 30 days: ____

NOTES THAT MUST BE WRITTEN
  Any ticket worked out of order: the tie-breaker that moved it.
  Any ticket marked waiting: what it waits on and the date to chase.

The rule set has one property worth protecting. Any two technicians, given the same queue at the same minute, would pick the same next ticket. They could say why in one line. That is what makes the order of work a rule rather than a habit. It is also what makes the desk's behaviour explainable to a requester who asks why their ticket was not next. A desk with no rule can answer that question only with an apology.

Tom's morning, replayed: 08:35, the filter on SLA state shows one High with eleven minutes on its response clock. He replies to it first, promising a call by ten. Then the oldest High, the boot failure, to a stopping point. The monitor request, which is Low and three days old, waits for the 15:00 slot. There it takes four minutes and the requester says thank you a second time. Nothing about the queue changed between the two mornings except that the top of the list stopped being the decision. The list never wanted that job. It was just the only thing in the room with an opinion.

Frequently Asked Questions