A Prioritization Policy You Can Write Down

Gwen has been IT lead at Westbrook Academy for eleven days when the bursar stops by her desk and asks, pleasantly, "What is your policy for deciding what gets fixed first?" Gwen says she will send it over. She then spends forty minutes looking for it. There is a document in the shared drive called "IT Service Priority Policy", eleven pages, written before her time. It has a flowchart on page six and a glossary on page nine. Callum, the other technician, has never read it. There is also what Callum actually does, which he can explain in about ninety seconds. It is sensible and lives nowhere but in Callum. Gwen has a policy nobody follows and a practice nobody wrote down. The bursar is expecting an attachment.

A prioritization policy is a short written statement of how the desk decides a ticket's priority, and who may change it. It also says what each priority promises and how the desk checks that it is doing what it said. It is the thing you hand the bursar. It is also the thing the new technician reads on day two. It is the thing the desk points at when a requester asks why their ticket is Medium. And it is the thing the manager reads before arbitrating a dispute. It fits on one page, or it is not doing any of those jobs. This article is part of our Prioritization Frameworks series. This article is the last one, because the policy is where the other five get written down.

It covers why the policy is one page and what each of its five sections is for. Then come the definitions, which borrow the grid, and the examples, three for each priority, drawn from your own building. Next come who may change a priority and how a change is recorded. Then comes what each priority promises, which points at the SLA rather than repeating it. After that come the monthly review in fifteen minutes and what to do when the rule gives the wrong answer, which it will. Next is how to announce the policy so that it survives its first month. Last is the policy page itself, laid out to be filled in this afternoon. The grid is explained in Impact Times Urgency in Practice and the etiquette of changing a priority in Who Decides the Priority. This article assumes both and turns them into a document.

Why One Page

The policy is read in three situations, and none of them has time for eleven pages. The technician at 08:35 with three Urgent tickets and a doubt needs the definition and an example, in under a minute. The requester who asks "why is mine Medium?" needs a sentence they can be sent, with a link to the page it came from. The manager asked to arbitrate needs the rule, the examples and the override procedure, before the meeting rather than during it. A page can do all three. A document with a glossary cannot, because nobody opens it, and a policy nobody opens is a rumour with a filename.

One page also forces the desk to decide what it actually believes. Eleven pages can hold every edge case, every exception somebody once argued for, and three overlapping definitions of urgency written in three different years by three different people. One page can hold one definition, which means the desk has to agree on it. That is the useful part. The writing is not the work. The agreeing is the work, and the page is the receipt.

The policy is not the SLA document and should not try to be. The service level agreement, or SLA, is the written promise of how fast the desk responds and resolves at each priority, with the schedule, the exclusions and the measurement rules. It is a longer document and it has its own article in Writing the SLA Document People Will Read. The prioritization policy is about how a ticket gets its priority in the first place and who may change it. The two documents meet at the ladder of priority names, which must be the same in both. Otherwise, they stay out of each other's way. A policy that tries to restate the SLA becomes page two, and page two is where readers stop.

Five sections, in a fixed order, is the shape. Definitions. Examples. Who may change it. What each priority promises. The review. The table further down gives each section a length and an owner, and the template at the end gives the blanks. If you find yourself adding a sixth section, ask which of the five it belongs in. It belongs in one of them. (It is usually trying to be an exception, and exceptions go in the review.)

Section One: The Definitions

The definitions section says what impact and urgency mean, in the desk's own words, and shows the grid that turns them into a priority. Impact is who is hurt and how many: one person, a team, or many people or a critical process. Urgency is how soon it hurts: work has stopped, work continues with a costly workaround or a deadline falls today, or it can wait a few days. Nine cells, five names. The section is six lines and a small grid, and it is the part of the policy the technician reads most. So it goes first and it goes in plain words.

Use the priority names your tool uses, exactly as they appear on the screen. Many small-team tools ship with a fixed set of names that cannot be renamed, and some let you rename them. In either case the policy should use the word the technician sees in the drop-down, so that the page and the screen agree. Where a tool offers four levels and the policy wants five, or the reverse, the policy wins. In that case, the mapping is written down once: "our tool's Critical is this policy's Emergency." The meaning of a priority lives in the definition on the page, not in the label on the screen. A desk that remembers that can survive a tool change without rewriting its policy.

