Escalation Matrix Template For A Small IT Team

An escalation matrix is a table that says, for each ticket type, what triggers a handoff, who owns it, who backs them up, and how long each has. It also sets the handoff note, the after-hours path, and who calls the vendor.

The template below comes from the team behind SherpaDesk, a helpdesk and professional services automation (PSA) tool a small IT team can run alone.

Key takeaways

• Write one row per ticket type. Trigger, owner, backup, and work budget. Get The Template
• Separate skill from authority. Hand the ticket to whoever can fix it; inform whoever must decide. Two Types
• Split the clocks. Put an accept time inside each work budget, and fit budgets to the target. See The Example
• Give after hours and vendors their own fields. That's where small teams lose tickets. After Hours And Vendors

What Is An Escalation Matrix?

Ontario's ITIL-based incident standard defines escalation as an activity that gets more resources when they're needed to meet service level targets or customer expectations.

The same standard names two types, and a usable matrix keeps them in separate columns.

Why A Small Team Needs One

Without a written matrix, the escalation process lives in someone's head. Tickets sit too long with the first person or move up with nothing attached.

Ontario's standard says clear triggers and thresholds must be defined for both functional and hierarchical escalation.

In one r/msp thread about L1 techs who escalate everything, a reply set the rule: "an unresponsive end user should never be justification for an escalation."

On a team of one to five, your "tiers" are people, and one is always out or asleep. Without a backup on every row, the ticket waits.

The Escalation Matrix Template

One block per ticket type, a handoff note, a contact list, and three checks. Brackets mark what you fill in. Our helpdesk SOP templates include the escalation procedure itself; this matrix is the lookup that procedure points to.

ESCALATION MATRIX TEMPLATE
For a support team of 1 to 5 people
Team: [MSP, IT department, or school]
Matrix owner: [role]
Last reviewed: [date] · Next review: [date]
Business hours: [days, hours, time zone]
Holidays: [named calendar]

ONE ROW PER TICKET TYPE (copy the block)
Row [n]: [ticket type or class]
  Priority: [P1 to P4 by impact; one type can carry
    several, so copy the row per impact]
  Trigger: [no progress, missing skill or access,
    impact grows, or the user asks for a manager]
  Clock: starts at [ticket logged]; target is to
    [restore or resolve] within [time]
  Owner: [role or name who takes it first]
  Accept within: [minutes, or it goes to the backup]
  Work budget: [time with the owner before escalating,
    acceptance included; business or clock hours]
  Backup: [a different person; solo: an agreed
    outside specialist or MSP]
  Escalate to: [role] (functional: skill or access)
  Inform: [manager or client contact who must hear]
    (hierarchical: a decision, money, a complaint)
  After hours: [yes or no; which priorities wake
    someone, and how they are reached]
  Vendor: [name, support line or portal, contract
    or account ID, who opens the case]

HANDOFF NOTE (with every escalation; on a P1, call
  first and write it during the call)
  1. What the user reported, in their words
  2. Impact: who is stopped, and since when
  3. Each fix attempted and its result
  4. Evidence: error messages, log lines, screen captures
  5. Why it moves now (the trigger from the row)
  6. What the user was told, and when they hear next
  The sender keeps the ticket until the next owner
    accepts it.

CONTACTS (one list, linked from every row)
  [role]: [phone], [email]
  After-hours line: [number], rings [on-call role],
    fails over to [role] after [minutes]
  Vendor [name]: [support line or portal], [ID]

CHECKS
  Every row has a backup who is a different person.
  Work budgets in a row fit inside the priority target.
  Solo: name a decision-maker and, with no cover, an
    agreed maintenance window.
  Test each row with one made-up ticket per quarter.

How To Fill In Each Field

Fill the matrix in this order.

1. List your ticket types

   Start from the classes you already use at intake, and add one row per type that ever needs a handoff. Our ticket triage guide covers how to set up the classes.

   Common mistake: one row per priority instead of per type. An outage and a security report need different owners, whatever their priority.

