Who Decides the Priority of a Ticket

Ticket 6230 arrives at 08:52 from a claims handler, marked Emergency, subject "second monitor flickering". Maya reads it twice. The monitor flickers when the cable is nudged; the handler can work on the laptop screen; nothing is on fire. The priority field sits there with Emergency in it, and the Emergency clock has been running for four minutes. Maya's cursor hovers over the drop-down. Changing it feels like telling the handler that her problem does not matter, and the handler has been nothing but polite. Leaving it means the desk's tightest promise is now attached to a cable.

Every desk has a Maya and every Maya has this moment, several times a day. The way out of it is to know whose decision the priority is. The answer has three parts. The requester, the person who raised the ticket, proposes a priority, because they know things about their own situation that the desk does not. The desk, the person triaging or working the ticket, decides the priority, because the desk can see the whole queue and the requester can see one ticket. The manager, usually the person the desk reports to, arbitrates when the first two disagree and the disagreement matters. Three parties, three jobs, in that order. This article is part of our Prioritization Frameworks series. This article is about the second job and the etiquette around it.

It covers the three parties and why the roles are in that order. Next is why the requester cannot be the final decider without it being a slight, and who on the desk may change a priority. Then comes the one courteous sentence that lowers a self-selected priority without an argument. After that comes logging every change so the decision can be read later. Next is what a manager override is, how to record it, and when to push back once. Last come raising a priority above what the requester asked for and a reply template for each case. How to decide what the priority should be is covered in Impact Times Urgency in Practice. This article assumes you have a grid and is about who gets to apply it.

Three Parties and the Order They Come In

The requester proposes. When a form offers a priority field, or an e-mail subject carries the word "urgent", that is a proposal. The requester is telling the desk how the problem feels from where they sit. The proposal is useful. The desk should read it as a fact about the requester's situation ("this person believes they are blocked") rather than as a fact about the queue. A proposal is not a demand, and most requesters know that. The ones who do not are a separate article, and it is The User for Whom Everything Is Urgent.

The desk decides. Somebody with the whole queue in front of them sets the priority and writes a line about why. They know what else is open, who is on shift, which processes are critical, and what the grid says. On a desk of one, that person is you. On a desk of five with a triage rota, it is whoever has the triage slot. The decision is the desk's because the desk is accountable for the promises that hang off it. A requester who sets a Emergency has not promised anything to anyone. The desk has.

The manager arbitrates. When the requester and the desk disagree and the disagreement is about something that matters, one person with the authority to say "do it anyway" makes the call. The disagreement may be about a deadline the desk cannot verify, a process nobody has written down, or a cost the requester can see and the desk cannot. The call is recorded as the arbitrator's. Arbitration is rare on a desk that has a grid, because most disagreements turn out to be about facts. Facts can be checked without a manager. Arbitration is for the rest.

The order matters more than the roles. A desk that lets the requester decide has handed its clocks to whoever is most anxious. A desk that lets the manager decide every ticket has a manager who triages and a desk that waits. A desk where the desk decides, after hearing the proposal and before any arbitration, runs itself most of the time. That is the point of having a rule. Most priority decisions should be boring. The exciting ones are the ones to write down.

Why the Requester Cannot Be the Decider

The requester sees one ticket. That is not a criticism; it is their job to see one ticket, their own, and to describe it well. What they cannot see is the other thirty-one tickets open this morning, the one that is a payroll server, and the technician who called in sick. They also cannot see the fact that four other people have also chosen Emergency since nine. Priority is a comparison between tickets, and only the party who can see all of them can make it. Asking the requester to set the priority is asking them to rank things they cannot see against the one thing they can.

The form makes this worse by offering the choice. A drop-down with five words in it asks the requester to translate a feeling into one of the desk's terms, with no definitions and no consequences shown. Most people pick the second-highest option, on the reasonable grounds that the highest sounds dramatic and the middle sounds like being ignored. (The middle option on a priority drop-down is the loneliest word in the building.) The result is a queue in which almost everything is High, and High therefore means nothing. Whether to offer the field at all is a form-design question for another series. If you do offer it, label it "how urgent does this feel to you?" and treat the answer as exactly that.

