Incident management process flowchart
A cross-functional incident management process flowchart covering logging, prioritisation, major incident escalation, SLA breach, resolution and closure.
How it works
Rename the lanes to your real roles
Replace Reporter / User, Service Desk, Incident Manager and Support Tier 2 / 3 with the roles that exist in your organisation. Small teams often merge Incident Manager into the Service Desk lane; teams with a NOC add a monitoring lane above the reporter.
Define your priority matrix
Attach your impact and urgency definitions to the 'Categorise and set priority' step. Write down what P1 through P4 mean in terms of users affected and business impact so priority is derived, not negotiated per ticket.
Set the major incident trigger
Decide what makes the 'Major incident?' decision a yes: a revenue-affecting service down, a named critical system, a customer count threshold. Name who can declare it and what happens immediately after, such as opening a bridge and starting a fixed update cadence.
Wire in your SLA targets and breach escalation
Put your response and resolution targets on the 'Resolution within SLA target?' decision, and state who is notified on the breach branch and how far ahead of the deadline. The point of the branch is early warning, not after-the-fact reporting.
Agree the closure and problem management rules
Define what counts as confirmed by the user, how long a ticket stays in resolved before auto-closing, and the criteria on 'Root cause still unknown?' that push an incident into problem management. Recurring symptoms and every major incident are the usual triggers.
Walk it with each lane, then publish a versioned copy
Review the chart with the people in each lane and correct the steps they actually perform. Once it is agreed, publish it as the current version with a sign-off, so anyone reading it later knows which revision was in force.
Frequently asked questions
What is the difference between incident management and problem management?
Incident management restores service. Problem management removes the cause so the incident stops recurring. They run on different clocks: an incident is measured against an SLA in minutes or hours, while a problem record can stay open for weeks of investigation. In this chart the two connect at closure, where 'Root cause still unknown?' raises a problem record without holding the incident open. Mixing them is the most common failure, and it shows up as tickets that stay open long after the user is working again.
When should an incident be declared a major incident?
When the impact justifies breaking the normal queue: a business-critical service is unavailable, a large group of users is blocked, or there is a safety, financial or reputational exposure. The trigger should be written down before you need it and be objective enough that a first-line agent can apply it at 2am. Once declared, the process changes shape rather than just speeding up. A named incident manager takes ownership, a bridge opens, and stakeholder updates go out on a fixed schedule regardless of whether there is news.
What happens when an incident is going to breach its SLA?
The breach branch is a hierarchic escalation, not a technical one. The work continues, but the incident manager is pulled in to reset expectations with the customer, reassign resources if needed, and record why the target is being missed. The important detail is timing: the branch should fire before the deadline passes, based on a threshold such as 75 percent of the remaining time, so the conversation with the customer happens ahead of the breach rather than as an apology afterwards.
Who closes the incident, and what counts as resolved?
Resolution and closure are two different states. An engineer marks an incident resolved when the fix is applied and the service is back. It is only closed once the reporter confirms the service works for them, which is why this chart routes through 'Confirm service is working' in the Reporter lane and a 'User confirms resolution?' decision before closure. If the user says the problem persists, the ticket reopens to initial diagnosis rather than starting a new one. Most teams also set an auto-close window, typically three to five working days of no response.