The User for Whom Everything Is Urgent

Nadia sees the name in the queue before she sees the subject, and her shoulders go up. Ticket 7312, Emergency: "The shared calendar shows my meetings in the wrong colour." Last Thursday it was an Emergency about a folder that needed renaming. The week before, an Emergency about a mouse. And three weeks before that, also an Emergency, his laptop died at 08:30 on the morning of a tenant hearing. He could not open the case file, and that emergency was real. The desk got to it at 11:15 because by then nobody was reading his tickets carefully. Nadia knows all this. She also knows that she is about to skim the ticket, set it to Low, and feel slightly ashamed about both.

The everything-is-urgent user is a requester whose tickets arrive at the top priority regardless of what is in them. Every desk has one, and most have two or three. The temptation is to treat the pattern as a fact about the person's character. It is not. It is a fact about what the person has learned. What they have learned was taught to them by a system, often by the desk itself. This article is part of our Prioritization Frameworks series. It is about handling the pattern without ever handling the person badly.

It covers why the pattern is a response rather than a trait. Next come the three causes behind it: being ignored before, having no other lever, and real pressure from above. The consistent response that the desk gives whatever the requester picks follows, then what a month of that response looks like on a real queue. Next come the honest conversation and when to have it. Then come the three situations in which the requester's manager should hear about it, and how to say it. The desk's own part in making the pattern and a conversation script in plain words finish the article. The sentence for changing a priority is covered in Who Decides the Priority. This article assumes you have it and is about using it fifty times with the same person.

It Is a Pattern, Not a Person

The requester who marks everything Emergency is doing something that has worked for them, or that they believe has. And that is the whole of the explanation. People repeat what works. If the only tickets that ever got a same-day reply were the ones marked Emergency, then Emergency is what you mark. That is not because you are unreasonable but because you have been paying attention. The desk that calls this user "difficult" has usually taught them the behaviour and then graded them on it.

Start by looking at the history before looking at the person. Pull the requester's last twenty tickets and read them in order. Most tools can filter or search by the requester's e-mail address, which brings back everything they have raised. Each ticket's history then shows every priority change and every reply. Look for the ticket where the pattern started. It is nearly always there: a ticket marked Medium that waited nine days with no update. That was followed by a ticket marked Emergency that was answered in an hour. The requester ran an experiment. The desk supplied the result.

Treating the pattern as a trait does two kinds of damage. The first is to the requester, who is now being read less carefully than anyone else in the building. That means the one time they have a real emergency the desk misses it, as Nadia's desk did with the laptop and the hearing. The second is to the desk, which has started sorting tickets by sender rather than by content. A desk that does that has quietly stopped prioritising. A requester's name is not a cell in the grid. (It is not even a column.)

The useful stance is that the requester is giving the desk information, and the information is "I expect to be ignored unless I shout". That is a sentence about the system. And it has a fix, which is to make the system stop rewarding shouting and start rewarding tickets. The fix takes a month and consists almost entirely of the desk doing what it said it would do, at the time it said. Nothing about it is clever. Nothing about it is quick, either.

Cause One: The Desk Once Ignored Them

The commonest cause is a ticket that vanished. Somewhere in the requester's history is a reasonable request, marked at a reasonable priority, that went into the queue and did not come out. There was no reply, no update, no sign that anyone had read it. That lasted until the requester chased, and chased again, and finally walked over to the desk. That experience teaches a lesson, and the lesson is that a normal priority is a hole. The desk's black hole, described in The Seven Ways Support Quietly Fails, has a graduating class, and its members mark everything Emergency.

The repair for this cause is not a conversation; it is a track record. The requester needs to see three or four tickets, marked at the right priority by the desk. Each must be answered inside the promised time, updated when the desk said it would be, and closed with a reply rather than a status change. After the fourth, the lesson has been contradicted by evidence, and most people update on evidence. After the first, nothing has changed, and a conversation at that point is a promise with no history behind it. Build the history first and talk second.

The track record has to be visible, which means updates even when there is nothing to report. "Still waiting for the part; I will update you Thursday either way" is an update. To a requester who has been ignored before it is the whole point. The cadence for these messages is a subject of its own, in Follow-Up Cadences That Keep Tickets Moving; for this requester, err towards one more update than you think is needed. Silence is what they are listening for. Do not give them any.

Cause Two: The Form Gives Them One Lever

The second cause is design. A requester who wants to say "this matters to me, please do not lose it" has, on most forms, exactly one way to say it. And that is the priority drop-down. There is no field for "I am nervous about this", no box for "my manager asked me to raise it". There is no way to say "not urgent but please acknowledge". The form offers five words, and the top one is the only one that sounds like it will be read. The requester pulls the lever they were given. It would be strange if they did not.

