SOPs your team will use: the one-page format

To write an SOP your team will use instead of ignore, keep it to one page and answer five questions in order: what triggers this process, who owns it, what are the exact steps, what does done look like, and who to ask when something breaks. Most SOPs fail because they read like a training manual nobody opens twice. A one-page SOP reads like a checklist someone can run at 4pm on a busy Friday. Write for that moment, not for a shelf.

Why do most SOPs get ignored?

Because they were written to impress, not to be used. Ten pages of background, a glossary, a flowchart, and by the time the reader finds the actual steps they have given up and messaged you instead. That message is the tell. If people still ask you how to do the thing after you documented it, the document is too long or too vague.

The other failure is the opposite: a note so thin it only makes sense to the person who wrote it. "Send the usual welcome email" means nothing to a new hire who has never seen the usual welcome email.

A good SOP sits between those two. Enough to run the process cold, nothing more. One page forces that discipline, which is why it works better than any template with a fancy header.

What goes in a one-page SOP?

Five parts, in this order. Skip any of them and the SOP starts generating questions instead of answering them.

The two parts people forget are the first and the last. Without a clear trigger, the SOP sits unused because nobody is sure when it applies. Without an escalation line, the first weird edge case ends with someone freezing or pinging you at 9pm. Name the trigger and name the fallback, and the SOP can run without you in the room.

Keep the steps at the right altitude

The most common mistake is writing steps for a robot. You do not need "open your browser" and "click the address bar." Your reader is a capable adult. Write steps a competent new team member could follow, not steps a machine could parse. If a step needs a screenshot to be clear, add the screenshot instead of ten more words.

How do you write an SOP fast without it being sloppy?

Record yourself doing the process once, then turn the transcript into the format above. This is the same capture step behind any good system, and if you want the full loop around it, business systems 101 covers where SOPs fit in the bigger picture.

Do not write the SOP from memory. Memory skips the small steps you do on autopilot, and those skipped steps are exactly what trip up whoever inherits the process. Record the real thing, hesitations and detours included, then trim.

Here is a prompt that turns a rough screen-recording transcript into a first-draft one-page SOP. Paste your transcript where marked.

You are my operations documentation assistant. Below is a raw transcript of me narrating myself doing a business process on a screen recording. It is messy and includes tangents.

Turn it into a one-page SOP with exactly these five sections:
1. Trigger (the specific event that starts this process)
2. Owner (leave a bracket for me to name the role)
3. Steps (numbered, each starting with a verb, in order, no filler)
4. Done looks like (the visible proof it finished correctly)
5. Escalation (leave a bracket for who to ask when a step breaks)

Cut anything that is not a real step. Keep it under 400 words. Flag any step where I was unclear so I can fix it.

Transcript:
[paste your transcript here]

The draft it gives back is not final. Read it, fix the flagged gaps, name the owner and escalation contact. But you go from blank page to editable draft in about ten minutes instead of avoiding the task for three weeks. If you would rather start from proven versions, the 100+ templates inside the WorkSmart OS include onboarding, delivery, and invoicing SOPs you can adapt instead of building from scratch.

Worked example: an SOP that finally stuck

A marketing consultant I'll call Dana runs a $290K shop with one full-time coordinator. Her client reporting process lived entirely in her head. Every month she rebuilt each report by memory, and when she tried to hand it off, her first SOP was a four-page document the coordinator stopped using after two tries.

She rewrote it in the one-page format. Trigger: the first business day of the month. Owner: the coordinator. Seven numbered steps. Done looks like: a report in the shared folder and a draft email in Dana's drafts for approval. Escalation: if a client's data is missing, message Dana with the client name before pulling the rest.

The difference was not effort, it was shape.

The coordinator ran the new version the first month with zero questions. Those are Dana's numbers, and the reason is boring: the page matched how the work happens.

An SOP nobody reads is just a confession that the process still lives in your head.

How do you keep an SOP from going stale?

Give it an owner and a review date, same as any system. The owner runs it. Once a month you ask them one question: what did you have to work around this time? A workaround is the SOP telling you it is wrong. Fix the page the day something changes, whether that is a price, a tool, or a step. An SOP that is 80% accurate gets abandoned, because the person running it stops trusting it and goes back to asking you.

Deciding which processes deserve an SOP first is its own question. If you are staring at a long list, what to delegate first gives you the order to work in.

Do this next

Pick the one process people ask you about most, hit record, and narrate yourself doing it once today. Run that transcript through the prompt above and you have a draft one-page SOP before lunch. The WorkSmart OS carries you the rest of the way with ready-made SOP templates and monthly calls where you can pressure-test what to document next.