Checklists, SOPs, Playbooks and Policies: Which One You Actually Need

Most process documentation fails before anyone reads it, because it was written in the wrong form. A twelve-page SOP for a task an experienced person does weekly gets skimmed once and abandoned. A three-line checklist for something nobody has been taught leaves them guessing.

Four formats, and two questions decide between them.

The two questions

Does the order matter? If steps must happen in sequence, or if omitting one causes a problem, you need something ordered.

Does the person need to make judgement calls? If the right action depends on the situation, steps will be wrong some of the time and you need principles instead.

| | Order matters | Order doesn't | |---|---|---| | No judgement needed | Checklist or SOP | Policy | | Judgement needed | Playbook | Policy |

Checklist — for people who already know

A checklist prevents omission. It does not teach.

Use it when the person is competent and the risk is forgetting something under time pressure or repetition. Pre-flight checks, month-end close, publishing a page, closing up.

CLIENT ONBOARDING
- [ ] Signed agreement filed
- [ ] Client added to CRM with owner assigned
- [ ] Welcome pack sent
- [ ] Portal access created
- [ ] Kickoff call booked
- [ ] Added to weekly report

Short lines, no explanation. The moment a checklist starts explaining, it's turning into an SOP and it will stop being used as a checklist — people skim past prose to find the boxes.

The test: could someone who has done this task ten times use it without reading anything but the box labels? If not, it's too wordy.

SOP — for people who need teaching

An SOP transfers capability. It's what you write when someone else will do this and doesn't yet know how.

It carries the things a checklist deliberately omits: the trigger, the exact tools and names, what each step should produce, and what to do when something varies. The format and the rules — one action per step, a verifiable outcome, name the exact thing — matter because the reader has no context to fall back on.

If your SOPs are only read by people who already know the job, you wrote the wrong document. Extract a checklist from each one and let the SOP be the training material it should have been.

Playbook — for situations that vary

A playbook is for work where steps would be wrong half the time.

Handling a complaint. Responding to a competitor's price cut. A client asking for something out of scope. Deciding whether to take on an unusual project.

Structure it as situation → principle → options → escalation:

Situation: A client asks for work outside the agreed scope.

Principle: Scope changes get priced. We don't absorb them to keep the peace, because it sets the precedent for the rest of the engagement.

Options: — Small and quick: do it, note it, mention it in the next update so it's visible as a goodwill item rather than a new baseline. — Meaningful: quote it as a change order at the published rate. — Large: treat it as a new project and scope it properly.

Escalate when: the client pushes back on being charged, or the request would delay the agreed timeline.

Steps would fail here. The principle plus a few named options lets someone handle a case nobody anticipated, which is the whole job.

Policy — for boundaries, not sequences

A policy answers "what's allowed" rather than "how do I do it."

Expenses. Anything under £200 that's clearly for the business: buy it, submit the receipt. Above £200, ask first. Anything with a recurring subscription, ask first regardless of amount.

Two sentences that remove a dozen individual questions. The value of a policy is that it prevents the question from being asked, which is a different job from telling someone how to do something.

Policies fail when they're written as aspirations rather than rules. "Employees should be mindful of spending" is not a policy; it's a hope. A policy has a number or a boundary in it.

Matching them up

| Work | Format | Because | |---|---|---| | Month-end close, by the person who always does it | Checklist | Competent, needs prompting | | Month-end close, taught to a new hire | SOP | Needs teaching | | Handling an unhappy client | Playbook | Every case differs | | What can be expensed without asking | Policy | It's a boundary | | Publishing a blog post | Checklist | Ordered, no judgement | | Deciding whether to take on a project | Playbook | Judgement, with principles | | Password and access rules | Policy | A rule, not a sequence |

The two common errors

Writing an SOP for expert users. It becomes a document that nobody opens, which then looks like a documentation-adoption problem when it's a format problem. Extract the checklist.

Writing an SOP for something that needs judgement. You end up with a step that says "assess the situation and respond appropriately," which is the writer admitting the format was wrong. That whole section wants to be a playbook.

Start with the format, not the document

Before writing anything, answer the two questions. It takes thirty seconds and it determines whether anyone will use the result.

A useful heuristic: if you find yourself writing "it depends" more than twice, stop and switch to a playbook. If you find yourself writing explanations in a checklist, stop and decide whether the reader actually needs teaching.

What to do next

Take your three most-used process documents and ask who reads them. If experienced people are skimming an SOP for one step, extract a checklist. If a document keeps saying "use your judgement," it wanted to be a playbook.

Once formats are right, the next problem is usually where any of it lives — a correctly formatted document nobody can find is the same as no document.