Draft an Escalation Matrix and SLA Document

Workflow area: Customer Support · Tier: Core · Hands-on time: ~30 minutes

An escalation matrix is a decisions-in-advance document — it converts 2 a.m. panic into a lookup. The reason most teams run without one isn't disagreement about the content; it's that the document is fiddly to draft: four severity levels times five attributes times communication templates is a lot of consistent prose. That's a structure problem, and AI eats structure problems. The judgment calls — what actually counts as Sev-1, what targets you can honestly hit — stay with you, decided before the model writes a word.

When to use — and when not to

• Use it when escalations run on tribal knowledgeif "who do I wake up?" has different answers per agent, you need this document this week.
• Use it before signing SLA commitments with customersdraft the internal reality first, then negotiate external promises you can keep.
• Use it after a badly-handled incidentthe post-mortem's "we didn't know who owned it" line is this playbook's trigger.
• Skip inventing targets you haven't validateda matrix promising 15-minute Sev-1 response with no on-call rotation is fiction that will be quoted against you. Draft from your actual staffing.
• Skip contractual SLA language without legal reviewthis playbook produces the operational document; anything that goes into customer contracts (credits, penalties, uptime math) goes through legal.

The recipe

1. 1.

   Decide the judgment inputs first — on one page, with your lead(s). How many severity levels (three or four; four is standard)? What real examples from your last quarter belong at each level? What are your support hours and on-call reality? What response times could you hit 95% of the time — honestly? Fifteen minutes of decisions; everything else is drafting.

2. 2.

   Generate the full matrix from your decisions.

   Copy

   Draft an escalation matrix and SLA document for our support team.
   
   Context: [PRODUCT ONE-LINER]. Team: [SIZE, HOURS COVERED, ON-CALL
   YES/NO]. Customers: [e.g. "B2B, ~200 accounts, 12 on premium
   support"].
   
   Severity levels and my example incidents:
   - SEV-1: [YOUR DEFINITION + 2 REAL EXAMPLES]
   - SEV-2: [SAME]
   - SEV-3: [SAME]
   - SEV-4: [SAME]
   
   Targets I can actually meet (standard / premium):
   - Sev-1 response: [X / Y], resolution-or-workaround: [X / Y]
   - Sev-2 ... [ETC.]
   
   Produce:
   1. SEVERITY DEFINITIONS table: level | definition | concrete
      examples | what it is NOT (boundary cases that look like this
      level but aren't)
   2. SLA TABLE: level | first-response target | update frequency |
      resolution/workaround target | standard vs premium columns
   3. ESCALATION PATHS: per level — who owns it, when it escalates
      (time-based triggers, e.g. "Sev-2 unresolved at 4h → team
      lead"), who is informed vs consulted, and the wake-someone-up
      rule
   4. CUSTOMER COMMUNICATION TEMPLATES per level: initial
      acknowledgment, progress update, and resolution message —
      each under 100 words, with {{placeholders}} for specifics
   5. SEVERITY DISPUTE RULE: what happens when the customer says
      Sev-1 and we assess Sev-3
   6. REVIEW CADENCE: how and when this document gets revisited
   
   Rules: use only the targets I stated — do not improve them.
   Definitions must let a new agent classify a ticket in under 30
   seconds. "What it is NOT" boundaries are mandatory per level.
   

3. 3.

   Stress-test with scenarios. The matrix is only as good as its edge cases. In the same chat:

   Copy

   Classify these 8 scenarios using only the matrix above. For each:
   severity, first action, who gets notified, and which template
   goes out. Flag any scenario where the matrix is ambiguous.
   1. Premium customer's exports fail; workaround exists via UI.
   2. Login is down for all customers at 7pm Saturday.
   3. A customer CEO emails our CEO about a Sev-3 bug.
   [ADD 5 REAL AMBIGUOUS CASES FROM YOUR HISTORY]
   

   Every "ambiguous" flag is a hole to fix in the definitions. A matrix that classified your last quarter's messiest tickets cleanly is ready; one that hasn't been stress-tested isn't.

4. 4.

   Check the templates sound like you at your best. A Sev-1 acknowledgment should read like:

   Copy

   Subject: [{{severity}}] We're on it — {{issue_summary}}
   
   Hi {{name}},
   
   We've confirmed the issue affecting {{affected_function}} and
   it's now our top priority, with {{owner_role}} leading. You'll
   hear from us every {{update_interval}} until it's resolved, even
   if the update is "still working on it."
   
   Next update by: {{time}}.
   

   The load-bearing sentence is the update promise — it's the difference between a customer who waits and one who escalates around you. Only promise intervals your team will keep during an actual fire.

5. 5.

   Socialize, then operationalize. Review with the team (they'll catch the path that routes to someone who left last quarter), get sign-off from whoever owns support, then wire it in: severity field in the helpdesk matching the definitions, templates loaded as macros (pb-33), escalation triggers as helpdesk automations where supported, and the document linked from the team's home page — not buried in a drive.

Make it yours

• On-call runbook companion: ask for a one-page Sev-1 runbook derived from the matrix — first 15 minutes, checklist form — the matrix is the law, the runbook is the drill.
• Internal-teams variant: the same recipe builds escalation matrices for IT helpdesk or internal ops; swap customer templates for stakeholder updates and premium tiers for department priorities.
• Contract alignment pass: paste your customer contracts' SLA clauses and ask the model to diff them against the operational matrix — every mismatch (contract promises 1h, matrix says 4h) goes on a list for legal and sales, before a customer finds it for you.

Quality check

• Targets reflect staffing realityvalidated against your actual coverage, not aspiration.
• Definitions include the "NOT" boundariesthe Sev-2-that-feels-like-Sev-1 case is explicitly settled.
• The scenario stress-test passedyour historical messy tickets classify cleanly.
• Escalation paths name roles, not peopleand every role currently exists.
• The dispute rule existscustomer-claimed severity has a written answer.