What is an escalation matrix?

An escalation matrix is a structured table that defines who handles which type of issue, at what severity, and within what response window. It removes the guesswork from incident response by making ownership and timing explicit, so support reps do not have to invent a path the first time something serious happens.

What should an escalation matrix include?

A useful escalation matrix has four columns: severity level, type of issue, owner at each tier, and response time target. Anything beyond that is decoration. The goal is a single page that someone new to the team can read and act on without follow-up questions.

How many escalation tiers should a support team have?

Three tiers is the right starting point for most teams. Tier 1 handles the inbound queue and resolves standard issues. Tier 2 handles complex or repeat issues that need product knowledge. Tier 3 escalates to engineering when a code change is needed. More tiers add ambiguity faster than they add value.

How does an escalation matrix work with an issue tracker?

The matrix tells the team when and how to escalate. The issue tracker is where the escalated work lives. For teams running HubSpot Service Hub and Linear, a tool like IssueLinker turns the escalation from support to engineering into a synced ticket-to-issue pair, so the matrix produces tracked work instead of a Slack thread.

The Escalation Matrix Support Teams Actually Use

Every support team eventually writes an escalation matrix. The first version is usually a wiki page with seven severity levels, four owners per level, and a flowchart that takes ten minutes to follow. Nobody uses it. The second version is the one written after the first real outage, when leadership notices that nobody knew who to call. That version is shorter, it works, and it is what this guide gets to up front.

The goal here is a one-page escalation matrix you can copy today, the reasoning behind why each piece is on it, and how to keep the matrix alive after the first month so it does not turn into another wiki page nobody reads.

In this article

What an Escalation Matrix Actually Does

An escalation matrix has one job. When something goes wrong, it answers "who handles this, by when, and what happens if they cannot" in under a minute. That is it. Every other goal people attach to escalation matrices, like cross-team awareness, compliance documentation, or training material, is downstream of getting that core answer right.

The reason this matters is that escalation decisions get made in the worst possible conditions. A customer is angry. A rep is twenty minutes into a shift. Three other tickets are open. The wrong question to ask in that moment is "what is our policy on this?" The right question is "what does the table say?" If the table is short and the answer is obvious, the team escalates correctly. If the table is long or the answer requires interpretation, the team escalates badly, late, or not at all.

Almost every escalation matrix problem comes from forgetting that the table is read under stress, not in a planning meeting. The remedy is brutal trimming.

The Four-Column Escalation Matrix

Here is the shape that works for most support teams. Four columns. Three tiers. Concrete severity criteria. Copy it as a wiki page, a Notion table, a HubSpot ticket property dropdown, or a printed sheet on the support team's wall. The structure stays the same.

| Severity | Issue Type | Owner | Response Time | | --- | --- | --- | --- | | Critical | Production down, data loss, security incident | On-call engineer, immediate page | 15 minutes | | High | Customer-facing feature broken, no workaround | Tier 3 engineering escalation | 1 business hour | | Medium | Feature working with noticeable problem, workaround exists | Tier 2 support | 1 business day | | Low | Cosmetic, minor inconvenience, feature request | Tier 1 support | 3 business days |

That is the entire matrix. Four severities, four owners, four response times. Almost every support team converges on something close to this once they cut what does not work, and the teams that stay healthy stay close to it for a long time.

A few notes on why each column looks the way it does.

Severity over priority
Use one scale, not two. Teams that distinguish severity from priority spend half their triage time arguing about which is which. Severity is concrete: how broken is the thing? That is enough to drive the routing decision.
Issue type as plain language
"Production down, data loss, security incident" is the kind of phrasing a rep can match against a real ticket. "Sev 1 incident per the runbook" is not. Write the issue type in the words someone would use to describe what they are looking at.
Owner as a role, not a name
The matrix outlives any one person. Owner should be a role like "on-call engineer" or "tier 3 engineering escalation", and the role should map to a name somewhere else, like an on-call schedule or a team directory.
Response time, not resolution time
The matrix sets the time-to-first-response target. Time-to-resolution is a different metric and usually too variable to commit to in a matrix. The promise is that someone responds within the window, not that the issue is closed.

The Three-Tier Support Model

The matrix above assumes a three-tier support team, which is the structure most B2B support orgs end up with. The tiers are worth being concrete about, because matrix rows that reference tiers only work if the tiers themselves are well-defined.

Tier 1 is the inbound queue. Every new ticket lands here first. The tier 1 rep handles routine issues end to end: account questions, configuration help, known-issue lookups, and anything else the team has documented playbooks for. Tier 1 also handles initial triage on severity, which is the call that determines whether a ticket stays at tier 1 or moves up.

Tier 2 is the product depth layer. These reps have more product expertise, handle the issues that tier 1 cannot resolve, and own the relationship with high-value accounts. Tier 2 also owns the bridge to product management for feature requests, since they see the patterns first.

