All templates
State template
SLA response state machine
Track support ticket states from submission through response and resolution SLAs.
Support teams live and die by SLAs — the promises made to customers about how fast you'll respond and resolve issues. This state machine shows every state a ticket passes through and the SLA windows that matter: time to first response, time to resolution, and what happens when you breach. Without this visual, SLA tracking becomes tribal knowledge; with it, every team member knows what "on track" looks like.
When to use this template
- SLA definition — before you buy ticketing software or start enforcing SLAs, map out the states and timing so the whole team agrees on what "resolved" means.
- Escalation runbooks — connect this diagram to your actual escalation procedures so when an SLA breaches, the right person gets notified and knows what to do next.
- Metrics and reporting — use the states to bucket your tickets (how many in "waiting", how many "escalated") and track which state is the biggest bottleneck.
How to adapt it
Customize the states to match your process and SLA tiers:
- Add tier-based routing: create separate flows for P1 (2-hour response) vs P3 (5-day response) so the SLA window is visible on the diagram.
- Insert automation: add a state for "auto-response sent" or "ticket classified by AI" so you track where humans enter the loop.
- Extend resolution tracking: some teams track "pending customer" separately from "resolved" for weeks; add intermediate states if your SLAs are long-tail.
Visual edits flow naturally through the state transitions, so you can evolve this as your support process matures.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
stateDiagram-v2
[*] --> Submitted
Submitted --> [*]: Abandoned
Submitted --> First_Response: Respond within SLA
Submitted --> Breached: SLA deadline passed
First_Response --> In_Progress: Acknowledge
In_Progress --> [*]: Resolved
In_Progress --> Escalated: Cannot resolve
In_Progress --> Waiting: Awaiting customer info
Waiting --> In_Progress: Customer replied
Waiting --> Resolved: Timeout
Escalated --> Pending_Senior: Assigned to senior
Pending_Senior --> Resolved: Fixed
Pending_Senior --> Waiting: Needs more info
Breached --> [*]: Closed
Resolved --> [*]: Closed
Frequently asked questions
- What is an SLA state machine for support?
- It maps every state a support ticket moves through while tracking time against service-level agreements — response-time commitments and resolution windows. Each state represents a milestone: submitted (clock starts), first response (first SLA met or breached), in progress, waiting for customer, escalated, resolved. Visualization makes it clear which transitions mean you're on track and which mean you've hit an SLA breach.
- Why is SLA tracking important?
- SLAs are contracts with your customers about how fast you respond and fix issues. Without a state machine showing the flow, tickets drift between teams, response times are missed, and escalations get stuck. This diagram is the definition of 'done' — a resolved ticket is one that completed the full flow and met its SLA.
- What happens if we breach an SLA?
- The diagram shows 'Breached' as a transition: once the deadline passes, the ticket moves to a special state, often triggering alerts to management and escalation to a senior team. Some teams resolve breached tickets with priority; others track them for incident post-mortems. Customize the next step to match your process.
- How do I track the actual times — response time, resolution time?
- The diagram shows states and transitions; the actual timers live in your ticketing system (Jira, Zendesk, etc.). Each state transition is timestamped, and you compare those timestamps to your SLA windows (e.g., 'first response within 2 hours for P1'). Export this diagram to your team wiki so ticketing admins know which SLAs to configure.