When Does a Ticket Escalate Between L1, L2, and L3?
Escalation between tiers is governed by clearly defined criteria. Priority drives urgency, but the technical criteria below determine when a ticket moves to the next support level.
| Escalation Path |
Triggers and Criteria |
| L1 → L2 |
SOP or KB-based resolution does not apply; issue is recurring; log or configuration analysis is required; required access is outside L1 permissions; issue cannot be resolved within L1 scope or SLA. |
| L2 → L3 |
Code defect suspected; formal RCA required; architecture-level issue; product or vendor dependency; permanent fix needed; complex automation failure or database-level issue. |
- Priority-based escalation is enforced — P1 and P2 tickets bypass queues and trigger immediate next-level engagement.
- SLA response ownership remains clear at every level; the ticket owner does not change unless explicitly handed over.
- Client communication continues throughout escalation — clients never have to ask for status.
SLA Targets and Response Times for P1, P2, P3, and P4 Incidents
The table below provides indicative SLA targets used in most HEX64 engagements. Actual response and resolution targets are defined in your signed service agreement and adjusted for region, support hours, and business impact.
| Priority |
Example Incident |
Initial Response |
Target Resolution |
| P1 – Critical |
Complete service outage or business-critical failure |
5 – 30 minutes |
4 – 8 hours |
| P2 – High |
Major business impact; significant degradation |
30 minute |
1 business day |
| P3 – Medium |
Partial impact; workaround available |
2 hours |
2 – 3 business days |
| P4 – Low |
General service request or minor issue |
4 hour |
3 – 5 business days |
Note: Actual SLA timelines vary based on contractual agreements, regional support windows, and business impact.
L1 vs L2 vs L3 Support — What’s the Difference?
The matrix below shows how scope, skill, access, and authority differ across the three IT support tiers.
| Area |
L1 Support |
L2 Support |
L3 Support |
| Skill level |
Foundational / generalist |
Intermediate / specialist |
Senior / expert / engineering |
| Troubleshooting scope |
Standard, SOP-driven |
Operational, multi-system |
Architecture, code, product-level |
| Documentation dependency |
High — SOPs and KB articles |
Moderate — guided by logs and analysis |
Low — defines new fixes and documentation |
| Access level |
Limited / read-only or basic |
Elevated, role-based |
Privileged / engineering-grade |
| Resolution ownership |
Routine and known-error tickets |
Operational incidents and workarounds |
Permanent fixes and root-cause closure |
| Escalation authority |
Escalates to L2 |
Escalates to L3 / vendor |
Owns final resolution; engages vendor or product team |
| Complexity handled |
Low |
Medium |
High and critical |
| Fix type |
Basic fix |
Workaround / temporary fix |
Permanent fix |
Escalation Handover Requirements
Every escalation between L1, L2, and L3 includes complete troubleshooting notes and findings from the previous tier. A handover without context forces the next level to repeat checks already performed — delaying resolution and inflating impact.
Mandatory Handover Details
- Issue summary in clear, factual language
- Business or user impact, including affected users, systems, or services
- Priority and severity assigned, with justification if changed
- Steps already performed and their outcomes
- Error messages, log excerpts, screenshots, and supporting evidence
- Findings to date and suspected cause
- Current ticket status at the point of handover
- Recommended next action for the receiving level
Important: Escalations are not sent with generic notes such as “please check.” Every handover contains sufficient context for the next level to continue without repeating the same checks.
End-to-End Ticket Workflow
The standard lifecycle of a ticket through the HEX64 tiered IT support hierarchy:
| Client / User |
L1 Support |
L2 Support |
L3 Support |
Resolution Validation |
Client Confirmation |
Ticket Closure |
- L1 performs initial response, classification, and basic resolution.
- L2 performs advanced operational troubleshooting and applies workarounds.
- L3 performs engineering or product-level resolution and permanent fixes.
- Closure happens only after validation and client confirmation, or per the agreed closure policy.
Ticket Closure and Root Cause Analysis (RCA)
- Resolution is validated before the ticket is moved to a closed state.
- Ticket notes, root cause, and final action are updated in the ticketing system.
- Client or user confirmation is captured where applicable.
- RCA is generally required for P1 and P2 incidents, repeated incidents, and major business-impacting issues.
- SOPs and KB articles are updated whenever a recurring issue or a new fix is identified.