Incident Management for Contact Centers
Incident Management for Contact Centers is the real-time process by which a contact-center operation detects, tickets, diagnoses, mitigates, and closes events that push service levels away from target, and then learns from them through post-mortem and root-cause follow-up. It is the operational sibling of Event Management. An event is a known activity likely to impact service levels, managed in advance through forecasting, scheduling, and a collision calendar. An incident is a planned event or unplanned occurrence actively degrading service levels, where the goal shifts to restoration. A problem is the underlying root cause. The three-way separation is inherited from IT service management.[1]
This page presents a generic twelve-step incident process, drawn from production use in a Resource Optimization Center (ROC) and documented as the worked example of the Process Decomposition (L0–L3) standard. Its Level 0 statement of scope: define the process for managing incidents in order to return service levels to normal — ticket, diagnose, act, monitor, and communicate through resolution, post-mortem, and root-cause follow-up.
The process at Level 1
Twelve steps, one owning team (the ROC real-time function), two decisions, one iteration loop:
| # | Step | Routes to |
|---|---|---|
| 1 | Identify Incident | 2 |
| 2 | Send Initial Messaging | 3 |
| 3 | Ticket created? | Yes: 5 · No: 4 |
| 4 | Create a Ticket | 5 |
| 5 | Set Severity / Verify Correlation / Send Notification | 6 |
| 6 | Conduct Fault Analysis | 7 |
| 7 | Take Corrective Action | 8 |
| 8 | Monitor the Fix | Resolved: 9 · Not resolved: 6 |
| 9 | Close the Ticket | 10 |
| 10 | Post-mortem required here? (ROC-owned and Severity 1) | Yes: 11 · Else: 12 |
| 11 | Conduct Post-Mortem | 12 |
| 12 | Monitor RCA Actions | End |
Identification (step 1) is continuous rather than triggered: the real-time team monitors IVR analytics, service levels and queues, resource levels, external feeds, and inbound communications from network operations, centers, and vendor partners in parallel. A monitored signal becomes an incident when a defined entry criterion trips — a service level crossing its threshold for a sustained run of consecutive intervals, a monitored driver deviating beyond its band, or an external party reporting impact. The criteria themselves live in the escalation-code job aid — the artifact the real-time team already watches minute to minute, and where a degrading staffing state is usually the first visible symptom of an incident — so the front door of the process is a written rule rather than a judgment call.
Initial customer messaging (step 2) deliberately precedes ticketing: mitigation of service-level impact starts the moment an incident is recognized, not after administration. At step 5, classification splits by ticket class — severity is set for service-request tickets, while verifying correlation applies to monitoring-detected tickets: confirming that the active alarms map to a single underlying incident rather than several.
The step-10 gate combines two different questions on purpose. Ownership decides who runs the review — an incident owned by another organization is reviewed there, not by the ROC. Severity decides whether a formal post-mortem occurs at all.
Fault analysis and corrective levers
For the diagnostic frame in full, see Real-Time Cause and Effect Fishbone.
Fault analysis (step 6) runs on a fixed causal frame rather than open-ended investigation: four top-level causes covering poor line adherence, actual volume differing from forecast, the scheduled line differing from arrivals, and handle time running longer than forecast. Every corrective action (step 7) then pulls one or more of three levers: call volume (demand), agent resources (supply), or call duration (handle time). The discipline matters because incidents are diagnosed under time pressure. A bounded causal frame converts urgency into procedure, and it makes post-incident reviews comparable across incidents.
A Level 2 excerpt shows the decomposition texture at this point in the process:
| L2 | Sub-step | Depends | Tools | Duration |
|---|---|---|---|---|
| 6.1 | Engage fix agents; open an incident bridge for Severity 1–2 | 5 | Bridge line; chat | Minutes |
| 6.2 | Diagnose using the cause-and-effect diagram (four causes above) | 6.1 | Real-time dashboards | Minutes–hours |
| 7.1 | Determine corrective actions via the three levers; approval per escalation code | 6.2 | WFM platform; routing admin | Minutes |
Owner for all rows: ROC Real-Time Team. The full table runs thirty-four sub-steps across the twelve steps, with dependency, notification, approval, and documentation fields per row.
Severity and escalation codes
For the escalation-code machinery in full, see Real Time Threshold Alerts and Escalation Protocols.
Two classification schemes operate simultaneously and are commonly conflated. Severity (1–5) classifies the incident along an axis of breadth, duration, and service-level impact — from total loss of service at Severity 1 down to minor, localized degradation at Severity 5. Each severity row fixes a service-level threshold, an initial notification window, an update cadence, a fix-agent resolution target, and the organizations notified. The values are set locally; the row structure is the standard:
| Severity | Service-level threshold | Initial notification | Update cadence | Resolution target | Notified |
|---|---|---|---|---|---|
| 1 — total loss of service | set locally | set locally | set locally | set locally | set locally |
| 2 — severe sustained degradation | set locally | set locally | set locally | set locally | set locally |
| 3 — sustained degradation | set locally | set locally | set locally | set locally | set locally |
| 4 — limited degradation | set locally | set locally | set locally | set locally | set locally |
| 5 — minor, localized | set locally | set locally | set locally | set locally | set locally |
Escalation codes (Blue through Black) classify the staffing state of the operation, from overstaffed through ideal to progressively degraded conditions. The two intersect — a red staffing state typically requires an incident ticket — but one describes what happened to the operation and the other describes what the operation has become. Merging them loses the ability to represent a severe incident under control, or a degraded operation with no single incident to blame.
Closure and the learning loop
Closure (step 9) requires eight lifecycle facts recorded on the ticket: incident start, incident detected, fix agents engaged, customer impact, probable cause, mitigation, incident diagnosed, incident repaired. The record doubles as an instrument panel for the process itself. The gap between start and detected measures the monitoring net; between detected and engaged, the escalation machinery; between engaged and repaired, the fix capability.
Qualifying incidents get a post-mortem (step 11) with an independent moderator drawn from outside the team that worked the incident, walking the same eight lifecycle facts recorded at closure — reused deliberately as the review agenda — with each item examined for what went well and what did not. Recurring incidents feed the forecast and the collision calendar, converting incident history into planning input. Root-cause analysis (step 12) is performed by the primary fix agent with the ROC monitoring completion — the function that owns the cause owns the cure.
Decomposition
The full decomposition — Level 0 identity, the one-page Level 1 flow, the thirty-four-row Level 2 table, and the Level 3 register of eight job aids — follows the Process Decomposition (L0–L3) standard. A deployable template set is published as Wiki:Packs/Process Decomposition (CP-OPS-001). Practitioner treatments of the underlying real-time discipline appear in the ICMI literature.[2][3]
Maturity Model Position
Positions on the WFM Labs Maturity Model:
- Levels 1–2: incidents are handled by whoever notices them; no severity discipline, no lifecycle record. The first step up is the ticket and the eight facts.
- Level 3: the process runs as documented here — continuous identification with written entry criteria, bounded diagnosis, severity and escalation separated, post-mortems on qualifying incidents.
- Levels 4–5: detection increasingly automated against thresholds, corrective actions increasingly executed by real-time automation within governed bounds, and the lifecycle record mined systematically for forecast and design input (see Real-Time Exception Handling Playbooks).
See Also
- Process Decomposition (L0–L3) — the documentation standard this process demonstrates
- Event Management — the planned-event sibling
- Real-Time Cause and Effect Fishbone — the diagnostic frame of step 6
- Real Time Threshold Alerts and Escalation Protocols — the escalation-code machinery
- Daily ROC Routine — the operating rhythm incident management interrupts
- Real-Time Exception Handling Playbooks — the automation-era extension
References
- ↑ AXELOS (2019). ITIL Foundation: ITIL 4 Edition. TSO. The event/incident/problem separation originates in the ITIL practice framework.
- ↑ Cleveland, B. (2012). Call Center Management on Fast Forward (4th ed.). ICMI Press.
- ↑ ICMI (2011). Nine Steps to Creating an Effective Call Center Planning Process. https://www.icmi.com/resources/2011/nine-steps-to-creating-an-effective-call-center-planning-process (accessed September 2026).
