IT Service & Operations · IT Service Management (ITSM)

Incident Management

Implementation path

● This moduleIncident Management

Required by these capabilitiesMajor Incident Management

Commonly implemented afterwardChange Management On-Call Scheduling

Works well withAdvanced Work Assignment (AWA)Cloud Observability Event Management Now Assist (Generative AI)Performance Analytics Platform Experience & UI Predictive Intelligence Problem Management Security Incident Response (SIR)Service Mapping Virtual Agent

Capability comparison

Incident Management and Change Management

Incident Management restores service fast and minimizes business impact. Change Management controls the lifecycle of production changes so fixes don't cause the next outage.

Incident Management provides

Structured intake, prioritization, and routing of incidents from any channel
Workflow and automation for diagnosis, investigation, escalation, and resolution
Service-level tracking, dashboards, and reporting on incident resolution performance
Knowledge search and reusable resolution guidance that helps agents resolve repeat issues consistently
Self-service, agent workspace, and communication tools that keep requesters informed through restoration

Change Management provides

Systematic change lifecycle control with risk assessment, approval, and scheduling
Change Advisory Board (CAB) Workbench for planning and managing CAB meetings
Conflict detection and blackout windows to prevent overlapping or risky changes
Service Maps integration showing change impact on business services at a glance
Change approval policies that balance governance with DevOps velocity
Automated change-task orchestration, notifications, and approval routing that support controlled execution

Consider it when

The IT team already handles incidents well but changes are ad hoc, high-risk, or cause their own incidents.
Leadership wants formal change governance, audit trails, CAB reviews, or risk-based approval before production changes.
DevOps teams need change policies that accelerate approved standard changes without blocking velocity.
Do not treat Change Management as a prerequisite for Incident Management - adopt it when the volume and risk of production changes demands systematic control.

Where the capabilities overlap

Both are core ITSM processes sharing the same platform, CMDB, and CI context - an incident may trigger a change, and a change may cause an incident.
Both can feed and consume data from the same operational sources, but Incident Management is about restoring service now while Change Management is about controlling what is deployed next.

Sources

Incident Management ↗Change Management ↗IT Service Management ↗

Incident Management and Change Management can be adopted independently. The sequence shown is practical implementation guidance, not an installation prerequisite.

What it is (plain English)

The system your IT team uses when something breaks: a user reports it (or a monitoring tool detects it), the right team gets it, works it, and restores service as fast as possible. An "incident" is simply an unplanned interruption or degradation of a service - from "my laptop won't start" to "email is down for everyone."

Problems it solves

Issues reported by email, chat, and hallway conversations get lost or forgotten.
No visibility into what's broken, who's working on it, or how long fixes take.
The same information is asked for over and over because nothing is recorded once.
No numbers to show the business how IT support is actually performing.

What must exist first

Platform Core Setup is required - incidents route to groups of people, so users and support groups must exist. A CMDB is strongly recommended (it powers "what is affected?" and smarter assignment) but a lean incident process can go live before the CMDB matures.

What the customer needs to provide

Your support team structure: which teams exist (service desk, network, apps…) and who is in them.
How urgent is urgent: agreement on what counts as high/medium/low impact for your business.
Your current intake channels (phone, email, walk-up, another tool) and which ones should feed ServiceNow.
Response and resolution time targets, if you have them (formal or informal).
A short list of your most common issue types - this seeds categories that make reporting useful.

Where it can go next

Major Incident Management adds a coordinated response process for the big outages; On-Call Scheduling gets the right person paged after hours; Problem Management stops repeat incidents at the root. Monitoring integration via Integration Foundation can create incidents automatically before users even call.