Escalation handling checklist

This is the checklist you run the moment you decide a ticket needs escalating. It isn't the policy — that's your escalation matrix, which says where things go. This is the six things you do, in order, so the next person can pick the ticket up cold and the customer never hears silence. Work it top to bottom. If you're skipping a box, know why.

Before you start: is this actually an escalation?

A quick gate, so you don't hand off work you could finish. Escalate when at least one is true; otherwise keep working it.

• Two real attempts and it isn't resolving (the two-touch rule)
• It needs access, authority, or a code change I don't have
• I can't reproduce it and the customer can
• The blast radius is growing — more tickets, same root cause
• It's approaching SLA with no clear path to resolve
• It's a "never sits in the queue" type — security, legal, Trust & Safety, payments at scale
• A named or contractual account is blocked
• My gut says it's bigger than it looks — I'd rather a lead tell me it's fine

If none are true, it's still yours. Escalating a ticket you could have closed just moves your work onto someone slower to it.

1. Confirm severity

Severity is about impact and blast radius, not customer tone. A calm email reporting a data leak is Sev1; an angry ticket about a typo is Sev4. Set it before you route — it decides who you wake and how fast the clock runs.

• Picked a severity from the criteria above, not from how loudly the customer is asking
• Wrote one line on why this sev — which criterion it meets
• Started the response clock: I know the deadline and it's on the ticket
• If it's Sev1/Sev2, notified the named owner or on-call now, before I finish the writeup

Severity is a dial, not a label — re-grade the moment reality changes. Anyone can raise it; only a lead lowers it, and notes why.

2. Gather context (before you touch anyone else)

Collect it once so the next owner never has to re-ask the customer. Everything here goes in the ticket — not in your head, not in a DM.

• Customer and account named, with their SLA / contract tier
• Impact in one plain sentence — what they can't do, not the raw error string
• Steps to reproduce, or "can't reproduce" plus exactly what I tried
• Scope: one user, one account, or many? (search for duplicate tickets on the same root cause)
• When it started, and whether it's constant or intermittent
• Environment: product/version, browser or app, region, plan
• Relevant IDs — ticket link, order/transaction, request ID, error code, log and screenshot links
• What I've already tried, with the result of each, so no one repeats it

If you'd have to ask the customer one more question to fill these in, ask it now — not after the handoff, when it costs a day.

3. Set customer expectations

Before the ticket leaves your hands, the customer hears from you. Silence during an escalation is what turns a bug into a complaint.

• Told the customer it's being escalated, and to whom by role (not a name they'll go chase)
• Set a concrete next-update time — a real timestamp with a timezone, never "soon" or "ASAP"
• That promised time is one I (or the next owner) can actually hit
• Gave a workaround if one exists, or said plainly there isn't one yet
• Did not promise a fix, a cause, or an ETA I can't stand behind
• Logged the expectation I set on the ticket, verbatim — e.g. "told them we'd update by 15:00 UTC"

The commitment you just made is now part of the handoff: the next owner inherits your promise, so it has to be written down.

4. Package the handoff (no cold starts)

The next person should be able to act without opening a single side conversation. A handoff missing context isn't a handoff — it's you moving the problem. The escalation note carries:

• Ticket link + customer/account + SLA tier
• Severity and the one-line why (§1)
• Impact in one plain sentence
• Repro steps, or "can't reproduce" + what I tried
• What I've already done — the two touches, so they're not repeated
• The specific ask — what I need this owner to do or decide
• Customer's last message + the expectation I set, with the update time
• Routed to the right place per the escalation matrix — a named owner or on-call rota, not "the team"

Self-check: could someone who has never seen this ticket act on it right now? If not, it isn't packaged yet.

5. Track ownership

A ticket with no name is an unowned ticket. Ownership transfers on acknowledgement, not on send.

• Tagged the named owner or on-call rota — a person or a rota, never just a channel
• Got an explicit "I've got it" before I let go — no silent handoffs
• No ack within my window (e.g. 15 min for Sev1/Sev2)? I re-pinged or went up a level
• Reassigned/flagged the ticket so the system shows who owns it now
• Until someone acknowledges, I still own it — I haven't dropped it in a queue and walked away

If you can't get an ack, escalate the lack of an ack. That's its own problem, and it's on the clock too.

6. Close the loop

The escalation isn't done when it's fixed — it's done when the customer knows and the record is clean.

• Told the customer the outcome in plain language: what happened and what's resolved
• Hit — or explicitly reset — every update time I promised along the way
• Removed or confirmed the workaround is no longer needed, if one was in place
• Noted the root cause on the ticket; if it'll recur, logged it for product/eng and drafted a macro
• For Sev1/Sev2: post-incident follow-up sent within the timeframe I promised
• Tagged the ticket as an escalation with its reason and route, so the pattern shows up in review
• If the routing went wrong or bounced back, flagged it — that's a matrix gap to fix, not a one-off

The one-line version

Pin this above the queue for the days when there's no time to read the rest:

Confirm severity → gather context → tell the customer and set an update time → package a cold-start-proof handoff → get an explicit "got it" → close the loop with the customer and the record.

Escalating is not failure. Sitting on something you can't fix is.