SOP flowcharts: turning a written procedure into a diagram

Most standard operating procedures start life as a document. Numbered steps, a few notes, some exceptions in brackets, and a line at the end about who to call. They are accurate, and they are hard to follow while doing the work. A new starter reading step 14 has usually forgotten the condition in step 6.

A flowchart doesn’t replace the written SOP. It sits on top of it, showing the route through the procedure at a glance, while the document keeps the detail. This article explains how to make that conversion without dropping anything important.

Decide what the flowchart is for

An SOP flowchart can serve two quite different readers:

• The new starter, who needs to see the whole procedure and understand where the decisions are.
• The experienced operator, who needs a quick reminder at the point of work, perhaps pinned beside a workstation or opened next to a ticket queue.

The first benefits from slightly more context. The second benefits from fewer boxes and large labels. If both groups matter, make the main chart for the new starter and a one-page quick reference for the operator.

Mark up the written procedure first

Print the SOP or open it in a document and go through it with three colours, or three kinds of mark:

1. Actions. Anything someone does: “Log the return”, “Inspect the item”, “Issue the credit note”.
2. Decisions. Anything that changes what happens next. Look for if, unless, only when, in case of and otherwise.
3. Notes. Explanations, reasons, references to forms or policies.

Only the first two go into the chart. Notes stay in the document, linked by step number. Trying to fit notes into boxes is the most common reason SOP flowcharts become unreadable.

Rewrite the steps for boxes

Written procedures often combine several actions in one sentence: “Check the item against the order, confirm the serial number and record any damage in the returns log.” On a chart, that is either one box (“Inspect and log the item”) or three, depending on whether the steps can go wrong separately.

A useful test: if a step can fail on its own and needs its own response, give it its own box. If the steps always happen together and succeed or fail together, keep them as one.

Write every box with a verb first and keep it to three to six words. Number the boxes to match the SOP steps, for example “4. Inspect and log the item”, so readers can move between chart and document.

Pull the hidden decisions out

Written SOPs bury decisions in the middle of sentences. “Items over 30 days old should be referred to the supervisor unless the customer has a warranty” contains two decisions:

• Is the item more than 30 days old?
• Does the customer have a warranty?

Turn each into a yes/no diamond. Then check the order. In this example, the warranty question may need to come first, because it changes the answer to the age question. Drawing the decisions out is often where teams discover that the written procedure was ambiguous.

Show who does what, if more than one role is involved

If the procedure passes between roles (a counter assistant, a supervisor, a finance team), consider drawing it with lanes, one per role. Responsibility then becomes visible, and so do the handoffs, which is where procedures tend to break. Swimlane diagrams explained covers the layout in detail.

If one person does everything, skip the lanes. They add width without adding meaning.

Handle exceptions without clutter

SOPs exist partly because of exceptions. The chart must show them, but not let them take over:

• Keep the normal path running straight down the page.
• Branch exceptions to the side, and end each one clearly: “Refer to supervisor”, “Return to customer”, “Escalate to quality team”.
• If an exception has its own multi-step procedure, show it as a single box marked as a separate process (a rectangle with double sides) and give it its own chart. Escalations are a common case; escalation path diagrams shows how to draw one with roles and time limits.

A good test is whether a new starter could follow the normal path without reading any exception branch.

Check it at the point of work

Before publishing, give the chart to someone who does the procedure regularly and someone who has never done it. Ask the experienced person where the chart is wrong. Ask the new person to talk through a sample case using only the chart.

Typical findings:

• a step people do that the written SOP never mentioned
• a decision that is made informally and differently by different people
• a step in the SOP that nobody actually does any more

Each of these is a finding about the procedure, not only about the chart. Fix the written SOP at the same time, so the two stay in step.

Keep the chart and the document together

An SOP flowchart is only trusted if it matches the current version of the procedure. A few habits help:

• Put the SOP reference and version on the chart: “SOP-RET-02, version 4”.
• Store the chart in the same place as the document, not in a separate folder.
• When the procedure changes, update the chart in the same edit.

A marked-up procedure, with actions, decisions and roles identified, is also a clean description to work from in any diagram tool, DiagramsPro included.