Priority Tiers That Are Realistic

At 08:50 on Monday the queue holds nineteen new tickets, and seventeen of them are marked Urgent. One is a department that cannot log in. One is a printer that is "making a noise". One asks for a second monitor "before the quarter starts". The form offered a checkbox, the checkbox was free, and nineteen reasonable people each ticked it for a reasonable reason. The desk now has to decide which Urgent comes first, which is the decision the checkbox was supposed to make. When everything is urgent, the queue is sorted by who typed fastest.

This article is the third in our SLA Design series. It is about priority: the rank that decides which targets apply to a ticket, set from impact and urgency. Priority is the hinge the whole SLA swings on. Get it wrong and the response and resolution targets, however carefully chosen, attach to the wrong tickets. In that case, the desk works hard in the wrong order all day.

It covers what priority is for; and impact and urgency in plain words, with a three-by-three grid. It covers why four or five tiers is the right number and seven is not; and a written definition for each tier with two examples. It covers who sets priority and who may suggest it; and the "everything is P1" problem and the three fixes. It covers targets a small team can meet; the quarterly check that shows whether the definitions are working; and a priority definitions card to pin beside the queue.

What Priority Is For

Priority is the rank that sets a ticket's targets, and it answers one question: which ticket does the desk touch next? It is not a measure of how important the person is, how important the system is, or how upset anyone sounds. It is an ordering. Two tickets at the same priority are worked in the order they arrived; a ticket at a higher priority is worked before both, whatever its age.

The SLA targets hang off priority, which is why it has to be decided before anything else about a ticket. A Critical ticket at Acme gets a thirty-minute response target and a four-hour resolution target. A Low ticket gets a business day and ten business days. Those numbers mean nothing until a human has decided which row applies, and they mean the wrong thing if the row was picked by a checkbox. The targets themselves are set in the sibling article Response Targets vs Resolution Targets. This article is about which ticket gets which row.

Priority is also what lets a technician stop apologizing. With a published ladder, leaving the noisy printer until after the login failure is the desk's policy rather than the technician's temperament. The technician can say so in one line. Without the ladder, every choice is personal, every choice is defended, and the queue develops a weather system.

Impact and Urgency in Plain Words

Priority is decided from two things, and keeping them separate is most of the skill. Impact is how many people are affected and how badly: one person slowed, one person stopped, a team stopped, the whole organization stopped. Urgency is how soon it hurts: right now, by the end of today, or whenever is convenient. A ticket can be high impact and low urgency (the payroll export fails, but the next run is three weeks away). It can also be low impact and high urgency (one person cannot present to a customer in forty minutes). Both deserve a sensible rank, and neither deserves the top one.

The grid below puts the two on axes, and the cell is the priority. Read impact down the side and urgency across the top. The cells use the house ladder that runs through this series: Critical, High, Normal and Low, often written P1 to P4.

Walk one ticket through it. Priya at a Bluewater Bank branch writes at 09:12 that the document scanner has stopped. Priya says six people at the counter are keying forms by hand while customers wait. Impact: several, a team of six. Urgency: now, because customers are in the building. Cell: High. Not Critical, because the branch is still serving people, slowly; not Normal, because there is no acceptable wait. Thirty seconds of triage, one cell in the grid, and the targets are set.

The grid is deliberately coarse. Nine cells, four outcomes, and no cell that needs a meeting. A finer grid, with five levels of impact and five of urgency, has twenty-five cells. I have watched a desk spend longer choosing the cell than fixing the ticket.

Four or Five Tiers, and Why Not Seven

Four tiers are enough for a small desk, and five is the most it can tell apart. Each tier has to mean something different about what the desk does next. The desk might drop everything, do it before anything Normal, do it in turn, or do it when the queue is quiet. A fifth tier, Planned, is useful for work with an agreed date, so that it stops aging in the queue and stops being compared with incidents. Beyond five, the tiers stop describing different behavior and start describing different feelings.

