Incident management restores normal service as fast as possible when something breaks, and keeps users informed while it happens. This page explains the ITIL 4 incident management process, the priority matrix, SLAs and KPIs, and how SMC Consulting configures it in HaloITSM or in the tool you already use.
Incident management is the ITIL 4 practice that minimises the negative impact of incidents by restoring normal service operation as quickly as possible. An incident is an unplanned interruption to a service, or a drop in its quality: the VPN refuses connections, an application is slow, a printer floor stops working. The goal is to get users working again, not yet to find out why it happened.
That last point is what separates incidents from the neighbouring practices:
| What it is | Goal | |
|---|---|---|
| Incident | An unplanned interruption or degradation of a service | Restore service fast |
| Problem | The underlying cause of one or more incidents | Find and remove the root cause |
| Service request | A planned request: access, equipment, information | Fulfil it through the catalogue |
| Major incident | An incident with high business impact | Restore service with a dedicated procedure |
Mixing incidents and requests in one queue slows both down; see service request management for the request side. Incident management is one of the core ITSM processes.
Reviewed by the ITIL v4 certified consultants of SMC Consulting. Source: the ITIL 4 Incident Management practice, ITIL 4 (PeopleCert).
Six stages, from the first signal to the closed record. Each one is configured in the tool to match your operating model, not left on default settings.
When the fix needs a change to production, it leaves incident management and follows change management.
The incident arrives through the portal, email, Teams, a call or a monitoring alert, and is recorded with its source, time and standard fields.
The category follows your service catalogue; the priority comes from the impact Ă— urgency matrix and sets the SLA targets.
First-line checks the knowledge base and known errors, resolves what it can and assigns the rest to the right resolver group.
Specialists investigate with the CMDB and the incident history; escalation fires before the SLA target is breached.
The fix or workaround is applied, the user confirms service is back, and the resolution code and notes are recorded.
The record is closed with clean data; recurring and major incidents go to problem management and feed the next review.
Priority is not a feeling. It comes from two questions: how many people or how much of the business is affected (impact), and how fast the damage grows (urgency). Crossing them gives a priority every agent applies the same way.
| Impact \ Urgency | High | Medium | Low |
|---|---|---|---|
| High (a service or site down) | P1 Critical | P2 High | P3 Medium |
| Medium (a team or department) | P2 High | P3 Medium | P4 Low |
| Low (one user, a workaround exists) | P3 Medium | P4 Low | P5 Planning |
Each priority then carries a response and a resolution target. The values depend on your services, opening hours and contracts, so we set them with you rather than copy a template. Two rules make them work: the SLA clock starts when the incident is logged, and escalation fires before the target is breached (for example at 75% of the time elapsed), while there is still time to act. Functional escalation moves the ticket to a more specialised team; hierarchical escalation informs a manager when a decision or extra resources are needed.
Clear criteria to declare a major incident, a named manager, a dedicated team and a shorter decision path. Declaring early beats escalating late.
Users and management receive updates at agreed intervals, through the portal, Teams or email, so the service desk is not flooded with "any news?" calls.
After service is restored, recurring or major incidents become problem records: root cause, known error, workaround, permanent fix.
The permanent fix is a change: assessed, approved and scheduled, so the cure does not cause the next incident.
We work in four phases: design the operating model, configure the tool, add knowledge, AI and automation, then train and hand over. HaloITSM is our pick for most mid-sized organisations, but the process itself works on any of the 10 ITSM platforms we work on: we configure the same model in the tool you already have.
Email, self-service portal, Microsoft Teams, API and monitoring alerts, with standard forms and mandatory fields so the first record is usable for triage and reporting.
Categories mapped to your services, and routing by category, affected service and user, so tickets reach the right resolver group the first time.
Response and resolution targets per priority, warnings before the breach, and escalation paths agreed with each team.
Relevant articles suggested to agents while they investigate and to users while they log the incident, plus a prompt to update knowledge at closure.
Incidents linked to configuration items and services, so agents see what else is affected and problem management sees the patterns.
Ticket logging, updates and approvals inside Teams, and links with Jira, Azure DevOps and PagerDuty where development or on-call teams are involved.
Many incidents still arrive by phone, often outside office hours. AurionAI, an AI helpdesk for IT support made by our partner AurionAI SRL, answers calls, chats and emails 24/7, verifies the caller, and solves the request or creates the incident ticket in your ITSM with its category and priority. Agents start from a complete ticket instead of a voicemail.
In a free 30-minute audit, a senior consultant reviews your incident process, priorities and SLAs with you and leaves you with your three priorities.
When the backlog keeps growing, the fix is usually in triage, SLA design and knowledge, not in a new tool.
Access, equipment and information requests belong in the service catalogue, with their own forms and approvals.
Who carry the queue, the SLAs and the escalations every day and need a process the whole team applies.
Who need fewer outages, faster recovery and figures they can report to the business.
Who want a lifecycle, priorities and handovers that people actually follow.
| KPI | What it tells you |
|---|---|
| Mean time to resolve (MTTR) | The average time from logging to resolution, per priority. |
| First contact resolution (FCR) | The share of incidents resolved at the first contact, without escalation. |
| SLA compliance | The share of incidents resolved within target, and how close the others came. |
| Reopen rate | Incidents reopened after resolution: a direct signal of fix quality. |
| Backlog age | How long open incidents have been waiting; the oldest show where the process breaks. |
Definitions, formulas and targets are in our guide to ITSM KPIs.
An incident is the interruption itself: a service is down or degraded and users need it back. A problem is the cause behind one or more incidents. Incident management restores service as fast as possible; problem management finds and removes the cause so the incident does not come back.
Detect and log, categorise and prioritise, diagnose and assign, investigate and escalate, resolve and recover, close and review. ITIL 4 does not impose a fixed sequence, but these six stages are what most service desks run, and each one should be visible in the tool.
With an impact Ă— urgency matrix. Impact measures how much of the business is affected, urgency how fast the damage grows; the combination gives a priority from P1 to P5, and each priority carries its own SLA targets. The matrix must be simple enough that every agent reaches the same answer.
Mean time to resolve, first contact resolution, SLA compliance, reopen rate and backlog age, completed by user satisfaction. Track a short list monthly and act on it. Our ITSM KPI guide gives the definitions.
An incident whose business impact is high enough to need its own procedure: a named major incident manager, a dedicated team, regular communication to users and management, and a review afterwards. The criteria for declaring one should be agreed in advance, not debated during the outage.
No. The process, the priority matrix and the SLAs come first, and they work in any ITSM tool. HaloITSM is our pick when a tool change is on the table; otherwise we configure your current platform. A free 30-minute audit tells you which applies.
Book your free 30-minute ITSM audit. A senior consultant reviews your incident process, priorities and SLAs with you and leaves you with your three priorities.
Learn how the ServiceNow MCP server connects AI agents to governed ITSM workflows, Action Fabric and secure enterprise automation, plus readiness steps for 2026.
Read more →
Learn how a HaloITSM Lansweeper integration connects discovery data to HaloITSM, enabling cleaner CMDB records, faster triage, and better change decisions.
Read more →
A practical ServiceNow migration cutover plan helps reduce risk, protect service continuity, validate integrations and support confident ITSM modernisation.
Read more →
