AI for writing standard operating procedures people follow

5 days ago
3 min read

Updated: 2 days ago

Introduction

Documentation is the constraint on delegation. An owner cannot hand over a task that exists only in their head, so they keep doing it, and the business stays the size of one person's attention. Everybody knows this and almost nobody writes procedures, for a simple reason: writing the first draft of a procedure is unpleasant, slow work that produces no immediate benefit.

Removing the blank page changes the calculation. Describing a process out loud for five minutes and receiving a structured draft to correct is a different task from writing one from nothing, and correction is substantially faster than composition. That is the whole of the opportunity here, and it is larger than it sounds because the alternative is that nothing gets written at all.

1. AI for writing standard operating procedures works by removing the blank page

Correction beats composition.

Talk through the process, get a structured draft, then fix what is wrong. Most people can correct a reasonable draft in fifteen minutes and would never have written the same document from scratch.

2. Document the processes that hurt when someone is away

Priority by risk.

Not everything needs a procedure. Start with the tasks only one person can do, the ones with expensive failure modes, and the ones new staff always get wrong. That is three to five documents, not thirty.

3. Have the person who does the work review it

Non-negotiable for accuracy.

A generated procedure will be plausible and will miss the specifics that matter: the setting on that machine, the customer who needs a call first, the step that must not be skipped. Only the practitioner knows these.

4. Write for the person who will do it next

Not for the person who already knows.

Include what to do when it goes wrong, who to ask, what a good result looks like, and the reason for any step that seems unnecessary. Steps without reasons get dropped by the next person.

5. Keep them short

Length is the enemy of use.

A single page that is read is worth more than eight pages that are filed. If a procedure needs more than a page, it is probably several procedures, or it is a training matter rather than a procedure.

6. Put a date and an owner on every one

The maintenance minimum.

An undated procedure with no owner is out of date within a year and nobody notices. A named owner and a review date make the decay visible, and visible decay gets fixed.

7. Store them where the work happens

Access determines use.

At the machine, in the job file, linked from the system people already use. A procedure library nobody navigates to is not documentation; it is a compliance artefact.

8. Use them for training and check they work

The test of a procedure.

Give it to a competent person who has not done the task and see whether they can complete it. Every point where they have to ask a question is a gap, and this is the only reliable way to find them.

9. Update them when something goes wrong

The improvement loop.

After any error or near miss, the question is whether the procedure was wrong, missing or ignored. Each of those has a different fix, and the procedure should change accordingly.

Where a procedure covers a regulated activity, safety-critical work or a statutory obligation, it needs review by someone competent in that area. A generated draft is a starting point rather than a compliant document, and the requirements differ by sector and jurisdiction.

Conclusion

Use drafting help to remove the blank page, because that is the reason the documentation does not exist.

Prioritise the tasks only one person can do and the ones with expensive failure modes, have the practitioner review every draft for the specifics that matter, write for the next person including what to do when it goes wrong, keep each one to a page, put a date and a named owner on it, store it where the work is done, test it by giving it to someone who has not done the task, and update it after every error or near miss.