An escalation procedure defines when an issue needs additional expertise or authority, who should receive it, and how ownership and communication continue. Use the copyable procedure, matrix, and handoff form below to build a process for your support team.
Replace every placeholder with your own approved roles, coverage, and service targets. The examples are illustrative; their timing and authority are not universal standards or promises to customers.
Validate the matrix with a coverage exercise
A completed escalation matrix needs a rehearsal. Use a fictional case, identify the intended receiving role, and ask what happens if that person is unavailable. The exercise should end with an accepted owner and a customer-update plan, not just a contact name.
Matrix exercise Case and escalation trigger: [...] Receiving role during normal coverage: [...] Backup if unavailable: [...] How the receiver accepts the handoff: [...] What evidence is required: [...] Who updates the customer: [...] What happens outside coverage: [...] Observed gap / matrix change / approver: [...]
A matrix identifies routing and authority; the escalation process explains how to perform and verify the handoff. Keep team-defined acknowledgment and resolution targets separate. If the exercise exposes an unowned case, repair the procedure before presenting its targets as reliable.
Copyable escalation procedure template
Procedure name: Service / team covered: Owner and approver: Version / effective date / next review: Coverage hours and time zone: 1. Intake Create or locate the issue record in [system]. Record the symptom, affected task, impact, scope, and customer contact. Assign initial ownership to [role / queue]. 2. Escalation triggers Escalate when [defined impact or urgency condition] applies, when [expertise or approval] is required, or when [acknowledgment / progress threshold] is reached. Route [incident or security category] through [approved separate process]. 3. Contact and fallback Notify [primary role] through [channel]. Include the handoff form below and the issue link. If no acknowledgment by [target], contact [backup role / channel]. Outside coverage hours, use [approved route and customer message]. 4. Ownership Current owner retains responsibility until [receiving role] accepts. Record acceptance, timestamp, next action, and next update time. Name [role] to coordinate customer communication. 5. Updates and resolution Send updates through [channel] at [cadence / agreed next update]. Record decisions, tests, workarounds, and remaining uncertainty. Verify [customer task / recovery criteria] before closure. 6. Review Document follow-up actions, owners, and due dates. Review the procedure after [trigger] and at [scheduled interval].
Keep the procedure where agents handle issues. A document that requires someone to search old messages for the backup contact will be difficult to use under pressure.
Escalation matrix format
The procedure explains the process. A matrix makes routing decisions easy to look up. You can copy this format into a document or spreadsheet and add a row for each issue category.
| Issue or trigger | Receiving role | Primary channel | Acknowledgment target | Fallback | Update owner |
|---|---|---|---|---|---|
| [Category and measurable trigger] | [Role with expertise or authority] | [Approved contact route] | [Target and clock definition] | [Backup role, route, and trigger] | [Role responsible for updates] |
| [Second category and trigger] | [Receiving role] | [Contact route] | [Target] | [Backup route] | [Update owner] |
Link to your maintained contact directory or on-call schedule instead of duplicating personal contact details in many versions. Specify whether a target uses elapsed time or business hours, the relevant time zone, and when its clock starts.
Sample support escalation matrix
This sample uses role names and placeholders. It shows how to distinguish expertise, authority, and incident response without imposing arbitrary one-hour or four-hour targets.
| Situation | Route | Handoff needs | If the receiver is unavailable |
|---|---|---|---|
| A reproducible product failure needs investigation. | Product specialist or engineering triage. | Steps, environment, expected/actual result, scope, and evidence. | Use the documented backup queue and retain support ownership until accepted. |
| A customer requests an exception beyond agent authority. | Support lead or designated approver. | Requested decision, relevant policy, customer context, and options already offered. | Use the named alternate approver; communicate the next update time. |
| Reports suggest a wider service disruption. | Approved incident-response route. | Observed symptoms, timestamps, affected service, and known scope. | Follow the incident plan’s fallback contact route. |
| A case has reached the team’s defined progress threshold. | Queue owner or support lead. | Timeline, blockers, completed checks, and specific assistance required. | Use the queue’s backup owner and keep the case visible. |
Adapt these rows to your structure. A small team may use two roles; a larger organization may have specialist queues. Extra levels are useful only when they clarify responsibility or decisions.
One case can use several rows at once: a specialist investigates a defect while a supervisor decides on an exception. These are complementary responsibilities, not stages every issue must pass through, so give each one a named owner. For the full flow of a single case, see the support ticket escalation process.
Copyable escalation handoff form
Issue / ticket link: Escalating owner and contact: Requested receiving team / role: Reason for escalation and requested action: Customer task or service affected: Observed impact and known scope: Time first observed and relevant timestamps: Steps / evidence / environment: Checks completed and their results: Workaround and whether it was verified: Current blocker: Current customer message: Next customer update due: Receiving owner acceptance and time: Next action and owner:
Write a specific request, such as “review whether this export failure affects other workspaces,” instead of forwarding a conversation with “please help.” A structured bug report or concise screen recording can make a technical handoff easier to understand.
Separate observed facts from possible causes. Link evidence instead of pasting a long conversation, remove secrets and unrelated personal information, and confirm that the receiving team can open what you linked.
For a short chat or paging message, AHRQ’s SBAR structure (Situation, Background, Assessment, and Recommendation or Request) keeps the decision needed near the top. It structures the message only; it does not create a receiving team, an approval limit, or a fallback.
Choose triggers the team can recognize
- Expertise: the issue requires knowledge or access the current owner does not have.
- Authority: a decision exceeds the owner’s approved responsibility.
- Impact: observed scope or disruption meets your incident criteria.
- Time: an agreed acknowledgment, progress, or service threshold has been reached.
- Repeated failure: documented attempts have not resolved the problem and the next check needs another team.
Expertise and authority call for different routes. Atlassian’s escalation guidance distinguishes functional escalation, which reaches specialist expertise, from hierarchical escalation, which reaches additional authority. Route to the role that removes the block instead of making every case climb through each level.
Describe what evidence satisfies each trigger. Avoid making escalation depend on an agent guessing that a customer is “important enough.” Use your organization’s approved incident and security routes where those apply.
For impact, separate severity (how serious the effect is) from urgency (how soon help is needed), and classify from observed facts rather than the customer’s tone. An elapsed-time trigger can request more attention without proving greater impact.
For a separate incident-oriented reference, Atlassian’s escalation path guide covers criteria, levels, communication, and follow-up. Keep incident response and ordinary support handoffs connected but distinguish their triggers and responsibilities.
Separate acknowledgment from resolution
An acknowledgment target tells the sender when a receiving team should accept or respond to a handoff. A resolution target concerns the outcome. A customer-update commitment says when someone will communicate again. Put these in separate fields so one is not mistaken for another.
Give each clock a start event, stop event, and calendar. “Respond within one hour” could mean replying to the customer, accepting an escalation, starting investigation, or restoring service. Do not reset a customer’s wait because an internal receiver changes.
| Clock | Start and stop | What the procedure must state |
|---|---|---|
| Escalation acceptance | Request sent → named receiver accepts responsibility | Coverage hours, target, and no-acceptance fallback |
| Customer or stakeholder update | Last qualifying update → next required update | Audience, channel, owner, and next due timestamp |
| Resolution or restoration | Defined service-policy event → defined verified result | Applicable agreement, status rules, and completion criteria |
| Decision deadline | Request recorded → required decision recorded | Deadline rationale and what happens if the decision is late |
A notification, forwarded email, or queue assignment is not acceptance. Require an entry with a named receiver and their next action. Alerting tools draw the same line: PagerDuty documents that acknowledgment stops its escalation policy, but it does not resolve the incident.
Agree targets with the people who must meet them. Check availability, workload, service commitments, and fallback coverage. A fast target written into a template does not create staffing or guarantee recovery.
Keep restoration and permanent correction distinct. A verified workaround can let the customer resume work while investigation continues; record its limits and give the remaining work its own owner.
Example: a business-hours acceptance target
In this fictional example, a team covers Monday to Friday, 09:00–17:00 UTC, with a two-business-hour target for specialist acceptance. A request sent at 15:30 on a working day uses 90 minutes before the close; the remaining 30 minutes run to 09:30 on the next working day, skipping weekends and configured holidays.
That is an internal acceptance clock, not permission for the issue to wait. If an urgent or outside-hours condition already applies, the agent follows that route instead. If nobody has accepted by 09:30, the agent contacts the backup and keeps tracking the request.
Customer update template
We are reviewing [specific issue / affected task]. We have confirmed [known facts] and are still checking [uncertainty]. [Team / role] is handling [next action]. [Verified workaround, if appropriate.] We will update you by [time and time zone], even if the investigation continues. You can reply to this case with [specific useful information].
Use a real update commitment your team can keep. Do not invent a cause, scope, or fix time to fill the template.
Test and maintain the procedure
- Walk through one routine specialist handoff and one urgent scenario.
- Test the primary contact, absent receiver, and outside-hours path.
- Add three changes: an exception that needs approval while investigation continues, impact that grows beyond the initial scope, and a case that crosses a shift change.
- Check that someone remains responsible until the handoff is accepted.
- Confirm that the receiving team can access the record and evidence.
- Practice sending an update when there is no new resolution.
- Record unclear steps, assign improvements, and publish the approved version.
Ask participants to explain each transition; if they disagree about whether an assignment means acceptance, revise the wording.
Before launch, agree triggers, evidence, coverage, and targets with the receiving teams, then pilot on one request type with an owner and review date. If agents fear that asking for help will be treated as failure, the written trigger may never be used.
Review after contact or role changes, a missed handoff, or a significant incident. Track acknowledgment delays, rejected or rerouted handoffs, missing evidence, overdue customer updates, reopened cases, and repeated requests for information. Read representative cases alongside the numbers; reducing escalation count alone does not prove better support.
If you report an escalation rate, define the denominator and count unique cases: 150 escalated out of 1,000 eligible cases is 15%, a calculation rather than a benchmark. A low rate can hide cases that needed help, so avoid ranking agents by escalation volume alone.
For the investigation itself, use our technical troubleshooting checklist. Screendesk’s Zendesk recording workflow can support visual evidence when a customer issue is difficult to explain in text.
Frequently asked questions
What is the difference between an escalation procedure and a matrix?
The procedure describes how escalation works, including ownership and updates. The matrix summarizes which route to use for a particular trigger. Keep their roles, contacts, and timing consistent.
Does escalation always mean contacting a manager?
No. An issue may need a specialist’s expertise, an approver’s authority, or an incident-response team. Route it to the responsibility required for the next action.
Who owns an issue after it is escalated?
Define this explicitly. The template above retains current ownership until a receiving owner accepts, while separately naming who communicates with the customer.
Does escalation guarantee a faster resolution?
No. It provides a defined route to additional capability or authority. Resolution still depends on the problem and the resources available, so measure routing and acceptance separately from the eventual result.
Can I use this template in Excel or Google Sheets?
Yes. Use one matrix row per issue category and add columns for your local targets and coverage. Keep the detailed procedure and handoff form linked from the sheet.
