Escalation Matrix

Full escalation decision trees, handoff checklists, and cross-team escalation protocols for multi-tier support operations.

Escalation decision tree

Should I escalate this ticket?

1. Can I resolve this with available macros and knowledge base?
   YES -> Resolve at current tier
   NO  -> Continue

2. Do I have access to the tools/systems needed to investigate?
   NO  -> Escalate to the tier with access
   YES -> Continue

3. Have I spent more than 30 minutes actively working on this?
   YES -> Escalate to next tier with findings
   NO  -> Continue investigating

4. Is this a confirmed bug or requires a code change?
   YES -> Escalate to Tier 3 (Engineering)
   NO  -> Continue

5. Has the customer explicitly requested escalation?
   YES -> Escalate immediately (honor all escalation requests)
   NO  -> Continue

6. Is the SLA at risk (> 75% elapsed)?
   YES -> Escalate with SLA urgency flag
   NO  -> Continue working at current tier

Priority-based escalation timing

These are maximum times. Escalate sooner if the decision tree above indicates it.

Escalation handoff checklist

Before escalating any ticket, complete this checklist:

[ ] Ticket summary written (1-2 sentences of the core issue)
[ ] Steps already taken documented (numbered list)
[ ] Customer information confirmed:
    - Name, plan tier, account age
    - Any relevant account flags (VIP, at-risk, enterprise)
[ ] Reproduction steps documented (if applicable)
[ ] Screenshots or logs attached (if applicable)
[ ] Customer sentiment noted (frustrated / neutral / understanding)
[ ] SLA status noted (time remaining before breach)
[ ] Specific ask for the next tier stated clearly:
    - "Need database query to check account state"
    - "Need code fix for [specific bug]"
    - "Need access to [internal tool] to investigate"
[ ] Customer notified of the escalation (use escalation notice macro)

Common handoff failures:

• "Please look into this" with no context = bad handoff
• Forwarding the entire ticket thread without a summary = bad handoff
• Escalating without trying basic troubleshooting = premature escalation

Tier-to-tier escalation paths

L1 to L2 escalation

When: Issue requires specialized product knowledge, access to internal tools, or deeper technical investigation beyond standard troubleshooting.

Routing by product area:

L2 response expectations:

• Acknowledge escalation within 30 minutes during business hours
• Provide initial assessment within 2 hours
• Either resolve or escalate to L3 within the SLA window

L2 to L3 (Engineering) escalation

When: Confirmed bug, data inconsistency, performance issue, or security concern requiring code-level investigation.

Engineering escalation template:

Title:        [BUG/PERF/DATA/SEC] - Brief description
Priority:     [P1-P4]
Customer:     [name, plan, impact scope (1 customer / multiple / all)]
SLA status:   [time remaining]

What happened:
  [customer-reported symptoms]

What we investigated:
  [L1/L2 troubleshooting steps and findings]

Reproduction steps:
  1. [step]
  2. [step]
  Expected: [what should happen]
  Actual:   [what happens instead]

Evidence:
  [logs, screenshots, error messages, request IDs]

Customer-facing workaround:
  [if one exists, describe it; if not, state "none available"]

Requested action:
  [specific ask: fix bug, investigate data, review performance]

Engineering response expectations:

• P1: Acknowledge within 15 minutes, actively investigate immediately
• P2: Acknowledge within 1 hour, provide initial assessment within 4 hours
• P3/P4: Acknowledge within 1 business day, schedule fix in next sprint

Management escalation

When: SLA breach on P1/P2, customer threatens churn or legal action, repeated escalations for same issue (3+), VIP dissatisfaction.

Management escalation includes:

Escalation reason:   [SLA breach / churn risk / repeated issue / VIP]
Ticket history:      [link to ticket + summary of all related tickets]
Customer value:      [ARR, plan tier, account age, expansion potential]
Business risk:       [churn probability, contract renewal date, legal exposure]
What has been tried: [summary of all support and engineering efforts]
Recommended action:  [specific recommendation for management decision]

Cross-team escalation protocols

Support to Product

When: Feature request from multiple customers (3+), workaround is unsustainable, or product behavior does not match documentation.

Protocol:

1. Log feature request in the shared tracker with customer count and business impact
2. Tag the relevant product manager in the tracker
3. Do not promise timelines to customers - say "logged with our product team"
4. Product PM reviews support-tagged items weekly

Support to Sales/Success

When: Customer expresses expansion interest, contract renewal concerns, or dissatisfaction that may affect retention.

