How to Write SOPs People Will Actually Follow: A Practical System

Most teams write SOPs backwards. Someone documents the process they already understand best, in the most detail, on the one quiet afternoon they had all quarter. Six weeks later nobody has opened the file, and the work still happens the way it always did: inside one person’s head.

A procedure people follow is a different object than a procedure people write. It is shorter. It names an owner. It says what to do when a step fails. It has a date on it. Here is how to build that with a blank spreadsheet, and where the spreadsheet stops being enough.

Why Most Procedures Get Opened Once and Never Again

There are four common failure modes, and all four are fixable.

• It is a narrative, not a procedure. Three paragraphs describing how invoicing „generally works.“ Nobody can execute a paragraph. Steps are numbered, start with a verb, and contain one action each.
• It has no owner. A document that belongs to everyone belongs to no one. When the billing tool changes its interface, nobody is responsible for the fact that step 4 is now wrong.
• It lives where the work does not. If the procedure is in a folder three clicks away from the tool it describes, it loses to memory every time.
• It was written for a stranger. Eleven pages of context for a task your team does weekly. Write for the person who will actually run it: a competent colleague on their second week, not an auditor from another planet.

The test is simple. Hand the document to someone who has never done the task and walk away. If they finish without asking you a question, it works. Every question they do ask is a defect — and the answer goes into the document, not into chat.

What to Do Before You Write SOPs

Do not document everything. Most teams stall because they tried to capture forty processes at once and finished none.

Score each candidate process on three axes, 1 to 3:

• Frequency. Yearly = 1. Monthly = 2. Weekly or more = 3.
• Cost of error. Internal annoyance = 1. Rework or a delay = 2. Customer-visible, money moving, or a contractual or regulatory obligation = 3.
• Bus factor. Anyone can do it = 1. Two people can = 2. Exactly one person can = 3.

The decision rule: a total of 7 or more gets documented this month. A 5 or 6 goes on the backlog with a date. A 4 or less stays undocumented, on purpose, and you stop feeling guilty about it.

One more sequencing rule that saves a lot of pain: document before you delegate, not after. Writing the steps is how you discover the three decisions you never actually defined.

The Seven Fields Every Procedure Needs

Whatever tool you use, each procedure carries the same seven fields. Anything else is optional.

1. ID and trigger. A stable ID (SOP-014) and the event that starts the work. „When a proposal is countersigned,“ not „onboarding.“
2. Owner. One named person. Not a team, not a role you have not filled.
3. Steps. Numbered, verb-first, one action each, with the tool named and the expected time.
4. Decision points and exceptions. The branches. „If the deposit has not cleared within 3 business days, pause at step 5 and notify the owner.“
5. Controls. The checks that catch a mistake before the customer does.
6. Training record. Who has been trained, on what version, on what date.
7. Version and review date. v1.2, last reviewed, next review due.

In a spreadsheet, that becomes two things. Sheet one is the index: one row per procedure with ID, name, owner, version, last reviewed, next review, and status (draft / active / retired). Sheet two onward is one sheet per procedure, with columns for step number, action, tool, who does it, expected time, and the exception note. The index is the part that keeps the system alive — it is the only page you look at during a monthly review.

A Worked Example: New Client Onboarding

SOP-014 — New Client Onboarding. Trigger: proposal countersigned in the e-signature tool. Owner: Dana (Ops). Version 1.3, last reviewed 12 Mar, next review 12 Jun.

1. Create the client folder from the template. Tool: shared drive. 2 min.
2. Issue the deposit invoice. Terms: net 7. Tool: accounting app. 5 min.
3. Send welcome email using template W-1, including the intake form link. 3 min.
4. Wait for intake form. Exception: no form after 3 business days, send reminder R-1; after 5, Dana calls.
5. Control gate: do not schedule kickoff until deposit has cleared and the intake form is complete. Both checks live in one column of the index.
6. Book kickoff within 5 business days of the gate clearing. 10 min.
7. Create the project board from the template and assign the delivery lead. 10 min.
8. Log the start date and the agreed scope reference in the client register. 3 min.

That is roughly 35 minutes of real work, and it is now transferable. Notice what earns its place: the gate at step 5 exists because someone once ran a kickoff for an unpaid client. Most good controls are scar tissue. Write them down as such, because that is how you stop a future teammate from quietly removing them.

Controls, Training, and Review Dates

A control is not a vibe check. Define three things for each one: what error it catches, who runs it, and what happens when it fails. „Manager reviews invoices“ is not a control. „Before sending, confirm the invoice total matches the signed scope; if it does not, return to step 2“ is.

Train in three passes. The trainee watches the owner do it once, does it once while the owner watches, then does it alone and reports back. Record the date and the version they trained on. When a procedure changes materially, that row expires and they need a five-minute re-read, not a whole session.

Set review dates by risk, not by calendar habit: 90 days for anything touching money or customer data, 180 days for standard operating work, 365 days for stable, low-stakes tasks. Add event triggers that override the schedule — a tool or pricing change, a customer complaint, an incident, or a new hire who could not follow the document. If you keep a running log of these reviews the way you would a maintenance record, the whole set stays trustworthy. There are more operations breakdowns like this one on the Cursiqa blog.

If You Draft With AI, Add a Named Human Review Step

AI is genuinely useful here: paste a messy transcript of yourself narrating a task and it will return clean numbered steps. What it cannot know is your actual thresholds, your tool names, who approves a refund, or which step exists because of a past mistake. It will fill those gaps confidently and plausibly, which is worse than leaving them blank.

So make the rule explicit in the document itself: AI may draft, the owner verifies. Verification means executing the procedure once, start to finish, against the draft. Then record it in the footer — „drafted with AI, verified by Dana, 12 Mar, v1.0.“ And do not paste customer records, credentials, or contract terms into a tool whose data handling you have not checked.

Where a Spreadsheet Stops Being Enough

Be honest about the ceiling. A spreadsheet handles roughly two to three dozen active procedures for a small team, and it handles them well. Past that, you will hit real limits:

• You need a per-step sign-off trail that proves who did what on which date.
• Several people edit at once and version numbers start disagreeing.
• You need screenshots, short screen recordings, or permissions per procedure.
• A contract, insurer, or regulator wants evidence, not a claim.
• Procedures need to hand off between people automatically, with reminders.

When two or more of those are true, move the procedure bodies into a wiki or a process tool with real version history and permissions — but keep the index. The index is the map, and it stays useful wherever the content lives.

Your First Week

1. List every repeatable process you can think of in ten minutes. Do not filter.
2. Score each one on frequency, cost of error, and bus factor.
3. Take the single highest score and nothing else.
4. Record yourself doing it once, narrating. Turn that into numbered steps.
5. Add an owner, one control, a version number, and a review date.
6. Hand it to a colleague and let them run it while you stay silent. Fix every question they ask.

One procedure that someone else can run beats twelve that only you understand.

If you would rather start from a structured index, step templates, and a review log than build the sheets yourself, the SOP Builder & Process Documentation Kit is set up for exactly this workflow, and the rest of the operational workbooks are in the Cursiqa shop. Either way, write the first procedure this week — the format matters far less than getting one out of your head.