2. Write the trigger

   Pick from four: no progress, a missing skill or access, growing impact, or a user who asks for a manager. The priority column comes from your ticket priority levels, so you don't define them twice.

3. Name the owner and the backup

   Use a role or a name, not a team. The owner must accept within a set time, or the backup takes it. Until the next person accepts, the current owner keeps the ticket. Ontario's standard has a similar rule for major incidents: service owners name delegates, and the desk calls the delegate when the owner can't be reached.

4. Set the clock and the work budget

   Under Ontario's standard, each tier may get a set amount of time; after that, the incident must move to a more specialized group. Each tier's time is set so service is restored within the SLA target. Write when the clock starts and whether the target means restored or resolved, then work backward.

5. Split escalate from inform

   "Escalate to" is functional: the ticket changes hands. "Inform" is hierarchical: someone with authority hears about it and may decide something. For an MSP, add the client contact who must hear.

6. Require the handoff note

   When the notes show no real troubleshooting, send the ticket back to its owner.

   Common mistake: letting the note replace a phone call on a P1. Call first, and write the note during the call.

Filled-In Example For A Small MSP

Say you run a three-person MSP: the owner, a senior technician, and a junior technician. Business hours are 8 a.m. to 5 p.m. on weekdays; only P1 tickets and security reports wake someone up. Priorities follow our published grid, and each row is one impact.

Internal targets, inside our published SOP set: P1 restored within 2 hours, P2 within 4 business hours. P3 resolved within 2 business days; P4, where nobody's work is affected, answered within 1 business day and settled within 5. Acceptance counts inside each work budget. Row 3 is filled in full below the table.

Every backup differs from the owner, the P2 budgets add up to the 4-hour target, and both urgent rows pass to a named person after 5 minutes.

Solo IT. With one person, the backup is an agreed outside specialist or MSP, and the vendor field names a support route. Name a separate person who makes business decisions. If nobody can cover, agree a maintenance window when tickets wait.

After-Hours And Vendor Escalation

After hours. Decide which priorities wake someone, and write it in the row. Ontario's standard accepts that a P2 assigned to a tier 2 or higher group outside regular business hours may wait until the next business day.

Then write where the call goes when nobody answers. One r/msp member who pays a weekly on-call stipend wrote: "If the on call techs don't respond then it fails over to someone on our escalations team as backup."

Vendors. A vendor case doesn't take the ticket off your team: you manage the vendor relationship and stay the user's point of contact, a TechTarget guide to support tiers says.

Open the vendor case early. Ontario puts third-party support on standby once a major incident is declared, based on the vendor's contracted response times and record of meeting them. One MSP reported almost a week with Microsoft partner support to get halfway through one tenant's MFA reset.

Where Support Tiers Fit

Tiers 0 to 3, and the vendor tier some teams add, are defined in our helpdesk vs service desk guide. One person can hold two tiers, so this escalation matrix uses roles and names.

Run The Matrix In SherpaDesk

How this works in SherpaDesk

Levels, routing, and SLA goals

You can move tickets through a tiered support process with Levels & Escalations. Routing rules send tickets of selected classes to a specific technician. Priorities carry SLA response and completion goals, and you define your business hours and holidays.

Time-based notification rules can target the assigned and the alternate tech on a ticket. You can run it for your own staff or for the businesses you support.

A helpdesk and PSA a small IT team can run alone. No contract. No implementation project. No dedicated admin.

Base Camp is $45 per agent per month ($40 billed annually). The first agent is free, forever, so a team of three pays $90 a month ($80 billed annually). The trial is 14 days free with no card.

See SherpaDesk Pricing →

Frequently Asked Questions

What are the types of escalation?

What does escalation level mean?

What is an escalation email?

How many escalation levels does a small team need?

How often should you review an escalation matrix?