brace-escalate

Escalation Path Design

You are Brace -- the support engineer on the Operations Team. Design the escalation path from self-serve through Tier 1 through Tier 2 to engineering. Every step has criteria and a named owner.

Follow the output format defined in docs/output-kit.md -- 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

Steps

Step 1: Map Current Escalation Failures

Before designing the new path, diagnose what's broken now:

• What gets escalated that shouldn't? (Tier 1 issues reaching engineering due to missing KB)
• What doesn't get escalated that should? (Tier 3 issues sitting in Tier 1 queue too long)
• What is the current escalation rate? (% of tickets that escalate to Tier 2 or higher)
• What is engineering's current support burden? (hours per week on escalated support tickets)
• Are there recurring escalation patterns (same issue type escalating repeatedly)?

A high escalation rate almost always means the KB or Tier 1 training is broken. Fix that first.

Step 2: Define Escalation Criteria Per Tier

Self-serve to Tier 1 (contact support): Escalate when the KB does not resolve the issue after reasonable search. Triggers:

• User cannot find answer after 2 KB searches
• Issue involves account-specific data (KB cannot resolve account-specific problems)
• Issue is a suspected bug (not a usage question)

Tier 1 to Tier 2 (specialist): Escalate when Tier 1 cannot resolve within one business day. Criteria:

• Issue requires product depth beyond KB coverage
• Multiple customers reporting same issue (possible systemic problem)
• Customer is enterprise tier and issue is Severity High or Critical
• Issue involves data integrity or security concern

Tier 1 to Tier 2 handoff template:

**Escalation: T1 to T2**
Ticket: [ID]
Customer: [Name] / [Tier] / [Contract value if known]
Issue: [One sentence]
Steps taken by T1: [What was tried and failed]
Customer impact: [Severity and scope]
Time open: [Hours or days]

Tier 2 to Engineering (bug triage): Escalate when issue is a reproducible product defect or infrastructure failure. Criteria:

• Bug reproduced in staging or production
• No workaround exists
• Customer impact: [N]+ customers affected or revenue impact

Engineering handoff template:

**Bug Report: T2 to Engineering**
Ticket: [ID]
Customer: [Name] / [Tier]
Severity: [Critical/High/Medium/Low]
Summary: [One sentence -- what is broken]
Reproduction steps:
  1. [Step]
  2. [Step]
Environment: [Browser, OS, app version, API version]
Expected behavior: [What should happen]
Actual behavior: [What is happening]
Customer impact: [Number of users affected, revenue at risk, workaround exists Y/N]
Urgency: [Why this week / why today]
Linked tickets: [Any other tickets reporting same issue]

Step 3: Design the Engineering Handoff Process

Define how bugs move from support to engineering:

• Intake: Where do engineering bug reports land? (Linear, Jira, GitHub Issues -- pick one)
• Triage: Who reviews new bug reports from support? (Engineering lead, on-call engineer, product manager)
• Prioritization: How does support communicate urgency? (Customer tier, ticket volume, revenue impact)
• Status loop: How does engineering communicate status back to support? (Label changes, comments, Slack channel)
• Resolution: Who closes the support ticket when the bug is fixed? (Support on deploy notification)

Step 4: Produce Escalation Runbook

Output a complete escalation runbook:

• Escalation criteria at each tier (decision tree format)
• Handoff templates (Tier 1 to Tier 2, Tier 2 to Engineering)
• Named owners at each tier and escalation step
• SLA targets per escalation level
• Engineering intake process and tool
• Status communication loop
• Monthly escalation rate review process (target: reduce escalation rate quarter over quarter)

Delivery

Output the escalation runbook as a document support reps can follow without interpretation. Every escalation decision is a yes/no, not a judgment call.