How to create an SOP flowchart
How to create an SOP flowchart: one procedure per chart, numbered steps, decision points with stated criteria, and an approved version under change control. With a worked incident-response example.
A worked example, stage by stage
Log it before you diagnose it
Detected, logged with impact, categorised and prioritised. An SOP starts at the moment the person reading it is standing in — and for incidents that is before anyone knows what is wrong, which is why logging comes before diagnosis.
Branch at the severity call
"Major incident?" splits the procedure: declare, open a bridge, notify stakeholders — or carry on with first-line diagnosis. The criteria for that call belong on the decision itself, because it is made under time pressure by whoever is on shift.
Escalate on a rule, not a feeling
Second-line investigation, an explicit SLA check with a breach-escalation branch, then restore and confirm with the user. Note the reopen path: an unconfirmed fix goes back to diagnosis rather than being closed hopefully.
Close it, and feed what you learned back
Closure notes, then a decision on whether the root cause is still unknown — if it is, a problem record is raised. An SOP that ends at "service restored" loses the one output that stops the same incident recurring.
How it works
Scope it to a single procedure
Write the trigger in one sentence: "an incident is detected or reported". If the trigger needs an "or" that covers a genuinely different situation, that is a second SOP. Keeping each chart to one procedure is what keeps it short enough to be opened in an emergency.
Write the steps as instructions
Verb first, one action each, addressed to the person doing it: "Log incident with impact details", not "Incident is logged". Passive phrasing hides the owner, and an SOP whose steps have no owner is the reason two people do the same step and a third does none of it.
Put the criteria on the decisions
"Major incident?" needs a definition next to it — number of users affected, service tier, revenue impact, whatever your organisation uses. Use the step's comment field for the rule. Decisions without criteria are made differently by every person who reads the chart, which defeats the word "standard".
Add the escalation and reopen paths
Draw what happens when the SLA is about to breach, when the fix does not hold, and when the person who normally does this is unavailable. These are the paths an SOP is consulted for. Each one either rejoins the flow or ends in its own terminator.
Assign the lanes, then walk it with the on-call team
Put each step in the lane of the role that performs it — service desk, incident manager, second line — and read it through with the people who will use it. Ask them where they would hesitate. Every hesitation is a step that needs either a criterion or a split.
Approve it, version it, and set a review
Route the chart through the approval workflow so the current version has a reviewer and a date, and put a review trigger on it: after any major incident, and at least annually. In QueryChart the approval and the change history live with the chart, so "which version was in force in March" has an answer.
Frequently asked questions
What is the difference between an SOP and a process flowchart?
An SOP is a controlled instruction for performing a specific task: numbered, owned, approved, versioned, written for the person doing the work. A process flowchart is a picture of how work flows, often across several roles, and it may be descriptive rather than mandatory. Drawing an SOP as a flowchart gives you both — the readability of a diagram with the control properties of a procedure — as long as the approval and version history come with it.
Should an SOP be a flowchart or written text?
Both, from one source. A flowchart is faster to follow under pressure and makes gaps in the branching visible; text carries the detail a diagram cannot hold, such as exact field values or safety warnings. The failure mode is keeping them as two separate documents, because they drift. Generate the procedure text from the same rows as the diagram, so a change to one is a change to both.
How long should an SOP flowchart be?
Short enough to fit on one screen at a readable size — in practice fifteen to twenty-five steps. Beyond that, look for a natural handoff and split it into two procedures that reference each other. Long SOPs are not more thorough; they are less likely to be opened, and an SOP nobody opens provides exactly as much control as no SOP at all.
Who approves an SOP?
The process owner, plus whoever is accountable for the risk it controls — often quality, compliance or the service owner. What matters procedurally is that the approval is recorded against a specific version with a name and a date, so there is no ambiguity about which text was in force at any point in the past. That record is what turns a document into a controlled one.