Protocol:

1. Internal note on the ticket with the customer's exact words
2. Direct message to the assigned account manager or CSM
3. Include: customer name, current plan, what they said, recommended action
4. Flag urgency: "informational" vs "action needed this week"

Support to Legal

When: Customer mentions legal action, regulatory complaint, data breach inquiry, or GDPR/CCPA data request.

Protocol:

1. Do not make any commitments or admissions to the customer
2. Respond with: "I've escalated this to our appropriate internal team who will follow up with you directly within [timeframe]"
3. Immediately notify support manager + legal team via designated channel
4. Attach full ticket history and customer communication

Escalation metrics to track

Monthly review questions:

1. Which product areas generate the most escalations? (knowledge gap signal)
2. Which agents escalate most frequently? (training opportunity)
3. Which escalations bounce back? (handoff quality issue)
4. Are engineering escalations increasing? (product quality signal)

Macro Templates

Ready-to-use support response templates organized by scenario. Customize placeholders and tone for your brand voice before deploying. Never send a macro blind - always review populated fields before submitting.

Placeholder reference

Tone rules:

• Open with empathy or acknowledgment, never the problem statement
• Close with a clear next step or expectation
• Avoid internal product names, error codes, or jargon the customer would not recognize
• Match severity: apologetic for outages, informational for how-to, warm for resolution

Acknowledgment templates

First response - general

Hi {{customer_name}},

Thanks for reaching out. I've received your request about {{product_area}} and
I'm looking into it now.

I'll have an update for you {{timeframe}}. If anything changes on your end in
the meantime, just reply to this thread.

Best,
{{agent_name}}

Actions: Set status to "In Progress". Apply product area tag.

First response - urgent (P1/P2)

Hi {{customer_name}},

I understand this is urgent and I'm treating it as a top priority. Our team is
actively investigating the {{product_area}} issue you reported.

I'll update you within the next 30 minutes with what we find. You don't need to
do anything on your end right now.

{{agent_name}}

Actions: Set status to "In Progress". Set priority P1 or P2. Notify team lead.

First response - needs more information

Hi {{customer_name}},

Thanks for reaching out about {{product_area}}. To get this resolved quickly,
I need a few more details:

1. {{question_1}}
2. {{question_2}}

Once I have these, I can investigate right away.

Best,
{{agent_name}}

Actions: Set status to "Waiting on Customer". Pause SLA clock.

Status update templates

Update - investigating root cause

Hi {{customer_name}},

Quick update on ticket {{ticket_id}}: we've identified the {{product_area}} issue
and our team is actively investigating the root cause.

I'll have another update for you within {{timeframe}}. No action needed on your end.

{{agent_name}}

Update - fix in progress, ETA known

Hi {{customer_name}},

We've identified the root cause of the {{product_area}} issue and a fix is in
progress. We expect it to be deployed by {{timeframe}}.

I'll confirm as soon as it's live.

{{agent_name}}

Update - fix in progress, ETA unknown

Hi {{customer_name}},

Our engineering team is actively working on the {{product_area}} issue. We don't
have a firm ETA yet, but I'll update you every {{timeframe}} until it's resolved.

Thanks for your patience.

{{agent_name}}

Update - escalated to engineering

Hi {{customer_name}},

I've escalated your {{product_area}} issue to our engineering team for deeper
investigation. They're looking into it now.

I'm staying on this and will keep you updated. Your ticket reference is {{ticket_id}}.

{{agent_name}}

Actions: Add "escalated-engineering" tag. Assign to engineering queue.

Resolution templates

Resolution - issue fixed, steps to verify

Hi {{customer_name}},

Good news - the {{product_area}} issue has been resolved. Our team deployed a
fix and verified it's working correctly.

Could you try {{specific_action}} and confirm everything is working on your end?
If you hit any issues, just reply here and I'll jump right back in.

Thanks for your patience throughout this.
{{agent_name}}

Actions: Set status to "Pending". Apply "resolved" tag. Set 48-hour auto-close timer.

Resolution - workaround provided

Hi {{customer_name}},

While our team works on a permanent fix for {{product_area}}, here is a workaround
that will unblock you:

{{workaround_steps}}

I've flagged your account to notify you when the full fix ships. Is there
anything else I can help with in the meantime?

Best,
{{agent_name}}

Actions: Apply "workaround-provided" tag. Add to notification list for fix release.

Resolution - known issue, linked to status page

Hi {{customer_name}},