Seven tiers fail because the triager cannot apply them in ten seconds and the technician cannot remember what P5 means at 16:45. The difference between two neighboring tiers has to be one the desk would act on. If both get worked "in turn", they are one tier with two names. The seven-rung ladder is precise in the way a ruler marked in sixteenths is precise: nobody reads past the quarters.

The test for a tier is whether it changes the targets or the order. If a proposed tier would carry the same response target, the same resolution target and the same place in the queue as its neighbor, it does not exist. Merge it and move on. A short ladder is also a ladder users can learn, which matters on the day the desk re-prioritizes their ticket and wants to say why in one line.

The Priority Definitions Card

Each tier needs a written definition with three parts. It needs a one-line test the triager can apply without a meeting, and two examples that would make a new technician nod. It must also say what the desk does when it sees that rank. The test is written in terms of impact and urgency. The examples are drawn from your own queue, because an example from someone else's queue describes someone else's building. The card below is the one to copy, with the targets Northgate Retail uses shown as examples. The card is also a section of the one-page document described in Writing the SLA Document People Will Read.

Pin the card beside the queue, put it on the portal page where users open tickets, and keep it to one screen. The card is what makes priority a policy rather than a mood. When a ticket is moved from High to Normal, the technician points at the test and the two examples. The conversation is about the card rather than about anyone in it.

Who Sets Priority

The desk sets priority, after triage, every time. Triage is the first human look at a ticket, and it ends with an owner, a priority and a reply. The habit itself is laid out in the Helpdesk Fundamentals series. The requester may suggest a priority, and the suggestion is useful information. But the rank that drives the targets is the desk's decision, because the desk is the only party that can see the whole queue. A requester who marks a ticket urgent is telling you, honestly, how it feels from their chair. That is data, not a verdict.

Give the requester a way to say what matters without handing them the lever. The form asks what is affected and how many people. It does not offer a priority list, because a list of five options with Urgent at the top is a list with one option. The desk reads the answers and sets the rank. The acknowledgment says which rank and why, in one line: "I have set this as High, since you cannot work and there is no spare machine; you will hear from me within two hours."

Re-prioritizing is normal and should be cheap. When a ticket turns out to be bigger than it looked, or smaller, the technician changes the rank and writes one line explaining the change in the reply. Nobody needs to approve it. A desk where changing a priority requires a conversation with a manager is a desk where nobody changes a priority. The ladder slowly fills with Highs that should have been Normals and nobody willing to say so.

The "Everything Is P1" Problem and Three Fixes

The queue in the opening is not an emergency. It is a definitions problem wearing a siren. When a third or more of tickets arrive at the top tier, the top tier has stopped meaning anything. In that case, the targets attached to it cannot be met. The one real Critical in the pile is indistinguishable from the printer that makes a noise. The cause is almost never the people who opened the tickets. It is a form that asked the wrong question and a desk that accepted the answer.

The first fix is that the form stops asking. Remove the priority field, or the Urgent checkbox, and ask instead what is affected and how many people, in two short fields. The form stops offering a lever, so nobody pulls it, and the desk gets the two facts it needs to set the rank itself. This one change does more than the other two together, and it takes ten minutes.

The second fix is that the definitions are published. The card goes on the portal, into the acknowledgment e-mail, and onto the wall. Users who can see that Critical means "many people cannot work right now" stop asking for it for one printer. That is not because anyone scolded them but because the word now has a meaning they can check their own ticket against. The best publishing is a one-line "why" in every acknowledgment, which teaches the ladder one ticket at a time.

The third fix is that the desk re-prioritizes with a one-line reason, every time, without apology. "I have moved this to Normal: the printer next door works, so nobody is stopped. You will hear from me by tomorrow morning." The line is kind, it is specific, and it quotes the test. Over a quarter, the requesters who marked everything urgent learn what the desk means by the word. The rank they suggest starts to match the rank the desk sets. That is the whole fix, and it has never once required a stern e-mail to all staff. The stern e-mail is what desks send instead of doing the three fixes.

Targets a Small Team Can Meet