Name the critical-process list in this section and point at it, without reproducing it. "A process on the impact register, kept at this link and reviewed quarterly, counts as high impact however many people are at the broken device." That sentence does two things. It tells the technician that the register exists and where it is. And it keeps the register out of the policy, so that the register can change quarterly without the policy changing with it. Building the register is the subject of Making Business Impact Visible. The policy just has to know it is there.

Section Two: Examples for Each Priority

Three examples per priority, from your own building, in one line each, do more to make the policy work than everything else on the page combined. A definition tells the technician what Urgent means. An example tells them what it looks like on a Thursday: "the whole finance team cannot open the shared drive", "the till in the main shop will not take cards", "the goods-out tablet is down and the haulier is due". The technician reads the ticket, reads the examples, and finds the one that rhymes. Most priority decisions on a desk with good examples are made by recognition, not reasoning. Recognition is faster and more consistent.

Draw the examples from real tickets, lightly disguised, and choose ones the desk has actually argued about. The argument is the signal. If two technicians once disagreed about whether a dead projector in the main hall on open evening was High or Urgent, that projector is an example. In that case, include the answer the desk settled on and the fact that decided it. Examples nobody has argued about teach nothing, because nobody needed teaching. The three for each level should include one that is obvious, one that is borderline, and one that surprises a new reader, such as a failed backup rated High when nobody is blocked.

Add one anti-example per level, saying what the priority is not. "Urgent is not: one person's laptop with a spare on the shelf; a request with a deadline next week; anything the requester marked Urgent without saying who is affected." Anti-examples catch the common mistakes before they happen. They are the lines requesters most often quote back at the desk, usually with approval. A policy that only says what things are leaves the reader to guess at the edges. The edges are where the arguments live, so put a fence there.

Keep every example to one line, and refresh them yearly. A policy whose examples mention a system the organisation replaced two years ago has told the new technician that nobody reads the policy. That is a strange thing for a policy to say about itself. The yearly refresh takes twenty minutes. Read the fifteen lines, strike the ones that no longer exist, and replace them with the three tickets the desk argued about most this year. The definitions should barely change. The examples are where the policy stays alive.

Section Three: Who May Change It

This section says, in four short lines, that the requester proposes, the desk decides, the manager arbitrates, and every change is written down. The requester may indicate a priority on the form or in the subject, and the desk reads it as information about their situation. Any technician who can see the whole department queue sets or changes a priority, from the grid. They add a one-line note saying why and a one-sentence reply to the requester saying what, why and when. The desk's manager, or a named deputy out of hours, may override the grid. The override is recorded with their name and reason, and counted at the review. Four lines, and most of the disputes a desk will ever have are already settled.

Put the permission line in writing even when the tool enforces it, because the policy will outlive the tool. The line is also a decision about trust that the desk should be able to explain. "Technicians who see only their own assigned tickets flag a priority concern to a colleague rather than changing it themselves; technicians who see the department queue change priorities directly." If your tool has roles that match, say which. If it does not, the line is a rule of habit. In that case, habits are enforced by the review, which is why the review exists.

Write the override rule so that it feels normal, not shameful. An override is the manager doing their job. A policy that treats it as a failure will teach managers to override quietly, which is a shadow SLA by another route. "Managers may set a priority above or below the grid when they have a reason the grid cannot see. The reason is written in the ticket. Overrides are counted monthly. A pattern of overrides is treated as a signal that the grid or the register needs a line, not that anyone did anything wrong." That paragraph, more than any other on the page, is what keeps the policy honest in its second year.

Section Four: What Each Priority Promises

This section is five lines, one per priority, each copied from the SLA, and nothing else. "Emergency: we respond within fifteen minutes and work continuously until resolved. Urgent: response within one hour, resolution target four business hours. High: response within two hours, resolution target one business day." And so on down to Low, which has a target too, because a priority with no promise is a priority that will be ignored. The lines are the SLA's. The policy quotes them so that the technician does not need two documents open. The quote says where the numbers came from so that when the SLA changes, someone knows to change the quote.

