How to create an incident management process
How to design an incident management process where severity sizes everything downstream: classify before diagnosing, draw re-classification as a route, and hand the cause to a separate record.
A worked example, stage by stage
A thin ticket is a wrong priority
Intake is two rows: "Incident detected or reported" and "Log incident with impact details". Everything the priority is computed from is captured in the second — affected service, how many people, when it started, the symptoms — so a thin ticket does not delay the classification, it corrupts it.
Severity sizes what follows
The "Yes" exit of "Major incident?" is not a louder version of the same path: "Declare major incident" and "Open bridge and notify stakeholders" both happen before anyone diagnoses anything, and ownership moves from Service Desk to the Incident Manager lane. The "No" arm arrives next.
Two routes to a restored service
"Resolved at first line?" keeps the small ones short: its "Yes" exit goes to "Apply first-line fix". The rest join the Support Tier 2 / 3 lane, where "Resolution within SLA target?" is asked after diagnosis — so "Escalate breach and update stakeholders" reports a breach it is too late to prevent.
The reopen skips classification
The "Reopened" exit from "User confirms resolution?" re-enters at "Perform initial diagnosis", which sits below the severity call — so a reopened incident is diagnosed again but never re-classified, whatever the second failure has cost by now. "Raise problem record" is where the cause leaves.
How it works
Write the priority matrix before the chart
Priority is impact against urgency, and both need stated levels: how many users, which service tier, whether money or safety is involved, how fast the damage grows, whether a workaround holds. Agree those first, because a matrix invented while mapping describes the last incident rather than the next one.
Decide what a major incident actually changes
List what the declaration buys: a named owner, a bridge, updates on a fixed clock, permission to bypass normal change approval. If nothing changes except the label, the branch is decoration. The example spends two whole steps on it, which is the honest amount of work involved.
Type intake and classification as rows
Each row in QueryChart is a box. Put the trigger in the Box text column, then the logging step, then the categorisation step, and point each row at the next in the Line to column. Three rows in, the map has made its argument: the priority on row 3 is computed from what row 2 captured, which makes row 2 a design decision and not a form.
Fork the severity call and label both exits
Change the classification row's Shape column to Decision, list both destinations in Line to, then give each number its answer in Line text. The chart forks once, at "Major incident?", though the matrix has four or five levels — and those two labels do more work than any other pair here, because they are the only place the route changes.
Point the reopen path at a lower row number
A fix the reporter rejects goes back to diagnosis: the "Reopened" exit from row 15 points at row 7. A severity called wrong needs the same treatment and the example does not draw it — add a branch from the diagnosis rows back to "Categorise and set priority". Each is a lower number in the Line to column.
Calibrate the matrix, then name who declares
Put the matrix where whoever logs the ticket can read it, then test it: give two people on opposite shifts the same three descriptions and compare what they set. Disagreement means a missing level, not a careless colleague. Then name the person on each shift who may answer Yes at "Major incident?" before the Incident Manager is awake.
Frequently asked questions
What is the difference between an incident and a problem?
An incident is an interruption to a service; a problem is the underlying cause of one or more incidents. They are kept as separate processes because they run on different clocks — incident management is measured on time to restore, problem management on whether the cause has actually been removed, which can take weeks. Merging them means the cause work inherits the incident's urgency and is abandoned the moment the service comes back.
How do you decide incident priority?
From impact and urgency on a published matrix, not from who is asking. Impact is how much of the organisation is affected: users, sites, service tier, whether money or safety is involved. Urgency is how fast the damage grows and whether a workaround holds. The matrix turns that pair into a priority, and it earns its place only if the figures behind the call are recorded alongside it — a priority nobody can reconstruct cannot be challenged when it turns out to be wrong.
When should an incident be declared a major incident?
When it crosses a threshold agreed in advance — a tier-one service down, a stated number of people unable to work, regulatory or safety exposure, a suspected breach. The declaration only earns its place if it changes behaviour: a named incident manager, a bridge, updates on a fixed cadence. Declaring late is the common failure, and the cost of declaring and then standing down is far lower than the cost of an hour of quiet.
Should a reopened incident be a new ticket?
No — reopen the original, because the two records answer different questions. A new ticket resets the resolution clock and reports one failed fix as two successful ones, which is precisely the distortion that hides an unstable service. Reopening on the same record keeps the history in one place and makes the reopen rate measurable, and reopen rate is the most honest quality signal an incident process produces.