Writing an SOP your team will actually open

The document nobody opens

Almost every store has a folder of procedures somebody wrote during a quiet week. Almost nobody opens them. When a new person asks how returns work, someone explains it verbally, and the document sits there being technically correct and practically irrelevant.

The usual explanation is that people are lazy or that the team lacks discipline. That is rarely it. The real reason is that the document was written for the wrong moment.

SOPs get written when the author is calm, has time, and knows the process intimately. They get read when the reader is busy, slightly stressed, has never done this before, and needs one specific answer. Writing for the first situation and reading in the second is why the document fails.

Write for the moment of use

Picture the actual reader. It is Saturday. They are covering for someone. A customer is waiting. They have opened your document because they need to know one thing.

That reader does not want context. They do not want the rationale. They want the step they are stuck on, and they want it in the first screen.

Everything below follows from taking that seriously.

Lead with the answer, not the background

Most SOPs open with scope, purpose and a definitions table. Nobody in a hurry reads any of it. Put the procedure first and the context at the bottom, where the person who genuinely wants to understand the reasoning will find it and nobody else has to scroll past it.

One decision per step

Steps that contain two decisions are where people go wrong. "Check the order and refund if appropriate" is two steps and a judgement. Split it, and replace "if appropriate" with the actual condition.

Name the thing on screen

Write what the reader will literally see. "Click Refund" beats "process the refund", because the second requires them to translate your language into the interface. If a button is called something unhelpful, quote it anyway. You are describing reality, not improving it.

State what to do when it goes wrong

Almost universally missing, and it is the reason people abandon the document. Procedures cover the happy path, the reader hits a case it does not describe, and they conclude the document does not cover their situation. Add the two or three most common deviations and where to go when none of it applies.

Keep it to one screen where you can

If a procedure does not fit on a screen, it is usually two procedures. Split them and link. Long documents get skimmed, and skimming a procedure is how steps get missed.

A structure that works

Not a template to fill in mechanically, but this order holds up:

1. Title as a task, not a topic. "Refunding an order" rather than "Refunds policy". People search for what they are trying to do.
2. When to use this, one line. Lets the reader confirm in two seconds that they are in the right document.
3. Who can do it. Roles and any limits, referencing your decision thresholds rather than restating them, so there is one source of truth.
4. The steps. Numbered, one decision each, naming what appears on screen.
5. When it goes wrong. Common deviations and the fallback.
6. Why, briefly. At the bottom. People follow procedures more reliably when they understand the reason, but not at the cost of finding the steps.

The maintenance problem

SOPs rot. The interface changes, the policy shifts, a step becomes unnecessary. A wrong procedure is worse than no procedure, because someone follows it and gets a bad result while doing exactly what they were told.

Scheduled reviews mostly do not happen, so rely on triggers instead:

• Someone follows it and hits a snag. They fix the document then, while they are in it. This requires that editing is genuinely easy and that nobody needs permission.
• A new person uses it. Their confusion is the best audit you will ever get, and it expires within a fortnight as they stop noticing what is unclear.
• Anything changes upstream. A policy change should include updating the document as part of the change, not as a follow-up task nobody picks up.

Put a "last checked" date at the top. Not "last edited", which software gives you anyway, but a human confirming it is still true. A procedure last verified fourteen months ago tells the reader to be careful.

An SOP nobody has verified in a year is a rumour with formatting.

What deserves an SOP, and what does not

Not everything should be documented. Writing procedures for things that do not need them buries the ones that do.

Worth documenting: tasks done rarely enough that nobody remembers them, tasks where mistakes are expensive or hard to reverse, tasks that only one person currently knows, and anything a new starter needs in their first week.

Not worth documenting: things people do daily, things obvious from the interface, and anything that changes so often the document will be wrong before it is read.

That third category is worth being honest about. If a process is genuinely in flux, a written procedure creates false confidence. Say "ask someone" until it stabilises.

Where it should live

Findability beats completeness. A partial procedure someone can reach in the moment is worth more than a thorough one in a drive nobody has bookmarked.

Practically: keep procedures where the team already works rather than in a separate system, make the title match what someone would search for, and link to them from the conversation when the question comes up. Answering "how do I do X" with a link rather than a retyped explanation is what teaches people the documents exist.

A worked example

The abstract advice is easier to apply against a concrete before and after. Take a returns procedure.

Before: "Returns Policy. Purpose: to ensure returns are handled consistently and in line with our customer service standards. Scope: applies to all returned items. Definitions: a return is any item sent back by a customer. Procedure: Upon receipt of a returned item, staff should assess the condition of the item and determine whether it is suitable for resale, then process the refund or exchange as appropriate in accordance with the returns window."

Everything in there is true and none of it helps the person holding a jumper on a Saturday.

After: Title it "Processing a return". First line: use this when a returned item physically arrives. Then the steps, numbered, one decision each. Find the order in Shopify by the order number on the slip. Check the item against what was ordered. If it is unworn with tags, click Refund and select the original payment method. If it is worn or damaged, stop and go to the damaged-items section below. If there is no slip and you cannot find the order, put it on the returns shelf and post in the room with a photo.

Same policy. The second one gets used, because every sentence tells someone what to do next and the sentence they need is the one they can find.

Note what the rewrite removed: purpose, scope, definitions. Not because those are worthless, but because they belong at the bottom under "why", where the reader who wants them can find them and the reader in a hurry never has to scroll past them.

Start with the three you actually need

The reason most documentation efforts stall is that they begin with an attempt to document everything, which is a project nobody finishes.

Write three. Choose them with this test: which questions have you personally answered more than twice this month? Those are your three, and they are almost always the same categories across stores. Something about returns, something about a specific product's handling, and something about what to do when an order is wrong.

Three short documents that answer the questions people actually ask will get used more than thirty thorough ones covering everything. And they build the habit: once people have looked something up successfully once, they will look again.

Add to the set only when a question comes up a third time. That rule keeps the library small enough to stay accurate, which matters more than coverage. A short set of documents people trust beats a comprehensive set they have learned to doubt.

Common questions