tonone-ai 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.
If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.