Contact-Center Incident Severity Matrix

Part of the Planning Week chain · previous: Event, Incident and Problem in Contact Centers · next: Real-Time Cause and Effect Fishbone Contact-Center Incident Severity Matrix is the classification instrument a workforce function's standard fixes for incidents: six parameters whose structure is the standard's and whose values are set locally, the incident record's nine fields, and the one trigger the matrix hands to business continuity. It matters because severity decides who is told, how fast, and whether a post-mortem is required, and a function formed from several heritages usually arrives with two or three matrices whose rows do not map. This page is narrow by design: Event Management carries a four-tier illustration with values, and Incident Management for Contact Centers carries a five-row structure with every value marked set locally; this page carries the parameters both share, the reconciliation of their row counts, the record, and the wire. It produces the matrix and the incident record for the incident section of a standard (the §3.x pattern of Anatomy of a ROC Standard) and is worked in a session with CP-OPS-003 ROC Standard Authoring once that pack is live.

Six parameters, values set locally

A severity matrix has two halves that are commonly collapsed into one. The first half says what qualifies an incident for a row; the second says what the row commits the operation to. The standard fixes six parameters across the two halves and leaves every value to the node or estate, marked SET LOCALLY in the shell (Process Shells for a Workforce Standard).

#	Parameter	Half	What it asks	Typical form of the local value
1	Impact	qualifies	How far is service from target, on which objective? Service level is the primary signal; cost, customer experience and agent experience are read where the function's goal frame pairs them	a service-level threshold per row; the objective set named
2	Duration	qualifies	For how long has the deviation been sustained? A breach in one interval is a variance; a breach across consecutive intervals is an incident	a count of consecutive intervals; three is a common value and is Asserted
3	Scope	qualifies	How much of the operation is affected: one queue, one book, one node, one channel, or the estate	the unit of scope per row
4	Customer visibility	qualifies	Can customers see it: a queue they wait in, a channel that is down, a message they hear?	yes or no per row, with the channel
5	Recoverability	qualifies	Can the operation restore service inside the interval with its own levers, inside the hour with escalation, or not without an outside party?	the lever class per row
6	Notification	commits	Who is told, how soon after detection, how often until closure, and who is told at closure; the notification footprint	the initial window, the update cadence, the notified organizations and the notified leadership tier per row

The four-tier illustration on Event Management collapses impact and duration into a single service-level signal, which is the collapse this split undoes. Two things the matrix does not carry. It does not carry the fix-agent resolution target as a parameter, because a target is a service-level commitment on the responding party rather than a property of the incident; the standard records it on the row as a commitment where a function wants one, and Incident Management for Contact Centers shows the column. And it does not carry the staffing state: the escalation codes that classify what the operation has become are a separate instrument from the severity that classifies what happened to it, as that page explains, and merging them loses the ability to represent a severe incident under control.

Impact and recoverability as the two axes that decide priority is the convention this matrix descends from: service management requires incidents to be prioritized, and the incident-handling literature scores recoverability alongside functional impact as the inputs to that priority.

The row count is local

This wiki carries two illustrations with different row counts: four tiers on Event Management and five rows on Incident Management for Contact Centers. Neither is wrong, and a function adopting the standard should not spend a sitting choosing between them. The standard fixes the parameters, not the rows; a function keeps the row count its estate can act on, with two constraints. The top row is a total or near-total loss of service and the bottom row is a deviation the desk absorbs without a ticket, so that the matrix has a floor as well as a ceiling. And every heritage's matrix maps onto the adopted one row by row, with the mapping written into the standard's temporarily accommodated variations with an expiry date, so that an incident rated on the old matrix can be counted on the new one.

The reconciliation matters most for two rows: the row that triggers a required post-mortem and the rows that trigger the continuity wire. Both are defined by the standard's rows, and both must be stated in the mapping so that a heritage's "severity 2" is not silently promoted or demoted when the matrices merge.

The incident record: nine fields

The incident page carries the eight lifecycle facts recorded at closure: start, detected, engaged, customer impact, probable cause, mitigation, diagnosed, repaired. The standard's record adds one field in front of them, the timestamp and its zone, because a function spanning nodes in several time zones cannot compare incidents whose times are read in the local zone of whoever wrote the record. The nine fields are one list used three ways: the notification body, the closure record and the post-mortem agenda. A record that carries them all is comparable across nodes and across heritages; one that carries seven is not, and the missing field is the one that turns out to matter.

The same list is the process's instrument panel: Incident Management for Contact Centers reads the three gaps between the facts as measures of the monitoring net, the escalation machinery and the fix capability, and this page does not restate the reading. What the standard adds is comparison across nodes, which is what the ninth field makes possible: a node whose gaps are consistently longer on one segment has a finding before any post-mortem is called.

The continuity wire's trigger