The {{product_area}} issue you reported is a known incident we are actively
working to resolve. You can track live updates here: {{link}}

I'll also send you a direct notification as soon as it's resolved. No action
is needed on your end.

{{agent_name}}

Actions: Apply "known-incident" tag. Subscribe customer to status page updates.

Closure templates

Closing - no response from customer (7 days)

Hi {{customer_name}},

I'm closing this ticket since we haven't heard back. No worries - if you still
need help with {{product_area}}, just reply to this thread and it will reopen
automatically. We're here whenever you need us.

Best,
{{agent_name}}

Actions: Set status to "Solved". Apply "auto-closed-no-response" tag.

Closing - duplicate ticket

Hi {{customer_name}},

I've merged this ticket with {{ticket_id}}, where we are already working on
your {{product_area}} issue. All updates will come through on that thread.

Thanks,
{{agent_name}}

Actions: Set status to "Closed". Apply "duplicate" tag. Link to primary ticket.

Closing - feature request logged

Hi {{customer_name}},

Thanks for the suggestion about {{feature_description}}. I've logged this as a
feature request with our product team - your feedback directly influences our roadmap.

I don't have a timeline to share right now, but I've tagged your account so
you'll be among the first to know if we build this.

Is there anything else I can help with?

Best,
{{agent_name}}

Actions: Set status to "Solved". Apply "feature-request" tag. Log in product tracker.

VIP and escalation templates

VIP - acknowledgment with named CSM

Hi {{customer_name}},

Thank you for reaching out. I'm {{agent_name}}, and I'm personally handling your
request about {{product_area}}.

I've also looped in {{csm_name}}, your dedicated Customer Success Manager, who
is copied on this thread.

I'm treating this as a top priority and will have an update for you within
{{timeframe}}.

{{agent_name}}

Actions: Apply "VIP" tag. CC CSM. Set P1 priority. Route to VIP queue.

Escalation received - enterprise path

Hi {{customer_name}},

I'm {{agent_name}} from our Enterprise Support team. I've received the escalation
on your {{product_area}} issue and I'm taking ownership now.

I've reviewed the full context from {{previous_agent_name}} and you won't need
to repeat anything.

I'll have a detailed update for you within {{timeframe}}.

{{agent_name}}
Senior Support Engineer

Actions: Assign to enterprise queue. Add escalation note. Notify CSM.

Macro maintenance schedule

SLA Playbook

Detailed SLA policy configurations, breach response procedures, and reporting templates for customer support operations.

SLA policy tiers

Standard tier (free / starter plans)

