## TL;DR
Urgency is a claim, not a fact, so score it before you act. Every ticket gets two quick scores, customer impact and time sensitivity, and you work the ones that are high on both. The rest get a real owner and a promised update time instead of sitting in a pile that all feels like fire. Triage like this takes two minutes per ticket and ends the day where you worked the right things first.

## The query

```text
how to prioritize tickets when everything is urgent
```

## Use this when

- The whole queue is marked urgent and nobody knows where to start
- Agents work tickets in arrival order and SLAs keep breaching
- One customer is shouting while a bigger problem sits quiet
- You are training new agents on what "urgent" actually means

## Not for

- Deciding how many agents to hire or schedule
- Burnout and workload policy
- Automated priority routing rules
- Incident management for full outages

## Steps

### 1. Split urgency into two separate scores

Impact: how many users affected and how badly (1 = one user, annoyed; 5 = many users, blocked). Time sensitivity: what breaks if this waits an hour (1 = nothing; 5 = money lost or data at risk). Write both numbers on the ticket.

Expected output: every ticket in the queue carries two numbers, impact and time sensitivity.

### 2. Work the high/high intersection first

High impact plus high time sensitivity goes first, always. High impact but low time sensitivity goes second. Loud tickets with low impact and low sensitivity go last, even if the customer is typing in caps.

Expected output: a clear top of queue that survives the loudest customer test.

### 3. Give the waiting tickets a visible owner

Everything you defer gets a name and an update time: "I have this, next update by 3pm." Customers panic less when a person owns it than when a ticket sits silent.

Expected output: no deferred ticket without an owner and a promised update.

### 4. Time-box the scoring to two minutes

Set a timer. Triage that takes longer than the fix costs you the morning. Fast scoring with a decent rubric beats perfect scoring you never finish.

Expected output: the full queue scored before you start working anything.

### 5. Re-score once mid-shift

Things change. A medium ticket becomes high when the workaround stops working. Scan the queue again halfway through and move anything that escalated.

Expected output: no ticket works a stale score all day.

## Ready-to-use scoring card

```text
Impact: 1 (one user, annoyed) to 5 (many users, blocked)
Time: 1 (waiting costs nothing) to 5 (money or data at risk)

Order: 4-5 impact + 4-5 time first
Then: high impact, low time
Then: loud but low impact/time, with an owner and update time
```

## Variant phrasings

### ticket triage when every ticket says urgent

Same two scores. The customer's urgency label is input to time sensitivity, not a verdict.

### how support agents should order their queue

Arrival order is a default, not a strategy. Replace it with impact times time.

### what to do when the support queue is on fire

Score first, then work. Ten minutes of triage saves the hour you would have spent on the loudest ticket first.

## Why it happens

Everything feels urgent because urgency arrives as emotion, from the customer and from the red label, and humans answer emotion with action. But emotion correlates badly with damage. Splitting urgency into impact and time forces the queue to be ordered by what breaks, not who shouts.

## Edge cases

- Enterprise contracts with penalty SLAs: contract terms can override impact scoring. Know which accounts carry them.
- Security reports: treat any credible security claim as high time sensitivity while you verify, even if impact is unconfirmed.
- The CEO's pet ticket: score it honestly, then escalate the conflict to a manager instead of quietly bumping it.
- Two equal top tickets: pick the one closest to resolution and clear it first to reduce cognitive load.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_afF7qW2py3Co2zgSXkK1Vw