The repair here is partly the form and partly the reply. On the form, ask the questions the desk actually needs (how many people, has work stopped, is there a deadline today). Label any priority field as the requester's view rather than the decision. Which fields earn their place is covered in the intake series. The short version is that a good form makes the priority drop-down unnecessary. In the reply, acknowledge what the lever was trying to say. "I can see this matters; it is logged, it is Medium by our definitions because the workaround holds, and you will hear from me by Wednesday." The requester wanted to be heard. Say so, and then say when.

A desk can also give the requester a second lever, which is a real one. "If something changes, such as the workaround failing or a deadline appearing, reply to the ticket and tell me the fact, and I will re-rate it." That sentence hands them a way to raise a priority legitimately, by supplying information rather than volume. Most requesters use it well once they know it exists. The drop-down was never the lever they wanted. It was the only one in reach.

Cause Three: The Pressure Is Real and Comes From Above

The third cause is that the requester is telling the truth about the pressure and wrong about its source. Their manager wants the thing done today and said so in a tone that did not invite discussion. The requester has passed that tone along the only way the form allows. The urgency is real; it is just not the desk's definition of urgency. It is a fact about a manager's afternoon, and the requester is the messenger. It is poor form to shoot the messenger even when the messenger has selected Emergency for a wallpaper change.

Recognise this cause by the language. Tickets driven by pressure from above say "I have been asked to", "my manager needs", "we have been told". They often name a time that is somebody else's deadline. The repair is to find the real requester, which is the manager, and to have the facts conversation with them, courteously, through the ticket. "Thanks, I can see Sam has asked for this by two. Could you tell me what the two o'clock is for, so I can rate it properly?" Sometimes the answer is a board meeting, which is a fact, and the cell moves. Sometimes the answer is that two o'clock was a figure of speech. Either way, the requester is no longer standing between the desk and their own manager, which is a kindness to the requester.

Where the manager is the persistent source, the pattern will not change until the manager hears about the grid, and that is covered below. Until then, treat the requester as a colleague relaying a message, because that is what they are. The desk's quarrel, where it has one, is with a management style that uses "urgent" as a synonym for "please". That is a quarrel with a system, not with the person who carried the note.

The Consistent Response

Whatever the requester picks, the desk's response is the same, every ticket, for as long as it takes. Read the ticket properly, as carefully as anyone else's. Rate it with the grid, from the facts in it, as described in Impact Times Urgency in Practice. Set the priority, write the note, send the one-sentence reply with the new priority, the fact, and the time. Keep the time. Update when you said you would. Close with a reply. Then do it again on the next one, identically, with no change in warmth and no change in speed. Consistency is the whole method, and it is harder than it sounds because it is boring.

Never punish the pattern by slowing down, and never reward it by speeding up. A desk that leaves this requester's tickets to the end of the day as a lesson has confirmed their belief that normal priorities are holes. It has done so on purpose. A desk that jumps on their Emergencies to make the shouting stop has confirmed that shouting works. Both responses teach the lesson the desk is trying to unteach. The requester's tickets get exactly the treatment the grid gives everyone else's: no faster, no slower, no colder. The grid is the one colleague who never gets tired of anybody.

The hardest part of the consistent response is continuing to read. By the tenth Emergency about a cosmetic fault, the technician's eye starts to slide off the ticket, and that is the moment the real one arrives. Build a small habit against it: for this requester, read the first three lines twice, and ask the four grid questions out loud. It costs twenty seconds. It is also, when you think about it, exactly what you owe every requester, which is the uncomfortable thing about the everything-is-urgent user. They make the desk notice how little attention it was paying to everyone.

What a Month of It Looks Like

Here is a month of tickets from Imogen, a buyer at Redbrook Engineering. It is a firm of eighty that makes pump housings and runs a desk of two. Every ticket arrived marked Emergency. The table shows what the desk set, the fact that decided it, and whether the promise was kept. The kept promise is the only column that changes anything. Read it as a record of the desk's behaviour, not Imogen's; Imogen's behaviour is the input, and the desk is the thing under review.

Two things happened over the month, and the table shows both. The first is ticket 7428, a real Urgent, which the desk caught because it was still reading. Imogen will remember it as the time the desk moved fast when it mattered. The second is ticket 7455, which arrived marked High rather than Emergency. One step down the ladder, unprompted, after five kept promises. That is what the change looks like when it begins. It does not look like an apology or a thank-you; it looks like a drop-down set one notch lower. If you are not looking for it you will miss it.

The Honest Conversation