There is a second reason, which is about promises. In a desk with a service level agreement (an SLA), the priority starts a clock. The agreement is the written promise of how fast the desk responds and resolves at each priority. The clock is a commitment the desk has made to the whole organisation. The requester did not make that commitment and is not accountable for it. Letting them set the priority lets them spend the desk's promise on their own behalf, which is generous of the desk and unfair to everyone else in the queue.

None of this means the proposal is ignored. A requester who marks a ticket Urgent has told you something, and the correct response is to read the ticket more carefully, not less. Sometimes they are right, and the desk sets it Urgent and says so. Sometimes they are right for a reason they did not write down, and one question finds it. The proposal is the start of the conversation, and the desk owes it a reply either way.

Who on the Desk May Change a Priority

Anyone who can see the whole queue may set a priority; anyone who can see only their own tickets should not. This is the practical line, and it is the one most permission systems draw. A trainee who sees only the tickets assigned to them cannot compare a ticket against the queue, so their priority changes would be guesses. A technician who works the department's whole queue can compare, so they decide. Many tools draw exactly this line in their permission roles. They have a trainee role that sees only its own assigned tickets and cannot change priority. They also have a technician role that sees the department queue and can. If your tool does not enforce the line, enforce it by habit, and write it into the policy.

On a desk with a triage rota, the triager decides at intake and the assignee may revise. Triage is the first reading of each new ticket, where it gets a priority, an owner and a first reply. The discipline is described in First-Touch Discipline. The triager's priority is the first decision, made quickly with what the ticket says. The assignee, an hour later with the requester on the phone, may learn something that moves the cell. In that case, they may change the priority with a note saying what they learned. Both decisions are the desk's. Neither needs a manager.

Changing a priority downward should be as ordinary as changing it upward, and on most desks it is not. Raising feels like service; lowering feels like a confrontation. The asymmetry is where priority inflation comes from: every ticket that is raised stays raised, and the ladder fills from the top. Treat both directions as the same act, done for the same reason (the facts put the ticket in a different cell). Use the same one-line note and the same courteous reply. A desk that only ever raises priorities is not deciding. It is agreeing, slowly.

The One Courteous Sentence

Lowering a self-selected priority takes one sentence, and the sentence has three parts: what the desk set it to, why in terms of facts, and what the requester will get. "I have set this to Medium, since you can work on the laptop screen for now, and I will have a replacement cable to you by tomorrow lunchtime." Twenty-eight words. No apology, because nothing has been done to them. No lecture about the policy, because they did not ask for one. No "unfortunately", because nothing is unfortunate. A decision, a reason, and a promise.

The reason must be a fact, not a verdict. "Since you can work on the laptop screen" is a fact the requester can check and correct. "Since this is not really an emergency" is a verdict, and verdicts invite replies that begin "Well, actually". If the fact is wrong (the laptop screen is cracked too; the handler cannot work at all), the requester says so, the cell changes, and the priority goes up with a thank-you. The sentence is built so that the only way to argue with it is to supply a new fact. A new fact is exactly what the desk wants.

The promise at the end is what makes the sentence land. A lowered priority with no promise reads as "your problem matters less and I am not telling you when I will deal with it". A lowered priority with a time attached reads as "your problem is in the queue and here is when". The time comes from the SLA target for the new priority, or from the technician's own estimate. Either way it is a time, not "as soon as possible", which is a phrase that has never once reassured anyone. If the promise cannot be kept, the sentence is not finished yet.

Here is the same sentence for a different ticket, to show the shape holds. "I have set this to High rather than Emergency, since the second till is taking cards and the queue is moving, and I will be in the store within the hour to look at till two." And for a ticket that is going up rather than down: "I have raised this to Urgent, since the whole finance team is affected and month-end is Thursday, and you will hear from me before eleven." Same three parts, every time, whichever way the priority moved. Say it enough times and the requesters start writing their tickets in the same shape. That is the quietest training programme a desk ever runs.

Logging the Change

Every priority change is written down twice. It goes once in the ticket's history, which the tool should do for you. It goes once in a note that says why, which the tool cannot do. The history is the ticket's own record of events: who changed what, when, from which value to which. Most ticketing tools record every priority change there automatically, with the agent who made it and the time. Check yours by changing the priority on a test ticket and reading the history. If it records nothing, the note below has to carry the old value as well. What no tool can record is the reasoning, because the reasoning was in the technician's head. That is what the note is for.

