Support escalation path
Route tickets from first response to engineering.
Every support team has an escalation path; far fewer have one written down. This template maps the full journey of a ticket: documentation deflection at the front door, Tier 1 triage, Tier 2 specialists, and the handoff to engineering when a real bug is confirmed — with every branch converging on a close-and-survey step so nothing falls through the cracks.
The structure mirrors how mature support orgs actually work. Deflection comes first because it's the cheapest resolution. Each tier gets a decision diamond, because the question "can this level resolve it?" is what drives the routing. And the fix-shipped node closes the loop back to the customer instead of letting engineering escalations vanish into a backlog.
When to use this template
- Onboarding new support hires — a single diagram explains the routing rules faster than a wiki page, and shows exactly when to escalate instead of struggling alone.
- Support and engineering alignment — the "Bug confirmed?" diamond is where the two teams meet. Agreeing on what crosses that line prevents both premature escalations and ignored bug reports.
- Process audits — overlay real ticket volumes on each branch to find where tickets stall, then fix the slowest hop instead of guessing.
How to adapt it
Rename the tiers to match your org, then layer in your own routing rules:
- Add a priority check after ticket creation so P1 incidents skip straight to Tier 2 or an on-call rotation.
- Insert an account manager notification branch for enterprise customers before the engineering escalation.
- Split "Fix shipped" into hotfix and next-release paths if your team distinguishes urgent patches from scheduled releases.
Open the template in the editor and drag the nodes into your own shape — visual edits regenerate clean Mermaid code, ready to paste into your support runbook or internal wiki.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Ticket created] --> B{Answered by docs?}
B -->|Yes| C[Send article + close]
B -->|No| D[Tier 1 support]
D --> E{Resolved?}
E -->|Yes| F[Close + CSAT survey]
E -->|No| G[Tier 2 specialist]
G --> H{Bug confirmed?}
H -->|No| F
H -->|Yes| I[Escalate to engineering]
I --> J[Fix shipped]
J --> F
Frequently asked questions
- How do I document a support escalation process?
- Start from the moment a ticket is created and trace every handoff: self-service deflection, Tier 1, Tier 2, and the engineering escalation. Each decision point becomes a diamond in the flowchart, and every path should eventually reach a close state. This template gives you that skeleton — rename the tiers and add your own SLA gates.
- What is a support tier in an escalation flowchart?
- A tier is a level of expertise a ticket can be routed to. Tier 1 handles known issues with playbooks, Tier 2 specialists dig into product-specific problems, and confirmed bugs escalate to engineering. Drawing the tiers as separate nodes makes ownership explicit, so nobody wonders whose queue a stuck ticket is sitting in.
- Why should every path in an escalation diagram end in a close step?
- Because tickets that never reach a terminal state are tickets that get lost. In this diagram every branch — docs deflection, Tier 1 resolution, Tier 2 fixes, and shipped engineering fixes — converges on a close-and-survey node. If you can't draw a path from a node to close, you've found a gap in your real process.
- Can I add SLA timers or priority levels to this flowchart?
- Yes. Add a priority decision diamond right after ticket creation that routes urgent tickets straight to Tier 2, or annotate each edge label with its SLA target, such as first response within 4 hours. Mermaid edge labels accept free text, so timing rules live right on the arrows where reviewers will see them.