Have the conversation after the track record exists, not before, and have it in person or by phone, never in a ticket reply. Three or four tickets rated by the grid and answered on time is enough history to point at. The conversation is five minutes. It happens somewhere neutral (their desk, not yours; a corridor is fine). Its purpose is to say two things. Here is how we rate tickets, and here is what you can do to get the right rating every time. It is not a telling-off. It is a tour of the machine.

Open with what you have noticed, stated as a fact and without an adjective. "I noticed your last few tickets came in marked Emergency, and I wanted to explain how we set priority so you know what to expect." Then explain the grid in two sentences: who is hurt and how many, how soon it hurts, and the ladder that comes out. Then point at a ticket of theirs that the grid rated correctly and the desk delivered on time, so the explanation has evidence attached. Then ask the one question that matters: "Was there a time a ticket of yours got lost? I would like to know, because that is what I am trying to fix." Then stop talking and listen.

The answer to that question is nearly always cause one, two or three, and once you know which, you know what to offer. If they were ignored once, offer the track record and ask them to hold you to it. If the form gave them one lever, give them the second lever: reply with a fact and the desk will re-rate. If the pressure comes from above, offer to take the facts conversation to the manager yourself, so that they are not carrying it. End by agreeing one concrete thing, usually "mark it how it feels, and I will rate it by the grid and tell you why every time". That way, both sides know what happens next.

Do not say "most of your tickets are not really emergencies", because they know, and hearing it from the desk converts a colleague into a defendant. Do not quote the policy at them; policies are for the wall. Do not promise to treat their tickets specially, in either direction, because special treatment is the thing you are dismantling. And do not have the conversation on a day they have just raised one, because then it is about that ticket. The conversation is about the pattern. Pick a quiet Wednesday. Bring nothing.

When Their Manager Should Hear It

The requester's manager hears about the pattern in exactly three situations, and in none of them is the message a complaint about the requester. The first is when the pattern persists for a month after the conversation and the track record, and the desk's time is measurably going on re-rating and replying. The second is when the pressure is coming from the manager, and the requester is the messenger. In that case, the conversation that needs to happen is with the manager, and the requester should not be the one having it. The third is when a genuine emergency was nearly missed because of the pattern. That is a risk to the manager's team, and they would want to know.

The message is facts, counts and the grid, with no adjectives and no names used as evidence. "Over the last two months, eleven of the twelve tickets from your team marked Emergency were rated Low or Medium by our definitions, which are these. The one that was a real emergency, the shared mailbox on the fourth, we caught. But it was close, and I would rather it were not close. Could we agree how your team raises urgent work?" Then show the grid and offer the second lever (a fact in the ticket moves the rating). Ask what deadlines the team has that the desk does not know about. The manager usually supplies two, and both go on the critical-process list described in Making Business Impact Visible.

Frame the manager as the person who can fix it, because they are, and never as the person at fault, even when they are. A manager who has been using "urgent" to mean "please" will hear the counts, look at the grid, and in most cases stop. In those cases, they stop because they did not know the word had a clock attached. A manager who insists their team's work is simply more urgent than everyone else's is making a claim about impact. And the honest answer is "show me which process, and I will put it on the list". Occasionally they can. Then the grid was wrong, and the manager was right, and the desk says so.

Keep the desk's own manager informed before, not after. One line: "I am going to talk to Sam about the Emergency pattern from purchasing; here are the counts." The desk's manager may know something about Sam's team, or may want to have the conversation themselves, or may say go ahead. What they should never experience is Sam arriving at their door with a complaint about a conversation they did not know had happened. A message that goes up one chain should be known to the other chain first. That is not politics. It is just manners with a diagram.

The Desk's Own Part

Most everything-is-urgent users were trained by a desk, and the honest review asks which part of the training this desk did. Did a ticket vanish? Then the triage habit needs fixing, and the whole desk benefits, not just this requester. Does the form offer a priority drop-down with no definitions? Then the form is recruiting new members every week. Does the desk reply faster to Emergencies than to Mediums by more than the SLA says it should? Then the desk is paying people to pick Emergency, and the payment is being accepted. The requester is the symptom. The desk is the thing with settings.

The most dangerous reflex is the one Nadia felt at the top of this article: the shoulders going up, the skim, the Low set before the ticket is read. It is dangerous because it feels like efficiency and is actually the desk declining to do its job for one named person. Watch for it in yourself and in the team, and name it when you see it. "We are not reading Rowan's tickets any more" is an uncomfortable sentence to say out loud at a stand-up. It is the sentence that saves the one that matters.

