Incident management process map

What is in this map

19 steps across 4 swimlanes and 5 phases, with 5 decision points.

Swimlanes (who does the work)

Reporter / User, Service Desk, Incident Manager and Support Tier 2 / 3

Phases (left to right)

Detect and log, Categorise and prioritise, Diagnose and escalate, Resolve and recover and Close and improve

Why map this process

During an incident nobody reads a procedure. They act from whatever model of the process they already have, which is why the value of an incident map is almost entirely in what it establishes beforehand: who decides the priority, who is allowed to escalate, and at what point the incident manager takes over from the service desk. Those three answers are what keep a major incident from being run by committee.

Categorisation and prioritisation are drawn as separate steps on purpose. Category routes the incident to the right team; priority sets the clock. Teams that merge them end up assigning priority by category (every network incident is a P2) and lose the ability to say that this particular network incident has stopped the warehouse.

Every step in the map

This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.

The decision points

Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.

• 4. **Major incident**?

  Owned by Service Desk · Categorise and prioritise

  • Yes → step 5
  • No → step 7

• 8. Resolved at **first line**?

  Owned by Service Desk · Diagnose and escalate

  • Yes → step 9
  • No → step 10

• 11. Resolution within **SLA target**?

  Owned by Support Tier 2 / 3 · Diagnose and escalate

  • Yes → step 13
  • No → step 12

• 15. User confirms resolution?

  Owned by Service Desk · Resolve and recover

  • Yes → step 16
  • Reopened → step 7

• 17. **Root cause** still unknown?

  Owned by Service Desk · Close and improve

  • Yes → step 18
  • No → step 19

Notes on specific steps

These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.

2. Log incident with impact details

Capture affected service, who is affected, time detected and symptoms. A thin ticket here costs hours later.

3. Categorise and set priority

Priority comes from impact and urgency on an agreed matrix, not from who is shouting loudest.

6. Open bridge and notify stakeholders

Major incidents run on their own comms cadence: a bridge, a named owner, and updates on a fixed clock.

12. Escalate breach and update stakeholders

Escalate before the target is missed, not after. Reset expectations early and record why the target moved.

16. Close ticket with resolution notes

Record the resolution category and the actual fix so the same symptom is searchable next time.

Making it yours

Put your priority matrix in the Notes column on the prioritisation step, and your escalation thresholds in the branch labels on the escalation decisions. That is the whole adaptation for most teams. If you run a separate major-incident procedure, add a decision immediately after prioritisation whose branch leaves this map: a reference is better than inlining a process that has its own bridge call and its own comms plan.

What to watch out for

• Resolution and closure are separate steps because a fix is not confirmed until the reporter says so. Maps that end at 'resolved' produce the reopen-loop everyone complains about, with no route drawn for it.
• The 'improve' step at the end is the one that gets cut first and matters most: it is the only link between incident handling and problem management. Keep it even if it is aspirational; a step nobody does is at least a visible gap.
• Do not give every support tier its own lane if the escalation between them is informal. Two lanes that hand work back and forth without a decision between them is a map of an argument, not a process.

Frequently asked questions