Tier 3 is the engineering escalation. Tier 3 is not usually a separate support team. It is the path from support into engineering for work that needs a code change. Tier 3 should be defined as a specific engineering contact or rotation, not "engineering" broadly, because "escalate to engineering" with no name attached is the most common reason escalations fail.

Writing Severity Criteria That Hold Up

Severity is the column most teams get wrong. The criteria sound clear in a planning meeting and dissolve into ambiguity when a real ticket comes in.

The fix is to write severity criteria as concrete, observable conditions, not as judgment calls. "Critical" is not "very bad." It is "production environment is unavailable, data has been lost or exposed, or a security incident is in progress." A rep should be able to look at a ticket and answer the severity question by checking conditions, not by guessing.

A working set of severity criteria for a SaaS support team looks something like this. Critical means the production service is down for one or more customers, customer data has been corrupted or exposed, or a security incident has been reported. High means a customer-facing feature is broken with no workaround for an impacted customer, or an outage is affecting a single tenant. Medium means a feature is degraded with a workaround available, or a bug affects a non-critical workflow. Low means cosmetic issues, minor edge cases, and feature requests dressed up as bugs.

Test the criteria by walking through ten recent tickets and asking which severity each one would have triggered under the proposed criteria. If different reps give different answers, the criteria are not concrete enough yet.

How to Roll the Matrix Out

A matrix that lives in a doc nobody opens does nothing. The rollout is the part most teams underinvest in.

1
Put the matrix where the work starts
The matrix needs to be one click from where the rep is filing the ticket. In HubSpot, that means a saved view of the matrix linked from every ticket form, or the severity field set up as a dropdown with the criteria visible inline. In a wiki, that means a bookmark on the support team's home page. Anywhere else, the matrix gets read once during onboarding and then ignored.
2
Walk every rep through three real examples
Pick three recent tickets across different severities and walk a new rep through how each one maps to the matrix. The examples teach the matrix better than the matrix teaches itself. The examples also surface ambiguous criteria before they cause a problem under stress.
3
Audit escalations every two weeks
For the first two months, read every escalated ticket and ask whether the severity assignment was right. The point is not to grade reps. The point is to find the rows of the matrix that are not landing and tighten them. Audits get rarer as the matrix stabilizes.
4
Update the matrix when the product changes
A new feature, a new tenant model, or a new compliance requirement can shift what counts as critical. The matrix is a living document. Pin a calendar reminder to review it every quarter.

What Happens After the Escalation

A matrix is only useful if the escalation it triggers produces tracked work. This is where most support teams quietly lose the thread.

The matrix says "escalate to tier 3 engineering." The rep does. Engineering acknowledges in Slack. Three days later, nobody is sure whether the bug was fixed. The customer who reported it has not heard back. The support ticket is technically still open. The escalation worked, in the sense that engineering knows about the issue, but the workflow around the escalation did not.

The fix is to make every tier 3 escalation produce a tracked engineering issue, with a two-way link back to the support ticket. The customer-facing record stays in the support tool. The engineering record stays in the issue tracker. The two stay in sync automatically. Status changes flow back to support. The customer hears about the fix the moment it ships.

For teams running HubSpot Service Hub and Linear, that is what IssueLinker handles. A tier 3 escalation in HubSpot becomes a Linear issue in one click, with the customer context attached. Status changes in Linear flow back to the HubSpot ticket. The escalation produces tracked work instead of a Slack thread. The full pattern is covered in the Linear HubSpot integration guide, and the bug tracking template guide covers the fields that should travel with the escalation.

The point is not that one tool is better than another. It is that the escalation matrix only works at scale if the tier 3 path produces real, trackable engineering work. A matrix that ends at "ping engineering on Slack" is a matrix that fails the moment ticket volume grows.

Make tier 3 escalations stick

If your escalation matrix sends bugs from HubSpot to engineering in Linear, IssueLinker turns the escalation into a synced ticket-to-issue pair. The customer hears about the fix the moment it ships, and nothing falls through the cracks.

Start Free Trial

Copy-Paste Escalation Matrix

For convenience, here is the matrix in plain text. Paste it into a wiki, a HubSpot ticket form, or a printed sheet.

SEVERITY    ISSUE TYPE                                        OWNER                              RESPONSE TIME
Critical    Production down, data loss, security incident     On-call engineer, immediate page   15 minutes
High        Customer-facing feature broken, no workaround     Tier 3 engineering escalation      1 business hour
Medium      Feature working with noticeable problem           Tier 2 support                     1 business day
Low         Cosmetic, minor inconvenience, feature request    Tier 1 support                     3 business days

Use it as the starting point, not the final answer. Trim rows you do not need. Tighten criteria your team is using inconsistently. The best escalation matrix is the shortest one your team will actually follow.