And once in a while, this requester is right, and the desk should say so with some grace. The eighth Emergency is a real one; the grid rates it Emergency; the desk drops everything and fixes it in forty minutes. The reply should say what it would say to anyone: what was wrong, what was done, and thank you for raising it. Nothing about the previous seven. The requester has just seen the system work exactly as described, for them, and that is worth more than any conversation. They will remember it. So, if you are honest, will you.

A Short War Story: The Fourth Emergency at Ashgrove Housing

Ashgrove Housing, a housing association with two hundred staff and a desk of three, had a housing officer called Rowan. Every ticket from him for about a year arrived marked Emergency. The desk's response had drifted, without anyone deciding it, into reading his tickets last and lightly. On a Friday in winter at 15:50 Rowan raised his fourth Emergency of the week. This one said that the out-of-hours repairs line was giving an engaged tone. That line routed tenants' emergency calls to the on-call plumber and electrician. The technician on triage saw the name, saw the word, and left the ticket for Monday with the other three. Over the weekend a boiler failure in a block of twenty-two flats went unreported to anyone who could act. The association paid for emergency hotel rooms for six households and a weekend callout at penalty rates. The Monday review traced the whole sequence back to a ticket that had been in the queue, correctly described, since ten to four on Friday. The desk had not been wrong about Rowan's first three tickets that week. It had been wrong to stop reading. And the cost of the fourth was the lesson that the consistent response is not a courtesy to the requester but a safety measure for everyone else.

The Conversation Script

The block below is the five-minute conversation in plain words, with the three branches for the three causes. It is written to be read once beforehand, not recited; the words should be yours, but the order and the omissions should be these. Have it after the track record exists, in person, on a quiet day.

THE PRIORITY CONVERSATION — FIVE MINUTES, IN PERSON

BEFORE
  [ ] Three or more of their tickets rated by the grid and delivered on time
  [ ] Their ticket history read; the ticket where the pattern started found
  [ ] Your own manager told, in one line, that you are having the conversation
  [ ] Not a day on which they have just raised a ticket

OPENING (a fact, no adjective)
  "I noticed your last few tickets came in marked Emergency, and I wanted
   to explain how we set priority, so you know what to expect from us."

THE GRID IN TWO SENTENCES
  "We ask two things: how many people are affected, and whether work has
   stopped or can wait. Those two answers pick the priority, and the
   priority sets how fast we promise to respond and fix."

THE EVIDENCE (point at one of their tickets)
  "Your ticket about ____________ came in as Emergency; by those answers it
   was ________, we said ________, and we did it by ________."

THE QUESTION (then listen)
  "Was there a time a ticket of yours got lost or went quiet? I would like
   to know, because that is the thing I am trying to fix."

BRANCH A — THEY WERE IGNORED BEFORE
  "That should not have happened. Here is what you will see from now on:
   a reply with the priority and a time, an update when I said, and a
   message when it is done. Hold me to it."

BRANCH B — THE FORM GAVE THEM ONE LEVER
  "Mark it how it feels; I will rate it by the grid and tell you why each
   time. If something changes, a deadline appears or the workaround stops
   working, reply with that fact and I will re-rate it the same day."

BRANCH C — THE PRESSURE COMES FROM ABOVE
  "It sounds like these deadlines are coming from ________. Would it help
   if I talked to them about how we rate things, so you are not in the
   middle? I will tell you what we agree."

CLOSE (one concrete agreement)
  "So from now on: ______________________________________. Thanks for
   talking it through."

DO NOT SAY
  "Most of these are not real emergencies."
  "The policy says..."
  "I will make sure your tickets get special attention."
  Anything about the ticket they raised today.

AFTERWARDS
  [ ] One-line internal note on their next ticket: conversation held on
      ________, agreed ________
  [ ] Keep every promise on their next five tickets without exception
  [ ] Review the pattern in one month; involve their manager only if it
      persists, if the pressure is theirs, or if a real emergency was
      nearly missed

The script does not change when the requester is senior, or when they are the desk's own manager's peer. It does not change when they are the person who approves the desk's budget. The grid does not know who they are and the conversation should not either, beyond the ordinary courtesy owed to anyone. If anything, a senior requester with the pattern is the most valuable person to have the conversation with. The rest of their team is watching what they pick.

Nadia's ticket 7312, replayed: she reads it twice, rates it Low, writes the note, sends the sentence with a day attached, and keeps the day. Three tickets later she has the conversation. She learns that in the spring a ticket of Rowan's about a broken door-entry system sat for eleven days at Medium with no update. During that time, tenants used the fire exit. That ticket is why everything is urgent now. The desk did not know, because the desk never asked, and the drop-down was the only way Rowan had been given to say it.

Frequently Asked Questions