The note is one line and it lives as an internal note, visible to the desk and never mailed to the requester. "Lowered Emergency to Medium: laptop screen works, cable replacement ordered." "Raised High to Urgent at request of finance manager (Dana): month-end close Thursday." The requester gets the courteous sentence; the note gets the shorthand. The two say the same thing in different registers, and the note is the one that survives the technician's holiday. In most tools an internal note is never sent to the requester. That makes it the right place for the shorthand and the wrong place for anything you would not want read aloud at the review. Confirm that yours stays internal before you rely on it.

Log the change because three people will want to read it later and none of them will be you. The next technician, who picks up the ticket cold and needs to know why it is Medium when the subject says Emergency. The requester's manager, who asks in two weeks why their team's tickets keep being lowered, and deserves an answer built from facts rather than memory. And the desk's own monthly review, which reads the changes in bulk and asks whether the grid is being applied or improvised. A change with no note beside it cannot be reviewed. It can only be defended.

A desk that logs every change gets a useful side effect: a count. How many tickets were lowered this month, how many raised, by whom, from what, and how often the requester's proposal matched the desk's decision. A high match rate means the requesters have learned the grid. A low match rate in one department means that department has not been told the grid exists. A high rate of manager overrides means either the grid is wrong or the manager is triaging. Both are worth knowing by the end of the first month.

When a Manager Overrides

A manager override is a priority set by authority rather than by the grid. It is legitimate exactly as long as it is recorded as what it is. Someone with the standing to say "work this next" has said it; the desk does it; the ticket's note says who asked and why. "Set to Urgent on instruction of Sam (IT manager), reason: board pack due 15:00." The override is not a defeat for the desk and not a flaw in the grid. It is the third party doing the third job, which the rule always allowed for.

The desk may push back once, and only once. If the override looks wrong, the technician says so in one sentence, with the facts. Say the ticket is one person with a workaround, and there are two Urgents already open. The sentence is: "Just so you know, that puts it ahead of the shared-drive fault affecting all of finance." The manager hears it, decides, and the decision is recorded. If the manager says do it anyway, the desk does it anyway, cheerfully, with the note. Pushing back twice is an argument, and an argument with the person who arbitrates is a strange use of a morning.

There are two managers in most override stories, and they do different things. The requester's manager can supply a business case the desk did not have: "my team is holding the regulator's audit next week and that spreadsheet is the evidence". That is a fact, and facts change the cell without anyone overriding anything. The desk's manager can supply authority: "I know it is one person; do it first." That is an override. Treat the first as information and the second as instruction, and record them differently, because at the review they will mean different things.

Count overrides and look at them monthly. One or two a month is a manager doing their job. Ten a month from the same manager is a manager who has become the triager. In that case, the fix is a conversation about the grid rather than a bigger note field. Ten a month for the same kind of ticket is a grid with a missing row. In that case, the fix is in the policy, which is where A Prioritization Policy You Can Write Down picks the subject up. The override log is the cheapest audit of the policy there is.

Raising a Priority Nobody Asked For

The desk raises priorities as well as lowering them. The raise with no requester behind it is the one that shows whether the grid is really in use. A ticket arrives marked Low: "the backup report says the overnight job did not finish". The requester, a diligent clerk in finance who noticed the e-mail, chose Low because nothing is wrong with her computer. The desk reads it, knows that the backup covers every store's sales data, and sets it High, with a note and a reply that thanks her for sending it. Nobody asked. The grid did.

Raising above the proposal happens for three reasons, and all three are facts the requester could not see. The ticket touches a critical process the requester did not know was critical. The ticket is the fourth of its kind this morning. Four tickets about the same fault are one fault with medium impact, which is the moment to link them under one incident name. Most tools can relate tickets to each other in some way, and the linked set then carries one story. Or the ticket has a deadline the requester mentioned in passing and did not think to weight. In each case the raise comes with the same three-part sentence as the lowering, and the same note. Otherwise, the requester will wonder why their Low has suddenly become somebody's afternoon.