Add one promise that belongs to the policy rather than the SLA: the promise to tell the requester. "Whenever we set a priority different from the one you asked for, we tell you what we set, why, and when you will hear from us." That sentence is the one requesters care about most, and it is not an SLA target. It is a behaviour the desk commits to. It is the reason the policy can be published to the whole organisation without starting an argument. People accept being rated Medium. What they do not accept is being rated Medium in silence.

Resist adding anything else to this section. Not the schedule, not the holidays, not the exclusions, not how breaches are measured. Those belong in the SLA. A policy that repeats them will drift out of step with it within a year. At that point, the desk has two documents that disagree and no way to tell a requester which one is true. Five quoted lines, one behavioural promise, and a pointer to the SLA. That is the whole section, and it is already longer than most desks' SLA knowledge.

Section Five: The Review

The review is fifteen minutes a month, on the calendar, with four numbers and one decision. The four numbers start with how many priority changes the desk made, split by raised and lowered. Next is how many overrides managers recorded, and from whom. Then comes how often the requester's proposed priority matched the desk's decision, by department. Last come breaches by priority, which the SLA review also reads but which this review reads for a different reason. The one decision: change one thing on the page, or write "no change" and say why. A review that produces two changes cannot tell next month which one worked. A review that produces none three months running is a policy that is right, and should say so.

Read the overrides first, because they are the policy telling you where it is wrong. Ten overrides for the same kind of ticket is a missing example or a missing line on the register, and the fix is a sentence. Ten overrides from the same manager is a conversation about the grid, held with the counts in hand. One or two overrides from different people for different reasons is a healthy month, and the right response is to leave the page alone. Overrides are not a measure of the desk's failure. They are the policy's error log, and an error log that nobody reads is just disk space.

Read the match rate second. Where requesters' proposals agree with the desk's decisions most of the time, the organisation has learned the grid. In that case, the desk can spend less time explaining it. Where one department's proposals almost never match, that department has not been told the policy exists, or was told once in an e-mail during a busy week. The fix is a ten-minute visit with the grid picture, and the match rate the following month tells you whether it worked. This number improves slowly and then holds. A desk that tracks it for a year has a quiet, convincing record of the policy doing its job.

Most tools can produce these counts from the ticket history, with some effort. Where yours cannot, export a month of tickets with their priority, the requester's proposed priority if the form captures it, and the history of changes. Then sort it in a spreadsheet. The first month takes half an hour. The second takes ten minutes. Write the four numbers on the policy page itself, in a small box at the bottom with the date. That way, anyone reading the page can see that it was reviewed, when, and what changed. A policy with last month's review date on it is a policy that is alive. One with no date is an artefact.

When the Rule Gives the Wrong Answer

The rule will sometimes give the wrong answer, and the policy should say so and say what to do. A grid is a simplification of judgment. It is built so that judgment can be applied quickly and consistently by people who have not been on the desk for ten years. Any simplification has edges where it fails. A ticket arrives that the grid rates Medium, and every experienced person in the room knows it should be Urgent. They are right. The question is not whether to deviate; it is how, so that the deviation is a decision and not a habit.

The deviation rule is three steps, and all three are mandatory. Deviate: set the priority judgment says, not the one the grid says. Record: write the grid's answer, the priority you set, and the fact or reason the grid could not see, in one line in the ticket. Review: bring it to the monthly review. There it becomes either a new example, a new register line, or a one-off that the page does not need to change for. A deviation that is recorded is the policy learning. A deviation that is not recorded is the policy being quietly replaced by whoever is on shift, which is the state Gwen found the desk in.

There are three legitimate reasons for a deviation, and it is worth listing them on the page so that technicians can name theirs. A fact the grid cannot see: a deadline nobody wrote down, a dependency the register missed, a requester who is quietly covering for a colleague on leave and is therefore now two people. A missing line: the register or the examples should have caught this and did not, and the review will add it. A genuinely new situation: something the organisation has never had happen before, which the grid was never going to anticipate. If the reason is none of these, and is instead "it felt important", the grid stands. Even in that case, the feeling is written down anyway, because feelings that recur are facts in disguise.