Business hours:  Mon-Fri, 9am-6pm (customer's timezone or HQ timezone)
Channels:        Email, help center form

First response targets:
  P1: 1 hour     P2: 4 hours     P3: 8 hours     P4: 24 hours

Resolution targets:
  P1: 8 hours    P2: 24 hours    P3: 48 hours     P4: 5 business days

SLA clock behavior:
  - Runs only during business hours
  - Pauses when status is "Waiting on Customer"
  - Resumes when customer replies

Premium tier (paid plans)

Business hours:  Mon-Fri, 8am-8pm (customer's timezone)
Channels:        Email, help center, live chat during business hours

First response targets:
  P1: 30 min     P2: 2 hours     P3: 4 hours      P4: 8 hours

Resolution targets:
  P1: 4 hours    P2: 8 hours     P3: 24 hours      P4: 48 hours

SLA clock behavior:
  - Runs only during business hours
  - Pauses when status is "Waiting on Customer"
  - P1 tickets: clock runs 24/7 regardless of business hours

Enterprise tier (enterprise contracts)

Business hours:  24/7 for P1/P2; Mon-Fri 8am-8pm for P3/P4
Channels:        Email, help center, live chat, phone, dedicated Slack channel

First response targets:
  P1: 15 min     P2: 1 hour      P3: 2 hours       P4: 4 hours

Resolution targets:
  P1: 4 hours    P2: 8 hours     P3: 24 hours       P4: 48 hours

SLA clock behavior:
  - P1/P2: clock runs 24/7
  - P3/P4: runs during business hours only
  - Pauses when status is "Waiting on Customer"
  - Named account manager monitors all open tickets daily

SLA clock rules

When the clock pauses

When the clock resets vs continues

• Customer replies to a solved ticket: New SLA clock starts (treated as new ticket)
• Agent reopens a ticket: SLA clock continues from where it paused
• Priority changes mid-ticket: SLA adjusts to new priority targets retroactively
• Ticket is merged: Surviving ticket keeps its original SLA clock

Breach response procedures

Pre-breach alerting

75% of SLA elapsed:
  - Notify assigned agent via in-app alert
  - Highlight ticket in queue with yellow warning indicator
  - No escalation yet

90% of SLA elapsed:
  - Notify assigned agent + team lead
  - Highlight ticket in queue with red warning indicator
  - Auto-reassign if agent is offline or at capacity

100% SLA breach:
  - Notify team lead + support manager
  - Log breach in weekly report
  - Trigger post-breach review for P1/P2 breaches

Post-breach actions

For P1/P2 breaches:

1. Immediate manager review - why did the breach occur?
2. Customer outreach - apologize and provide updated resolution timeline
3. Log in breach tracker with root cause category:
   • Staffing gap (not enough agents)
   • Knowledge gap (agent lacked expertise)
   • Process gap (routing or triage failure)
   • Volume spike (unexpected ticket surge)
   • Complexity (issue harder than priority suggested)
4. Review in weekly ops meeting

For P3/P4 breaches:

1. Log in breach tracker with root cause category
2. Review in weekly ops meeting if pattern emerges (3+ breaches same category)
3. No individual customer outreach required unless CSAT survey indicates dissatisfaction

SLA reporting

Weekly SLA report template

Week of: [date range]

Overall compliance:
  First response SLA: [X]% (target: > 95%)
  Resolution SLA:     [X]% (target: > 90%)

By priority:
  P1: [X]% first response | [X]% resolution | [N] total tickets
  P2: [X]% first response | [X]% resolution | [N] total tickets
  P3: [X]% first response | [X]% resolution | [N] total tickets
  P4: [X]% first response | [X]% resolution | [N] total tickets

Breach summary:
  Total breaches:     [N] ([X]% of volume)
  P1/P2 breaches:     [N] (each documented below)
  Root cause breakdown:
    Staffing gap:     [N]
    Knowledge gap:    [N]
    Process gap:      [N]
    Volume spike:     [N]
    Complexity:       [N]

Top 3 actions for next week:
  1. [specific action with owner]
  2. [specific action with owner]
  3. [specific action with owner]

Monthly SLA trend report

Track these metrics month-over-month to identify trends:

Red flags in trends:

• Compliance dropping while volume is flat = process or staffing problem
• Compliance stable but CSAT dropping = premature closures
• Volume rising faster than headcount = scaling problem; plan hiring
• P1 breaches increasing = triage or escalation workflow needs review

SLA negotiation guidelines

When setting SLAs for new customer tiers or enterprise contracts:

1. Start with what you can reliably deliver - promise 80% of your current performance, not your best-case scenario
2. Build in buffer for growth - if you hit 95% compliance at current volume, set the SLA target at the level you can maintain at 150% volume
3. Differentiate on response, not resolution - response time is controllable; resolution depends on issue complexity. Offer aggressive first-response SLAs and reasonable resolution SLAs
4. Define exclusions clearly - maintenance windows, third-party dependencies, and customer-caused delays must be documented upfront
5. Include SLA review cadence - quarterly review clause to adjust targets based on actual performance data

Triage Automation

Auto-triage rule recipes, keyword detection patterns, and routing logic examples for common helpdesk platforms.

Auto-triage rule framework

Every auto-triage rule follows this structure:

Rule name:      [descriptive name]
Trigger:        [condition that activates the rule]
Actions:        [what happens when triggered]
Priority:       [rule execution order - lower number = higher priority]
Exceptions:     [when this rule should NOT fire]

Rules execute in priority order. First matching rule wins unless configured for cumulative execution (all matching rules apply).

Keyword detection patterns

Priority detection keywords

P1 - Urgent (auto-tag + alert):

Keywords:  "down", "outage", "cannot access", "error 500", "503",
           "completely broken", "data loss", "security breach",
           "compromised", "all users affected", "production down"

Rule:
  IF subject OR body contains ANY of the P1 keywords
  AND ticket is from a verified customer (not spam)
  THEN:
    - Set priority to P1
    - Alert on-call support lead
    - Skip L1 queue, route directly to L2
    - Send P1 acknowledgment macro automatically

P2 - High (auto-tag):

Keywords:  "cannot log in", "login failed", "payment failed",
           "stuck", "blocked", "not working", "critical",
           "urgent", "broken", "affecting our team"

Rule:
  IF subject OR body contains ANY of the P2 keywords
  AND NOT already classified as P1
  THEN:
    - Set priority to P2
    - Route to front of L1 queue

P4 - Low (auto-tag):

Keywords:  "feature request", "suggestion", "nice to have",
           "would be cool", "wondering if", "cosmetic",
           "minor", "typo", "alignment"

Rule:
  IF subject OR body contains ANY of the P4 keywords
  AND NOT contains ANY P1 or P2 keywords
  THEN:
    - Set priority to P4
    - Route to general L1 queue

Product area detection keywords

Routing rules

Skill-based routing

Rule: Route by product area tag
Priority: 10

IF ticket has tag "billing"
  THEN assign to billing-support group

IF ticket has tag "api"
  THEN assign to api-support group

IF ticket has tag "auth"
  THEN assign to auth-support group

IF ticket has no product area tag
  THEN assign to general-support group

Customer tier routing

Rule: VIP routing
Priority: 5 (runs before skill-based routing)

IF customer is on Enterprise plan
  OR customer is in VIP account list
  THEN:
    - Add "priority-support" tag
    - Apply Enterprise SLA policy
    - Route to senior-agents group
    - Notify assigned account manager

Language-based routing

Rule: Non-English routing
Priority: 3 (runs before all other routing)

IF detected language is NOT English
  THEN:
    - Add language tag (e.g., "lang-es", "lang-fr", "lang-ja")
    - Route to corresponding language support group
    - IF no language group exists, route to general with "needs-translation" tag

Load-balanced assignment within groups

Rule: Fair assignment
Priority: 20 (runs after routing determines the group)

Within the assigned group:
  1. Filter to agents who are online and not at capacity
  2. Sort by number of open assigned tickets (ascending)
  3. Assign to agent with fewest open tickets
  4. IF tie, assign to agent who has been idle longest

Auto-response rules

Business hours auto-response

Rule: After-hours acknowledgment
Trigger: Ticket created outside business hours

Response:
  "Hi {{customer_name}},

  Thanks for reaching out. Our support team is currently offline and will
  be back at [next business hours start time] [timezone].

  Your ticket (#{{ticket_id}}) has been logged and you'll hear from us
  as soon as we're back. If this is an emergency affecting your production
  service, please email [emergency-email] or call [emergency-phone].

  Best,
  [Company] Support"

Actions:
  - Send auto-response
  - Do NOT start SLA clock until business hours begin (unless P1)

Duplicate detection

Rule: Potential duplicate
Trigger: Same customer email + similar subject within 24 hours

Actions:
  - Flag as potential duplicate
  - Link to the most recent open ticket from same customer
  - Do NOT auto-merge (agent reviews and decides)
  - Add internal note: "Potential duplicate of #[ticket_id]"

Auto-close inactive tickets

Rule: Inactivity auto-close
Trigger: Status is "Waiting on Customer" for 7+ days

Actions:
  Day 5:  Send check-in macro ("Just checking in...")
  Day 7:  Send closing macro ("I'm closing this ticket...")
  Day 7:  Set status to "Solved"
  Day 7:  Add "auto-closed" tag
  Day 7:  Pause - customer reply within 48 hours reopens automatically

Spam and abuse filtering

Spam detection rules

Rule: Spam filter
Priority: 1 (runs first)

IF sender is on blocklist
  OR subject matches known spam patterns (regex library below)
  OR body contains > 5 URLs and no product-related keywords
  OR sender domain is in disposable email list
  THEN:
    - Move to spam queue (do NOT delete)
    - Do NOT send auto-response
    - Do NOT start SLA clock
    - Weekly review of spam queue for false positives

Common spam patterns (regex):

/\b(buy now|limited offer|act fast|congratulations you won)\b/i
/\b(SEO services|web design services|marketing services)\b/i
/(click here|unsubscribe).*(http[s]?:\/\/(?!yourdomain\.com))/i

Abusive language detection

Rule: Abusive content flag
Priority: 2

IF body contains profanity or threatening language
  THEN:
    - Add "review-required" tag
    - Route to team lead queue
    - Do NOT auto-respond
    - Agent responds with empathy-first approach
    - If threats of violence: escalate to management + legal immediately

Rule testing and maintenance

Before deploying a new rule

1. Run the rule against the last 30 days of tickets in dry-run mode
2. Check for false positives (tickets that would be incorrectly tagged/routed)
3. Check for false negatives (tickets the rule should have caught but did not)
4. Target: < 5% false positive rate, < 10% false negative rate
5. Get sign-off from support lead before enabling

Monthly rule review