How should a scaling customer support team document their ticket escalation procedures?
A scaling support team should document escalation procedures with clear tier definitions, escalation criteria for each tier, required information for handoff, and response time expectations. The SOP should answer two questions instantly: "Should I escalate this ticket?" and "What information does the next tier need from me?" Without this, agents either escalate everything or sit on critical issues.
What does an escalation SOP include?
| Component | Details |
|---|---|
| Tier definitions | Tier 1: General inquiries, known issues. Tier 2: Technical troubleshooting. Tier 3: Engineering/product team |
| Escalation criteria | Specific conditions that trigger an escalation (not "when you can't solve it") |
| Required handoff info | Steps attempted, customer context, error messages, account ID |
| Response SLAs | Tier 1: 4 hours. Tier 2: 8 hours. Tier 3: 24 hours |
| Escalation path | Who to contact, which Slack channel, which Jira project |
| De-escalation criteria | When to send a ticket back down to a lower tier |
How do you define escalation criteria clearly?
Vague criteria like "escalate if you cannot resolve" leads to inconsistent behavior. Instead:
| Escalate To | When |
|---|---|
| Tier 2 | Customer reports data loss, integration failure, or account access issues after standard troubleshooting fails |
| Tier 3 (Engineering) | Confirmed bug reproducible in multiple accounts, or system outage affecting multiple customers |
| Manager | Customer threatens legal action, requests above refund authority, or VIP account with specific SLA |
Record the escalation workflow with Glyde — from identifying the escalation trigger in the ticket, to collecting required information, to routing the ticket in your support tool. New agents can follow the recorded steps exactly, reducing misrouted escalations.
This answer is part of our guide to process documentation.