Support escalation SOP template

Escalation is a handoff, and handoffs are where context dies. This template defines the three things every escalation needs: a trigger (when), a route (to whom), and a package (what travels with it). Teams that write these down stop paying the restart tax on their hardest tickets.

Escalation triggers

Escalate on category, not on frustration

Define the automatic triggers concretely. A workable starter set: any security or data-privacy concern; any legal threat or regulator mention; a confirmed bug with no workaround affecting a paying customer; any request beyond your written authority (refund limits, contract terms); and any SLA about to breach. When a trigger fires, escalation is the procedure — not a judgment call about whether you should be able to handle it.

The two-touch rule

If a ticket has bounced twice without a plan — two replies that didn’t move it — escalate on the third touch. Long, polite, going-nowhere threads are the silent SLA killers.

AI handoffs count

If an AI agent works your queue, its stand-down conditions are escalation triggers too: low confidence, missing account data, an angry-tone detection, or a request outside its action envelope. The AI’s escalation should look like your best teammate’s — summary, evidence, open questions — not a raw transcript dump.

Escalation routes

One route per category

Map each trigger to a destination: security → the security owner, directly, immediately; bugs → the engineering triage queue with severity attached; billing authority → the team lead; legal → whoever owns legal, never freelanced by support. Publish the map next to this SOP and keep it to one screen.

Severity and clock

Attach a severity when escalating: S1 (customer down, no workaround) gets a response commitment in minutes and interrupts people; S3 (annoying, workaround exists) joins a queue. State the expected response time to the customer only after the receiving team confirms it.

The escalation package

What travels with the ticket

Every escalation carries: a two-sentence summary of the problem, what has been tried and its results, the exact error or evidence (links, not screenshots-of-text), the customer’s plan and impact, and the specific question you need answered. If the receiving person must re-read the whole thread to start, the escalation failed.

Ownership doesn’t teleport

The escalating teammate keeps owning the customer until someone explicitly accepts the ticket. “Escalated” is a state of the problem, not a goodbye. Set a follow-up check on every escalation you send.

Closing the loop

Tell the customer the truth

On escalation, the customer gets: what’s happening, who has it now (by team, not by name), and when they’ll hear next. On resolution, the fix in plain words.

Feed the pattern back

Weekly, skim the escalations: any trigger firing constantly is either a product bug to fix or a missing authority to grant the front line. Escalation volume is a roadmap, if anyone reads it.