Support tools & workflow · SupportRoadmap Docs
Escalation basics in software support
Escalation is handing a ticket to a person or team with more product depth, engineering access, or decision authority. A useful escalation includes reproduction steps, impact, scope, and evidence—not just “please look ASAP.”
By Tom Ulman · Published · Last reviewed
What escalation is
Escalation moves a problem to someone with more access, product depth, or authority: Tier 2, a specialist pod, or engineering. It is not a way to skip reproduction. A weak escalation (“please fix ASAP”) creates ping-pong; a strong one lets the next person start immediately.
When to escalate
- You reproduced (or carefully failed to reproduce) and hit a permissions or code boundary.
- Impact is broad or data-risking and needs an incident process.
- Policy or credit decisions need a manager, not more troubleshooting.
What belongs in the handoff
- Customer impact and scope (who, how many, since when).
- Expected vs actual behaviour.
- Reproduction steps, environment, and user/org IDs.
- Evidence: screenshots, request IDs, sanitised HAR, logs.
- What you already tried and ruled out.
Docs vs Guides
This page defines the concept. For a worked scenario writing an engineering-ready packet, use Engineering-ready escalation. Capture browser evidence with HAR files.
Common mistakes
- Escalating before asking one clarifying question that would unlock the case.
- Omitting impact so engineering cannot prioritise.
- Pasting secrets into the escalation instead of redacting.
Related concepts
Primary sources
Prefer an ordered path? Open the related roadmap skill and work through it with the curated resources.
Practise this skill