Routing and Escalating High-Priority Tickets

When speed matters most

Most tickets follow a calm path. This workflow is for the ones that don't — the Urgent and High-priority requests where minutes count and a missed target has real consequences. It's built around the SLA radar and the route action.

Understand the SLA math first

Every ticket's clock is set by its priority:

Priority	Target	Enter "High" risk when ≤	Enter "Watch" when ≤
Urgent	4h	~1h remaining	~2h remaining
High	8h	2h remaining	4h remaining
Normal	24h	6h remaining	12h remaining
Low	72h	18h remaining	36h remaining

The radar labels each open ticket Healthy → Watch → High → Breached, and stops the clock only at Resolved/Closed/Archived (then it reads Met). The escalate count on the radar summary is simply Breached + High — the tickets that need action now.

The escalation playbook

Open the SLA radar and read the summary: total open, breached, high, watch, and escalate.
Start at the top. The radar sorts Breached first, then High, then Watch — so work top-down.
For a Breached ticket: escalate immediately. Assign a named owner, post an internal update, and, if severity warrants, raise the priority so it's unmistakably at the front of the board.
For a High-risk ticket: assign an owner and send a substantive reply before the window closes. Even an honest "we're on it, next update by X" resets expectations.
Route to the team that can actually fix it. Use route to move the ticket to Platform Operations, Account & Access, or the right queue, which stamps the owner team automatically.
Confirm the timer stops only when the issue is genuinely resolved — never move to Resolved just to clear the radar.

Using priority and severity together under pressure

Severity: Critical justifies the escalation — it's the impact signal you point to.
Priority: Urgent sets the 4-hour clock — it's the response commitment.
Set both when a ticket is a genuine incident. Once you've mitigated, you can drop priority to Normal for the cleanup while leaving severity: Critical for the record.

A realistic example

At 2:10 p.m. the radar shows one Breached ticket ("Payments declined for all customers," created 4.5 hours ago against a 4-hour urgent target) and two High. You open the breached ticket, set Severity: Critical, assign the on-call operations lead, and route it to Platform Operations. You post an internal owner update and reply to the customer within two minutes. For the two High tickets, you assign owners and send status replies before their windows close, moving both to Waiting Internal with a promised next-update time. By 2:45 the escalate count is back to 1, and only the active incident remains — which resolves at 3:05, stopping its clock at Met.

Tips

Check the radar's escalate number first — it's the single figure that tells you how much fire is on the board.
Set an explicit due date for tickets tied to a promised deadline; the radar will measure against your real commitment instead of the priority default.
A fast, honest holding reply on a High-risk ticket is worth more than a perfect answer that arrives after the window closes.
Never resolve a ticket just to clear it from the radar — a false Resolved erodes trust and your CSAT.

Troubleshooting

A ticket shows Breached even though I replied. Replies don't stop the clock. The timer measures time-to-response from creation (or the due date); only Resolved/Closed/Archived stops it.

Routing didn't raise the priority. If you passed a priority in the route action it overrides the queue default. Omit it to inherit the queue's default, or set it explicitly to the level you want.

The radar looks empty during a busy day. The radar only lists open tickets. If everything at-risk was resolved, it clears — verify by checking the dashboard's open count.