Managing Request Priorities Without Chaos

Managing request priorities without chaos comes down to three rules: define priority from impact (how many people or how much work is affected) and urgency (how soon it hurts), not from how loudly someone asks; let the desk — not the requester — set the final priority; and work the queue by deadline, with priority setting the deadline. Add a small, explicit path for genuine emergencies, and review priority changes monthly so "urgent" keeps its meaning.

Why priorities collapse

Every desk that lets requesters choose priority ends up in the same place: most requests are "high" or "urgent". It's rational — people want their thing done first — and it destroys the signal. Agents then fall back to first-in-first-out or to whoever complains most, and the genuinely urgent request waits behind a dozen "urgent" font-change requests.

Impact × urgency

IT service management practice (as in ITIL-based incident management) derives priority from two separate questions:

• Impact: how much damage? One person inconvenienced, one person blocked, a team blocked, the whole company affected?
• Urgency: how fast does it get worse? Can it wait until next week, or is money, safety or a deadline at stake today?

Then a matrix turns the two into a priority:

	Urgency: low	Urgency: medium	Urgency: high
Impact: one person, workaround exists	Low	Low	Normal
Impact: one person blocked	Low	Normal	High
Impact: team blocked	Normal	High	Urgent
Impact: company-wide	High	Urgent	Urgent

Splitting the question makes people answer honestly. "Is your whole team blocked?" is harder to inflate than "How urgent is this?"

Write definitions people can apply

Four levels, each with a one-line definition and an example, published where people file requests:

• Urgent — many people can't work, or there's a security, safety or legal risk right now. Example: nobody can sign in.
• High — one person or a small group can't work, no workaround. Example: a new starter's laptop won't boot on day one.
• Normal — something is broken or needed, but there's a workaround or it can wait days. Example: a second monitor for home.
• Low — a nice-to-have or an improvement. Example: a new shared folder structure.

Each level maps to a response and resolution target — that's how priority becomes a deadline. The mechanics of targets are in the SLA tracking guide.

Who sets priority?

The requester describes; the desk decides. Ask requesters the two impact and urgency questions (or let them describe the problem freely), then have triage confirm the priority. An AI model can suggest a priority from the text — LetRelay suggests category and priority and applies them automatically only above a confidence threshold — but a person owns the final call, and the requester sees the result.

This removes the incentive to inflate: choosing "urgent" doesn't make it urgent; describing a blocked team does.

Work the queue by deadline, not by label

Once priority sets a deadline, sort the queue by deadline — the soonest first. That automatically balances priority against age: a low-priority request from two weeks ago eventually rises above today's normal ones instead of starving forever. It also means agents don't have to juggle labels; the top of the list is the next thing to do. The data side is covered in building an internal help desk with Next.js and Supabase.

A worked triage example

Five requests arrive on a Tuesday morning. The requester marked all of them "urgent".

Request	Impact	Urgency	Priority	Target
"The whole sales team can't open the CRM"	Team blocked	High — deals closing today	Urgent	Response 15 min, fix ASAP
"My laptop won't turn on, I start presenting at 2 pm"	One person blocked	High — deadline today	High	Response 1 h
"Need access to the Q3 finance folder"	One person, can work on other things	Medium	Normal	1 business day
"Printer on floor 3 is jammed"	Several people, other printers exist	Low	Normal	1 business day
"Could we get a standing desk?"	One person, no blocker	Low	Low	5 business days

Triage takes a minute per request because the questions are concrete. Each requester sees the confirmed priority and its deadline, and the reason: "You can work on other things while you wait — due tomorrow noon." Most people accept a clear, honest deadline far more readily than an unexplained wait.

Two follow-ups make the next Tuesday easier: the CRM outage gets a problem record so it doesn't recur, and the finance-folder request goes into the knowledge base as "How to request access to a shared folder", with the approver named.

Priority vs order of work

Priority isn't the whole story of what an agent does next. Within the same deadline window, prefer:

1. Quick wins that unblock people — a five-minute fix for someone who's stuck beats a two-hour task for someone who isn't.
2. Requests close to breaching — the deadline-sorted queue shows these first.
3. Work that prevents future requests — fixing the cause of a repeated problem.

That judgment belongs to the agent. The system's job is to make deadlines visible and honest, not to micromanage the order.

The genuine emergency

Some things can't wait for the queue at all: an outage, a security incident. Give them a separate path:

• A clearly labelled way to raise it (a specific category or a phone number), with a definition so it isn't used for everyday requests.
• An immediate notification to the on-call person, not just a queue item.
• A dedicated space for the people handling it — see team rooms — and one public status update rather than many side conversations.

Google's SRE guidance on on-call applies: pages must be rare and actionable, or people stop responding. If the emergency path is used weekly, either you have a reliability problem or the path is being misused.

The VIP problem

Executives' requests often jump the queue informally. Pretending otherwise doesn't work, so make it explicit and bounded:

• Define whose requests get a tier bump (e.g. one level up in urgency) and write it down.
• The bump changes the deadline, visibly, in the system — not through a side-channel message to a favourite agent.
• Review how often it's used.

Visible rules are fairer than invisible favours, and they protect agents from being blamed for other requests slipping.

Stop priority drift

Priorities degrade quietly. A monthly ten-minute review keeps them honest:

• Distribution — what share of requests were urgent and high? If it's creeping up, definitions are being stretched.
• Changes — how often triage changed the requester's priority, and in which direction.
• Breaches by priority — if urgent requests breach as often as normal ones, urgent isn't getting different treatment.

These come from the events table, not the current state; see help desk metrics that matter.

Priorities across teams

When a request needs two teams — IT to provision, finance to approve — the second team may not share the first's sense of urgency. An operational level agreement between them ("finance approves urgent purchases within 4 business hours") makes the priority survive the handoff. See SLA vs OLA vs KPI.

FAQ

How do you prioritize help desk requests?

Rate impact (how many people or how much work is affected) and urgency (how soon it gets worse), map them to a priority with a matrix, and let the desk confirm it. Priority then sets each request's deadline, and the queue is worked by deadline.

Should requesters choose their own priority?

They should describe impact and urgency; the desk should set the final priority. Letting requesters pick labels leads to nearly everything being marked urgent.

What's the difference between impact and urgency?

Impact is how much damage — how many people or how much work is affected. Urgency is how quickly the damage grows or a deadline arrives.

How do I stop everything being marked urgent?

Publish clear definitions with examples, ask about impact and urgency instead of priority, have triage confirm it, and review the distribution monthly.

Sources

• Wikipedia — Incident management
• Atlassian — Incident management
• Wikipedia — Eisenhower matrix
• Google SRE Book — Being on-call
• Axelos — ITIL service management