There is a version of this you have probably seen: a genuinely well-written SOP that nobody opens. The steps are right, someone put real work into it, and the person who is supposed to follow it does the task from memory anyway — because reading four pages of numbered paragraphs takes longer than doing the job, badly, from what they remember.
That document did not fail because it was written poorly. It failed because it was in the wrong shape for the task it described.
Format is the part of SOP writing most people never consider. They pick one — usually a numbered list, because that is what an SOP looks like — and use it for everything, including the tasks it is worst at. There are four standard formats, they are not interchangeable, and picking the right one is often the whole difference between a procedure that gets used and one that gets ignored.
The four SOP formats
1. Simple steps. A flat numbered list. Best for short, linear tasks — roughly a dozen steps, no branching, nothing that needs its own explanation. Send the invoice. Log it. Set the reminder. Most small-business SOPs are this, and for the tasks that suit it, anything fancier is overhead.
2. Hierarchical steps. Main steps numbered, sub-steps nested underneath (1, 1.1, 1.2). This is what you move to when a flat list gets long enough that people lose their place in it — past about fifteen steps, or when a single step needs three lines of its own. The advantage is scanning: someone who has done it before reads only the top level and drops into the detail where they need it, while a newcomer reads everything.
3. Flowchart. Boxes and arrows. Use it when the difficulty of the task is deciding, not doing — approvals, escalations, triage, qualification, anything where the honest answer to “what happens next” is “it depends.” A flowchart shows every branch at once, which prose cannot do without turning into a thicket of nested ifs.
4. Checklist. Just the items, with boxes. This is for tasks that are run often by someone who already knows how — where the risk is not ignorance but omission. Pre-flight checks, closing procedures, onboarding steps. The reason it works is precisely that it does not explain: it is a memory aid, not a teacher.
The two questions that pick for you
You do not need to agonise over this. Two questions resolve almost every case.
How many decisions does the task contain? If the answer is “none, you just do the steps in order,” you want simple or hierarchical. If you find yourself writing if the client has already paid… but if the deposit is short… unless it’s a renewal — stop. That is a flowchart trying to get out, and forcing it into prose is why nobody can follow it.
How often does one person run it? A task someone does twice a year needs the full document, because they will have forgotten it. A task someone does three times a day needs a checklist, because they have not forgotten anything — they are just moving fast and about to skip step four.
Put together, that gives you a rough map:
| The task | Format |
|---|---|
| Short, linear, done occasionally | Simple steps |
| Long or detailed, done occasionally | Hierarchical steps |
| Mostly decisions and branches | Flowchart |
| Well known, done frequently | Checklist |
Where each one breaks
Every format fails at something, and knowing the failure is faster than debating the choice.
Simple steps break on length. Past fifteen or so items people lose their position, especially if they were interrupted — and they are always interrupted.
Hierarchical steps break when the nesting becomes the point. Three levels deep and you have written an org chart, not a procedure. If you need 1.2.4, the task is really several tasks wearing one title.
Flowcharts break on detail. A box cannot hold the sentence explaining what “verify the details” means, so flowcharts quietly assume knowledge the reader may not have. The fix is a hybrid: the chart for the route, a short written note for the steps that need one.
Checklists break on new people. Handing a checklist to someone who has never done the task gives them a list of things they do not know how to do — which reads as a test rather than instructions.
Which points at something worth saying plainly: the same procedure can legitimately exist in two formats. The full document is what you train from. The checklist is what gets used at speed once someone knows it. That is not duplication, as long as one of them is clearly the source and the other is derived from it.
The format that is not on the list
Prose. Paragraphs of explanation, written the way you would describe the task out loud.
It is the most common thing people produce when asked to document something, and it is the one format that never survives contact with someone actually doing the work. Nobody reads a paragraph with one hand on the keyboard. If your SOP is currently paragraphs, converting it to a numbered list — changing nothing else — will usually do more for adoption than another round of editing.
Why the wrong format quietly costs money
A procedure nobody opens is the same as no procedure. The task keeps living in one person’s head, keeps coming back to them, and keeps being the thing that stalls the week they are busy.
And look at which tasks those are. The follow-up that never went out. The onboarding step someone skipped. The invoice that sat unsent for a week. The client who was never told their job had moved. Those are not dramatic failures — nobody complains, nothing breaks loudly. Admin is loud: the form with a deadline, the portal sending reminders, the client already waiting. The work that earns is quiet, and quiet work is what gets dropped on a busy week. It does not get rejected. It gets forgotten, and nothing anywhere records that it happened.
A usable SOP is how that stops depending on whether someone was having a good week. Which is why format is not a cosmetic question — it decides whether the document is used at all, and an unused document protects nothing.
Start by reformatting one
If you already have SOPs that nobody follows, do not assume they need more detail. Take the one that gets ignored most, and ask the two questions: how many decisions, how often run. Then put the same content into the format the answers point at. It usually takes twenty minutes, and it is the cheapest improvement available to you.
If you are starting from nothing, the free SOP template gives you the sections, and how to write an SOP covers the method. Format is the layer on top: same content, right container.
Getting the work out of your head and into a form people actually use is step one. Having an AI employee run those procedures for you — the same way every time, without anyone remembering to — is step two, and that is what we build at CoreFlux.