Be sparing with raises that come from inside the desk, because they are the other source of inflation. A technician who finds a ticket interesting, or who likes the requester, or who wants the clock to justify working it now, can raise it with a note that says "looks important". That is not a fact. The test is the same as for a lowering: the note must name the cell and the fact that put it there. A raise with no fact is a preference wearing a priority's clothes. The grid does not care what the technician finds interesting. Neither, by Friday, will the review.

Who May Do What, in One Table

The table is the permission model in plain words, for desks whose tools enforce it and desks whose tools do not. The roles are generic; map them to your own presets. The column for the requester is deliberately short.

Two refinements fit most desks. A senior technician may be given the manager's override authority for out-of-hours work, so that a weekend Emergency does not wait for a phone call. Record it the same way. And a desk serving several departments may let each department's manager override only their own department's tickets. That keeps the arbitration close to the people who know the process. Neither refinement changes the rule. The desk decides, and everything else is an exception with a name on it.

A Short War Story: Silent Changes at Stonebridge Insurance

Stonebridge Insurance ran a desk of four for a claims operation of ninety. For about a year the desk lowered requester priorities without saying anything, on the theory that a reply would start an argument. Maria, a claims team lead, had three tickets lowered from Urgent to Medium in one month. There was no message, no note and no change in the time she was told to expect. She drew the natural conclusion, which was that the desk had decided her team did not matter. She took the three tickets to the IT manager. Having no notes to read and no reasoning to defend, the manager reversed all three on the spot. The manager told the desk to leave claims' priorities alone in future. For the next six weeks claims marked everything Urgent. The queue carried eleven Urgent tickets at once. A genuine one, the document scanner that fed every new claim into the system, waited most of a day behind a request for a bigger mailbox. The desk had been right about all three of Maria's tickets. It had cost them the authority to be right about anything, for want of a sentence that would have taken forty seconds to write.

The Priority-Change Reply

The block below is the reply, in three versions, with a matching internal note for each. Paste it into the desk's predefined replies and fill the blanks; the shape is the same whichever way the priority moved. Keep the three parts in order (new priority, the fact, the time) and resist adding a fourth part, which is usually an apology and is never needed.

PRIORITY-CHANGE REPLY — THREE VERSIONS

1. LOWERED FROM THE REQUESTER'S CHOICE
   Reply to requester:
   Thanks for the details. I have set this to ________, since
   ____________________________________________ (the fact: workaround,
   number of people, no deadline today). I will ____________________
   by ______________ (day and time), and I will let you know sooner if
   that changes. If anything above is wrong, reply and I will look again.

   Internal note (not mailed):
   Lowered ________ to ________: ______________________________________

2. RAISED ABOVE THE REQUESTER'S CHOICE
   Reply to requester:
   Thanks for sending this in. I have raised it to ________, since
   ____________________________________________ (the fact: critical
   process, several people affected, a deadline today). You will hear
   from me by ______________.

   Internal note (not mailed):
   Raised ________ to ________: _______________________________________

3. SET BY A MANAGER'S INSTRUCTION
   Reply to requester:
   I have set this to ________ and it is being worked now. You will hear
   from me by ______________.

   Internal note (not mailed):
   Set to ________ on instruction of ______________ (role), reason given:
   ____________________________________________. Desk view at the time:
   ____________________________________________ (one line; optional).

RULES FOR ALL THREE
  One sentence for the priority, one fact, one time.
  No apology, no policy quotation, no "unfortunately".
  The note is written before the reply is sent.
  The time in the reply is one the desk can keep.

The third version carries an optional line for the desk's own view at the time, and it is worth keeping. It is not a complaint; it is the single sentence of pushback, preserved, so that when the override is reviewed the manager can see what the desk saw. Most of the time the two views agree and the line is empty. When they do not, the line is the most useful sentence in the ticket.

Maya's ticket 6230, replayed: she sets Medium. She writes the note ("Lowered Emergency to Medium: laptop screen works, cable on order"). She sends the sentence ("I have set this to Medium, since you can work on the laptop screen for now, and I will have a replacement cable to you by tomorrow lunchtime"). Then she moves on. Elapsed time, ninety seconds. The handler replies "thanks, that's fine", because it is. The Emergency clock, which had been running on a cable for four minutes, is returned to the organisation to be spent on something that needs it. That is the whole job, and it is a smaller job than it feels at 08:52.

Frequently Asked Questions