The test for a good deviation is whether it can be explained to the next technician in one line. "Grid said Medium, set Urgent: requester is the only person running the admissions export this week, cover is on leave, deadline Friday." Anyone can read that and agree or disagree on the facts. "Grid said Medium, set Urgent: seemed important" explains nothing and will be the first line read aloud at the review, with a pause after it. Write the line you would be comfortable hearing read back. Then, if the same line keeps appearing, change the page. In that case, the page is wrong and the technicians are telling you so in the only way the policy gave them.

How to Announce It

Announce the policy to the desk first, then to the department heads, then to everyone, in that order, with a week between each. The desk goes first because the technicians have to agree with the page before anyone else sees it. The desk also goes first because the first hundred tickets rated under the new policy will be theirs. Walk through the examples together, argue about the borderline ones, and change the page where the argument is won. Department heads go second because they will field the first questions from their teams. A department head who can say "yes, I saw this, the despatch line is mine" is worth ten announcement e-mails. Everyone goes last, by which time the page has survived two rounds of informed readers and is unlikely to embarrass anyone.

The all-staff announcement is three sentences and a picture. "From Monday, the IT desk rates every ticket by two questions: how many people are affected, and whether work has stopped. Here is the grid we use and what each level promises. If we set a priority different from the one you asked for, we will tell you what, why and when you will hear from us." Attach the grid picture and a link to the one-page policy. Do not attach the policy itself as a document, because attachments are where policies go to be unread. Link to the page, and keep the page where the link will still work in a year. The craft of announcing a desk's own changes is covered in Announcing the Desk. The short version is that a good announcement is one that could be read aloud in a corridor in under a minute.

Pick a quiet week, not the week after an incident. A policy announced in the aftermath of a bad outage reads as a reaction. The organisation will read the grid looking for the clause that would have prevented last Tuesday. Announce it when nothing is wrong, present it as housekeeping, and let the first month of consistent, explained priorities do the persuading. The form change, if there is one (relabelling the priority field, adding the two questions), goes live the same Monday. That way, the first ticket under the new policy already asks the questions the policy says it will.

Expect a month of questions and treat each one as a reading of the page. "Why is mine Medium?" is answered by the one-sentence reply and a link. "Who decided that?" is answered by section three. "What does Medium actually get me?" is answered by section four. If the person asking is a department head, the question is worth a visit. Every question that the page cannot answer is a sentence missing from it. The first review will have a short list of them. By the second month the questions stop, not because people have given up but because the answers are now where they can find them. Finding them is less effort than asking. That is what a policy that works feels like from outside: slightly boring.

The Five Sections at a Glance

The table is the policy's shape on one line per section: what goes in, roughly how long, who owns the words, and how often they change. Use it to check a draft; a section that has grown past its length is a section that has started doing another document's job.

Add the lengths together and the page is about fifty lines, which is one side of paper in a readable font with a small grid drawn on it. If the draft runs to two sides, the examples have become paragraphs or section four has started quoting the SLA's schedule. In either case, it is a quick fix. The page is not a target to hit. It is a constraint that keeps the policy readable at 08:35, which is the only time it matters.

A Short War Story: Eleven Pages at Harbourview Clinic

Harbourview Clinic was a group practice with sixty staff and a desk of two. It had an eleven-page prioritisation policy that had been written by a consultant and approved by a committee. It had been filed in the practice manager's folder and read, as far as anyone could later establish, by nobody on the desk. The desk ran instead on the instincts of whichever technician was in. The practice manager, Fiona, spent an estimated forty minutes a week arguing with the desk about why reception's tickets were rated the way they were. That was because neither side could point at a rule. The cost arrived on a Wednesday when the interface that delivered blood results from the laboratory to the doctors' screens stopped overnight. The ticket arrived from a receptionist who described it as "results not showing for Dr Patel". The technician on duty, reading one doctor and one screen, rated it Medium and left it until after lunch. Meanwhile, the whole practice's morning clinics ran without results and three patients were asked to come back. The eleven pages, when Fiona finally read them that evening, did in fact classify the results interface as critical, on page seven, in a table, under a heading nobody had ever seen. The desk replaced the document with one page the following week. It had "lab results interface: every clinic, every morning" as the first example under Emergency. Fiona's forty minutes a week fell to about five. The lesson was not that the clinic had lacked a policy. It was that a policy nobody can read in a minute is indistinguishable, at 08:40 on a Wednesday, from having none.