The continuity wire is the standing interface between the incident process and the continuity owner: a trigger and a product, specified as an interface on Enterprise Interconnection Plan. The matrix fixes the trigger. An incident rated at the top two rows, severity 1 and 2, sends its record to the continuity owner at the moment its severity is set, as one of the notified organizations in parameter 6; the record is the product. Nothing else is required of the incident process, and the continuity owner decides whether the plan activates. The wire is carried at step 5 of the incident process on the existing notification row, not as a new step, so the twelve-step L1 is unchanged; Business Continuity Planning for Contact Centers carries what happens on the other side of the wire, including the named activation role. The convention that continuity is invoked by a defined trigger and a named role rather than by judgment in the moment is the business-continuity standard's own.

Whether the wire also carries authority to move work across nodes is a decision the chain leaves to the room (D-10 on Planning Week for a Workforce Function); this page fixes only the trigger and the product.

Worked example

On Wed 8 Apr 2026 the real-time team's detector proposed severity 2 for incident IN-001 from the function's matrix, and the issuer set it at 09:21 (Real-Time Agents). Read against the six parameters: impact, voice service level below target from 09:15 [M]; duration, the criterion's threshold met at 09:20 on the detector's sustained-decline pattern rather than on an interval count [M], the function's set-locally value being one full interval or a sustained within-interval decline, the function's own value and not the common one; scope, one book, one channel; customer visibility, yes, a queue customers waited in; recoverability, inside the hour with the operation's own lever, a break shift for nine agents; notification, the book's node owner and the real-time analyst at 09:21, the continuity owner at 09:21 as a notified organization because the row is severity 2. The continuity owner received the record as the wire's product and did not activate, because recoverability was inside the hour; the receipt is on the record. The record's nine fields at closure: zone and timestamp, 09:15 in the book's zone; start 09:15; detected 09:20; engaged 09:21; customer impact, voice service level below target from 09:15 to 09:50, spanning three intervals [C]; probable cause, arm 1, a staffing gap; mitigation, R-044, approved 09:24; diagnosed 09:21; repaired 09:50. Detected minus start, five minutes; engaged minus detected, one minute; repaired minus engaged, twenty-nine minutes [C]. Severity 2 did not meet the required post-mortem condition; the discretionary review that afternoon is on Post-Mortem and RCA for Workforce Operations.

The function's heritage matrices, one with four tiers and one with five, were mapped onto the adopted five-row matrix on Day 2 afternoon of its planning week (Tue 21 Apr 2026) and listed as a temporarily accommodated variation expiring Wed 30 Sep 2026, by which date every open incident record carries the adopted row.

The artifact this page produces

The severity matrix, one row per severity, and the incident record, one per incident, both for the incident section of a function's standard (the §3.x pattern of Anatomy of a ROC Standard) and recorded against L0 card P-008 (T4). One filled example row of the matrix:

Row	Impact	Duration	Scope	Customer visibility	Recoverability	Notification (initial · cadence · organizations · leadership)	Required post-mortem	Continuity wire
Severity 2	service level below target on the primary channel [SET LOCALLY: threshold]	sustained [SET LOCALLY: consecutive intervals]	one book or one node	yes	inside the hour with the operation's levers	[SET LOCALLY] · [SET LOCALLY] · node owner, real-time, continuity owner · [SET LOCALLY]	no (discretionary on request or recurrence)	yes: the record at severity set

Produced in a working session with CP-OPS-003 ROC Standard Authoring (the pack link is added when the pack is live); the filled set is part of blueprint v0.1.

What would change this

The page's central claim is that fixing six parameters and leaving the row count local produces incident records comparable across nodes and heritages. The observation that would overturn it is a function whose incident log, after a full cycle on the adopted matrix, still could not be compared across two nodes because the local values on the same parameter diverged so far that "severity 2" meant different things in practice; that would argue for fixing the values as well as the parameters, at the cost of a matrix no estate could act on uniformly, and the page would have to say which parameters must carry a fixed value.

How this connects

• Previous in the chain: Event, Incident and Problem in Contact Centers — what an incident is before it is rated
• Next in the chain: Real-Time Cause and Effect Fishbone — how the rated incident is diagnosed
• Defers to: Event Management (the four-tier illustration with values and the notification footprint) · Incident Management for Contact Centers (the five-row structure, the escalation codes kept separate, the eight lifecycle facts) · Real Time Threshold Alerts and Escalation Protocols (the alert classes that trip the entry criterion) · Business Continuity Planning for Contact Centers (the other side of the wire) · Enterprise Interconnection Plan (the wire as an interface with an owner on each side)

Maturity Model Position

A matrix with fixed parameters and one record is Level 2 work, the discipline Event Management places at its foundational level. Reading the record's gaps as an instrument panel across nodes, and letting the real-time agent team propose a severity from the matrix for a person to set, is Level 3 practice. Four scales on this wiki use the word level; the launch page states which is which.

See Also

• Planning Week for a Workforce Function
• Event Management
• Incident Management for Contact Centers
• Event, Incident and Problem in Contact Centers
• Post-Mortem and RCA for Workforce Operations
• Real Time Threshold Alerts and Escalation Protocols
• Business Continuity Planning for Contact Centers
• Enterprise Interconnection Plan