Priority only works if the targets at each tier are ones the desk can keep. A small desk should set them from its own history rather than from what sounds impressive. Pull last month's tickets, sort them by the tier they should have been, and look at how fast the desk actually replied and actually fixed them at each tier. The target is the figure the desk met on eight tickets in ten, rounded to something people can remember. A target that nothing in the history has ever met is a breach with a start date, and SLA Breaches and What They Teach is the article you will be reading if you set it.

The figures on the card are the ones a desk of two to five people commonly manages. They are thirty minutes to reply to a Critical, two business hours to a High, four to a Normal, and a business day to a Low. Resolution targets are eight or more times looser. The full ranges, and the business-hours clock they run on, are in the targets article linked earlier. The only rule here is that each tier's numbers come from your own queue, not from a list.

The spacing between tiers matters as much as the numbers. Each step down the ladder should roughly double or quadruple the targets, so that the tiers feel different to the desk and to the user. If High and Normal sit an hour apart, the triager will stop distinguishing them. In that case, the ladder will have quietly collapsed to three rungs without anyone deciding that it should.

The Quarterly Check

Once a quarter, count the share of tickets at each tier, because the distribution is the only honest test of whether the definitions are working. A healthy small desk sees roughly two to five percent Critical, ten to fifteen percent High, sixty to seventy percent Normal, and the rest Low and Planned. The numbers are not a standard; the shape is. The ladder should be a pyramid with a narrow top.

If a third of tickets are Critical, the definitions are wrong, or the form is still asking. If almost nothing is Critical for a year, the test is too strict and real emergencies are being logged as High, where the targets are too loose for them. If Normal is ninety percent, the desk has stopped triaging and is using Normal to mean "unread". Each shape points to one fix, and the fix is to the card or the form, never to the users.

Here is one check. Bluewater Bank's branch desk, three technicians, closed 412 tickets in a quarter: 14 Critical, 58 High, 266 Normal, 61 Low and 13 Planned. That is three percent, fourteen, sixty-five, fifteen and three. The pyramid is the right shape. The one thing the check found was that nine of the fourteen Criticals were the same branch's connection dropping on Monday mornings. That is not a priority problem but is a problem. It went to the network owner with a count attached. Fifteen minutes, once a quarter, one finding. That is what the check is for.

A Short War Story: Northgate Retail

Northgate Retail's ticket form had an Urgent checkbox, and forty percent of requesters ticked it. The desk had three technicians and a thirty-minute Critical response target. That meant that on a typical morning it owed thirty-minute replies to a dozen tickets, most of them about label printers and one, sometimes, about the till system. Dana, who ran the desk, did not send an e-mail asking people to stop. She replaced the checkbox with two fields, "what is affected" and "how many people", and put the priority card on the portal page above the form. In the following quarter, four percent of tickets were set to Critical, every one of them by the desk. The thirty-minute target was met on all but two. The requesters had not changed at all; the form had stopped asking them a question they could only answer one way.

I have replaced that checkbox on three different desks. It has never once been the users.

Keeping the Ladder Short

A short ladder stays short only if something stops it growing. Every quarter someone will propose a new tier: Urgent above Critical, or Medium between High and Normal, or a VIP rank for one department. Each proposal is reasonable on its own. Each one lengthens the ladder by a rung the triager has to think about at 08:50. The defense is the test from earlier: a new tier exists only if it changes the targets or the order. Most proposals fail that test and are really a request for a better definition, which is a change to the card, not to the ladder.

A tool with a fixed set of priorities keeps the ladder short by construction. QuerySolv ships five priorities and ten statuses that cannot be renamed or added to. The site states that plainly as a limit. For a small desk it is also a discipline: the fifth rung is the ceiling, and the argument about a sixth never starts. On a tool that allows any number, write the ceiling into the SLA instead, and treat a request for a new tier as a request to rewrite a definition.

Back to Monday at 08:50. The same nineteen tickets arrive. The form has asked what is affected and how many people, and the desk sets the ranks in ten minutes: one Critical, three High, twelve Normal, three Low. The login failure is being worked by 09:00. The printer that makes a noise is on the list for the afternoon. The person who reported it has been told so, and why. Nothing about the tickets changed. The queue is now sorted by something other than typing speed.

Frequently Asked Questions