Escalation matrix with SLAs.

Who is notified, when, through which channel — and how fast they must respond. Not solving the issue. Just saying "I got it, I'm on it."

An escalation matrix defines who should be notified, when, and through which channel when something goes wrong or when a decision cannot be made at the current level. The SLAs (Service-Level Agreements) define how fast each level must respond — to confirm they've seen it and are taking ownership.

Without this, either issues stay buried at the operational level too long (POs afraid to escalate), or everything gets escalated to the CPO immediately (CPO drowning in noise).

The matrix works on two axes: what type of issue (rows) and what severity (columns). The intersection gives the escalation path.

01Severity levels

Level	Meaning	SLA — Acknowledge	SLA — Resolve
S1	Critical — production down, revenue-blocking, legal/security	15 min	4 h
S2	Major — significant impact on a segment or workflow	1 h	1 business day
S3	Standard — sprint-level issue, no immediate revenue impact	4 h	1 sprint
S4	Minor — cosmetic, low frequency, no blocker	1 business day	Next planning

02Issue types

Type 1 — Production incident (bug in production, outage, data issue)
Type 2 — Cross-team dependency blocked
Type 3 — Scope or priority disagreement
Type 4 — Stakeholder request (from Sales, Marketing, CS, C-level)
Type 5 — People issue (conflict, burnout, misconduct, attrition risk)
Type 6 — Release / go-no-go decision

03Escalation matrix

Issue type	S1	S2	S3	S4
Production incident	CPO + CTO (Slack #incidents)	Product Director + Tech Lead	PO + dev squad	PO
Cross-team dependency blocked	CPO + counterpart C-level	Product Director	PO ↔ counterpart Lead	PO
Scope / priority disagreement	CPO	Product Director	PO + Lead Dev	PO
Stakeholder request	CPO	Product Director	PO	PO (logged, weekly review)
People issue	CPO + People	Product Director + People	Direct manager	Direct manager
Release / go-no-go	CPO + CTO + CEO	CPO + CTO	Product Director + Tech Lead	PO + Lead Dev

04Communication channels by severity

Severity	Primary channel	Backup
S1	Phone call + dedicated Slack channel	SMS
S2	Slack DM with @here	Email
S3	Jira ticket with escalation label + Slack mention	—
S4	Jira ticket, weekly review	—

05Escalation rules

Always escalate up, never across. A PO does not escalate directly to the CTO. The PO escalates to the Product Director, who escalates to the CPO, who coordinates with the CTO. Skipping levels creates confusion and undermines trust.
Escalation is not failure. Escalating is a sign of maturity, not incompetence. Escalating too late causes more damage than escalating too early.
The escalation comes with a recommendation. Include: what happened, what you've already tried, what you recommend, and what you need from the person you're escalating to.
Acknowledge ≠ resolve. The SLA to acknowledge means "I've seen your message and I'm on it." The SLA to resolve means "we have a decision or a fix."
One owner per escalation. When something is escalated, the person who receives it explicitly accepts ownership (or delegates it to someone specific).
Written trail. Every S1–S2 escalation must be logged: what, when, who was involved, what was decided, what was the outcome. This feeds into the post-mortem process.
Auto-escalation. If the SLA to acknowledge is breached, the issue automatically escalates to the next level via tooling (Jira automation, Slack bot…).

06How to implement this

Publish the matrix in Confluence as a single reference page — and put it on the wall. Each cell gives who handles it, who it escalates to, the SLA (acknowledge + resolve), and the channel to use.
Add escalation status to Jira: create labels escalation-S1, escalation-S2, etc. Set up Jira automation to notify the right people when these labels are applied.
Review monthly: in the CPO's management meeting, review all S1 and S2 escalations from the past month. Look for patterns — same team? Same dependency? Same type?
Include in onboarding: every new PM should know exactly who to call and when.

← Back to the process