Standard operating procedure: writing one people actually follow

A standard operating procedure is a written description of how a recurring task is done, precise enough that two people following it produce the same result. That is the whole definition, and the whole difficulty: precise enough. Too vague and it is a mission statement; too detailed and nobody reads past step four.

The honest reason to write one is repetition with consequences. If the task happens weekly, if getting it wrong costs money or safety or a customer, and if more than one person does it, it deserves a procedure. Everything else deserves a note, or nothing at all.

What a standard operating procedure contains

• A title that names the task as the person doing it would name it — "Closing the shop", not "End-of-day operational protocol".
• Scope and trigger: when this procedure applies, and what starts it.
• The role responsible, not a person's name. Names go out of date faster than procedures do.
• Anything needed before starting: access, tools, materials, prior steps.
• The steps themselves, numbered, one action each, in the imperative.
• Decision points written as conditions — "if the reading is above X, stop and call Y" — rather than buried in prose.
• What done looks like, so the person can check themselves rather than asking.
• Version, date, owner, and the next review date. A procedure with no review date is a procedure nobody is accountable for.

Write for the least experienced person who will ever legitimately do this task, not for the author. The most common failure in procedures is assumed knowledge: a step that says "reconcile the batch" to someone who has never been told what a batch is. If a step needs a definition, the definition belongs in the procedure, not in somebody's head.

How to write one that survives

1. Watch the task being done once, by someone who does it well, and write down what actually happens rather than what should.
2. Draft the steps in the imperative, one action per step. If a step has an "and" in it, it is probably two steps.
3. Cut every sentence that explains why, and put the why in a short paragraph at the top. Mixed rationale and instruction is what makes procedures skimmed rather than followed.
4. Add screenshots or photographs only where words genuinely fail — an interface, a physical setup, a correct-versus-wrong comparison.
5. Have someone who has never done the task follow the draft while you watch, without helping. Every question they ask is a missing step.
6. Set an owner and a review date before publishing, not after.
7. Publish it where the work happens. A procedure two clicks from the task gets used; one in a folder nobody opens does not.

SOP, work instruction, policy: keep them separate

A policy says what must be true — "customer data is never emailed unencrypted". A standard operating procedure says how a task is carried out, end to end. A work instruction goes one level down, covering a single operation in detail for the person performing it. Mixing the three produces a document that is too abstract to follow and too specific to approve. Write the policy once, the procedures per task, the work instructions where the detail genuinely matters.

Keeping procedures current

Every procedure decays, and an out-of-date one is worse than none: it teaches people that the written version is unreliable, and after that they stop looking. Two habits keep the set honest. Give each procedure a review date and treat a missed review as a defect. And make correcting one cheap — anyone who follows a procedure and finds it wrong should be able to comment on it in place rather than mentioning it in passing.

In Ettex, the natural home for this is Ettex Docs: write the procedure, and use threaded comments so the person who found step six wrong can say so against step six, with @mentions to whoever owns it. Version history means you can see what changed and return to any earlier state, so a bad edit is recoverable and an argument about what the procedure used to say is settled by looking. Share links let you point at the procedure from wherever the work happens. Anything that must be signed off — a safety procedure, a regulated one — can go on to Ettex Signature for a real signature with an audit trail, and forms that a procedure tells people to fill in fit Ettex Forms, where submissions land timestamped in one inbox.

What Ettex does not do: there is no SOP module, no library of ready-made procedure templates, no automatic review reminders, and no approval routing between named reviewers. The review date is something you put in the document and diary yourself. If you operate under a standard that demands controlled documents with enforced periodic review and audit-ready approval trails, use a dedicated document-control system.

Why procedures go unread

• Written for the auditor rather than the operator, in language nobody speaks.
• Too long. Anything past two pages for a routine task is being skimmed at best.
• Stored somewhere that requires knowing it exists to find it.
• No owner, so nobody updates it when the tool or the rule changes.
• Rationale and instruction interleaved, so the steps have to be excavated.
• Never tested on a newcomer, which means the gaps are invisible until they cost something.

A standard operating procedure earns its place when a newcomer can follow it without asking anyone. Write from observation, one action per step, name an owner and a review date — and keep it where the work is, not where the documents are.