The Policy Page

The block below is the page, with the five sections in order and blanks where the desk's own words go. Fill the definitions from the grid, the examples from your argued-about tickets, the promises from your SLA, and the review box from this month's numbers. It is written to be read in a minute; keep it that way. The example lines in brackets show the shape and should be replaced with your own.

TICKET PRIORITY POLICY — ONE PAGE
Desk: __________________   Owner: __________________   Last reviewed: __________

1. HOW WE DECIDE
   Impact (who is hurt, and how many):
     High   = many people, or any process on the impact register (link: ________)
     Medium = a team, or several people
     Low    = one person
   Urgency (how soon it hurts):
     High   = work has stopped and no workaround holds
     Medium = work continues with a costly workaround, or a deadline falls today
     Low    = can wait a few days
   The grid (impact down, urgency across):
                   Low urgency   Medium urgency   High urgency
     High impact   High          Urgent           EMERGENCY
     Medium impact Medium        High             Urgent
     Low impact    Low           Medium           High
   Our tool shows these levels as: ____________________________________

2. WHAT EACH LEVEL LOOKS LIKE HERE (one line each; refresh yearly)
   EMERGENCY  [whole site offline]  [________________]  [________________]
     Not: [one person's laptop with a spare on the shelf]
   URGENT     [________________]  [________________]  [________________]
     Not: [________________]
   HIGH       [________________]  [________________]  [________________]
     Not: [________________]
   MEDIUM     [________________]  [________________]  [________________]
     Not: [________________]
   LOW        [________________]  [________________]  [________________]
     Not: [________________]

3. WHO MAY CHANGE A PRIORITY
   The requester proposes a priority on the form or in the subject; we read it as
   information about their situation.
   Technicians who see the department queue set and change priorities from the
   grid, with a one-line note in the ticket and a one-sentence reply to the
   requester saying what we set, why, and when they will hear from us.
   Technicians who see only their own tickets flag a concern to a colleague.
   ______________ (role) may set a priority above or below the grid for a
   reason the grid cannot see; the reason and their name are written in the
   ticket and counted monthly.

4. WHAT EACH LEVEL PROMISES (quoted from the SLA at ________; the SLA governs)
   EMERGENCY  respond within ______   resolution target ______
   URGENT     respond within ______   resolution target ______
   HIGH       respond within ______   resolution target ______
   MEDIUM     respond within ______   resolution target ______
   LOW        respond within ______   resolution target ______
   Whenever we set a priority different from the one you asked for, we tell you
   what we set, why, and when you will hear from us.

5. WHEN THE GRID IS WRONG, AND THE REVIEW
   A technician may set a priority the grid did not give when there is a fact
   the grid cannot see, a line missing from the register or the examples, or a
   genuinely new situation. The grid's answer, the priority set and the reason
   are written in one line in the ticket and read at the monthly review.
   Monthly review (fifteen minutes):
     Priority changes: raised ____  lowered ____
     Manager overrides: ____  (from: ______________________)
     Requester proposal matched our decision: ____%  lowest department: ________
     Breaches by priority: E __  U __  H __  M __  L __
     The one change this month: ______________________________________________
     (or "no change", because: _______________________________________________)

One line in the template deserves defending, which is "the SLA governs" in section four. It is there so that when the two documents disagree, as they eventually will, everyone knows which one is right without a meeting. The policy quotes; the SLA promises. Keep the quote current, and the sentence never has to be invoked.

Gwen's eleventh day, replayed: she spends the forty minutes writing the page instead of searching for the old one. Callum is beside her supplying the examples from memory and arguing about two of them. She sends the bursar a link, not an attachment. The bursar reads it in a minute, says "that is clearer than I expected", and asks whether admissions week counts as a peak. It does, and it goes on the register that afternoon. The eleven-page document stays in the shared drive, where it is not hurting anyone. It was never the policy. It was just the longest thing in the folder.

Frequently Asked Questions