How to Write SOPs and Process Documentation You Will Actually Use

Most SOPs are written once, filed in a folder nobody opens, and quietly go stale within a quarter. The problem is rarely laziness. It is that people write documentation the way they were taught to write essays: comprehensive, cautious, complete. That produces a 2,400-word document describing a task that takes eleven minutes, and nobody reads it twice.

This article is about the other approach. Short documents, written at the moment of doing, stored where the work happens, and maintained by the person who uses them. It covers what to document first, the exact template, how to use recording and AI to cut writing time, and how to stop your documentation rotting.

The direct answer

A usable SOP is one page, written in second person, made of numbered steps that each start with a verb. It names one owner, one trigger, and one definition of done. You produce it by recording yourself doing the task while narrating, transcribing the recording, and editing the transcript into steps — not by writing from memory. You store it attached to the task it describes, not in a separate documentation library. And you fix it the moment somebody follows it and hits a wrong step.

If you do only one thing from this article: next time you do a repeating task, hit record. The recording is the raw material. Everything else is editing.

Why most process documentation fails

Four failure modes, in rough order of how often they show up.

It was written from memory. You sit down away from the work and try to recall the steps. You skip the things your hands do automatically — which tab, which filter, which of the three similarly named folders. Those gaps are exactly where a new person stalls.

It describes the ideal, not the actual. People write what the process should be, including the quality checks nobody has ever done. The reader tries it, notices the document is aspirational, and stops trusting it. One wrong step poisons the whole document.

It is too long to scan. A wall of prose cannot be followed while working. If the reader has to hold three paragraphs in their head to perform one action, they will do the task from memory instead and the document is decoration.

Nobody owns it. No name, no date. When it goes wrong, the reader assumes someone else will fix it. Nobody does.

There is a fifth, subtler one: the business documented everything at once during a burst of enthusiasm, produced 40 documents in a fortnight, and now cannot maintain any of them. Volume is not the goal. Coverage of the expensive parts is.

What to document first

Do not start with an inventory of everything you do. Start with a scoring pass. Score every recurring task on three axes, one to five.

Multiply the three. Anything scoring 40 or above gets documented this month. Anything under 15 does not get documented at all until it causes a problem — the maintenance cost outweighs the benefit.

This scoring is deliberately crude. Its job is to stop you documenting the annual tax-package handover (frequency 1) before the daily quote follow-up (frequency 5, delegation 5, cost of error 4 = 100).

A typical services business ends up with a first list that looks something like this:

1. Responding to an inbound enquiry
2. Producing and sending a quote
3. Onboarding a new client
4. The weekly invoicing run
5. Chasing an overdue invoice
6. Publishing a piece of content or a listing
7. Handling a complaint or refund
8. Closing out a job and asking for a review

Eight documents. That is a realistic first pass, and it covers most of where money leaks. The same prioritisation logic drives what to automate first — and that is not a coincidence. A documented process is the prerequisite for automating it. You cannot hand a process to software, or to an AI assistant, if you cannot state it in steps.

The one-page template

Use the same structure every time. Consistency matters more than cleverness — a reader who knows where the "when this goes wrong" section always sits will find it in two seconds.

# [Verb + object: "Send a quote"]

Owner: [name]
Last updated: [date]
Trigger: [the specific event that starts this]
Done when: [the observable end state]
Time: [realistic minutes]
Tools: [the exact apps, with links]

## Steps
1. [Verb first. One action. Where needed, the exact button or field name.]
2. ...

## Decisions
- If [condition], then [action].
- If [condition], escalate to [name].

## When it goes wrong
- [Known failure] → [what to do]

## Notes
[Anything that does not fit above. Keep it short or move it out.]

Six fields at the top, four sections. Nothing deeper. Every part of it earns its place:

• Trigger stops the reader wondering whether this SOP applies. "A form submission lands in the enquiries inbox" is a trigger. "When needed" is not.
• Done when is the single most-skipped field and the most valuable. Without it, delegated work comes back at 80% and you finish it yourself. "Quote PDF sent, opportunity moved to Sent, follow-up task created for +3 days" is a definition of done.
• Time sets expectation. If the SOP says 10 minutes and it is taking someone 40, that surfaces a problem — either the document is wrong or the person needs help. Both are worth knowing.
• Decisions is where judgement lives. Pulling the if/then branches out of the numbered steps keeps the happy path readable. If your Decisions section is longer than your Steps section, you are documenting a judgement call, not a procedure — write it as a decision guide instead, with principles and examples.

Write steps that survive contact with a new person

The difference between a followed SOP and an ignored one is usually granularity. Some rules that hold up.

Start every step with a verb. "Open", "Copy", "Check", "Send". Not "The invoice should then be checked."

One action per step. If a step contains "and then", split it.

Name the exact thing. Not "go to the settings" but "open Settings → Billing → Payment methods". Not "use the template" but "use the template named Quote — standard v3".

Write the search string, not the location. File locations move; searches survive. "Search Drive for quote-template-standard" beats "it's in the Templates folder inside Sales."

Say what "good" looks like at the checkpoint. "The total should match the line items and include GST" tells the reader how to catch their own mistake.

Use screenshots only where the interface is genuinely confusing. Screenshots are the highest-maintenance part of any document — one product redesign and they are all wrong. A well-named button beats a screenshot in most cases. Where you do need one, annotate with a single arrow or box and nothing else.

Do not explain why in the middle of a step. Reasons belong in Notes, or in one italic line under the step. Steps are for doing.

Here is the same instruction written badly and then well.

The strong versions are longer. That is fine. Length per step is not the problem; total document length is.

Record first, write second

This is the single biggest time-saver and most people have not tried it.

Do not write the SOP. Do the task, record it, and edit the recording into a document. The recording captures the steps your memory omits, because you cannot skip a click you actually make.

The process:

1. Pick a real instance of the task. Not a demo. A real quote, a real onboarding, a real invoice run.
2. Start a screen recording with your microphone on. Loom, Scribe, or the recorder built into your video tool — anything that captures screen and voice. Scribe and similar tools will additionally auto-generate a click-by-click guide with screenshots, which is worth it for interface-heavy tasks.
3. Narrate as you go. Say what you are doing and why, including the parts you would normally do silently. "I'm filtering by status Open because the closed ones are archived weekly."
4. Do not restart when you fumble. Fumbles are useful. If you had to backtrack, that is a real branch in the process and belongs in the document.
5. Stop at the definition of done. Then say it out loud: "Done means the quote is sent and the follow-up task exists."
6. Get the transcript. Most recording tools produce one automatically.
7. Turn the transcript into the template — by hand, or with an AI assistant, which is the next section.
8. Keep the video and link it from the SOP. Text for following, video for the first time someone learns it.

A 10 to 15 minute recording is the sweet spot. Longer than 20 minutes and you are recording two processes; split them.

The one thing to watch: recordings contain whatever is on your screen. Close the inbox, hide the customer list, blur or skip anything with personal data in it before you share the file. If the task genuinely requires working on real customer records, use a test record or your own details.

Using AI to do the boring 80%

AI assistants are genuinely good at this specific job — turning a rambling transcript into structured steps — because the source material is all there and the task is reformatting rather than invention. This is one of the higher-return uses of AI in a small business, and it sits alongside the other practical applications in how to use AI in a small business.

A prompt that works:

Below is a transcript of me narrating a task I do regularly.
Turn it into a one-page SOP using exactly this structure:

Title (verb + object), Owner, Trigger, Done when, Time, Tools,
## Steps (numbered, each starting with a verb, one action each)
## Decisions (if/then)
## When it goes wrong

Rules:
- Use only what is in the transcript. Do not add steps I did not do.
- Where I was vague or skipped something, add a line under
  "## Gaps to confirm" quoting what I said. Do not guess the answer.
- Write in second person. Keep the whole thing under 400 words.
- Name exact buttons, fields and file names as I said them.

Transcript:
[paste]

The "Gaps to confirm" instruction is the important one. Without it, the model fills holes with plausible generic steps, and plausible-but-wrong is worse than obviously missing. With it, you get a short list of exactly what to go back and check.

What AI does well here, and what it does not:

Two warnings worth taking seriously. First, always read the output against the recording. Models smooth over inconsistencies, and a smoothed-over step can be quietly wrong. Second, do not paste customer data, contract terms or credentials into a general AI tool unless you have checked your provider's data handling and your own obligations. Check the specific tool's terms and your local privacy rules — they differ by country and by plan tier, and neither we nor an AI assistant can tell you what applies to your business.

Where to store them

The rule: an SOP should be reachable from inside the task, not from a documentation homepage. Every extra navigation step is a chance for the reader to give up and wing it.

Three practical rules regardless of tool:

1. One canonical link per process. If two versions exist, one is wrong and you will not know which. Delete, do not archive-and-forget.
2. Name by the verb. "Send a quote", not "Quoting process v2 FINAL". People search for what they are trying to do.
3. Keep an index. One page listing every SOP, its owner and its last-updated date. This page is how you spot rot at a glance.

Tool choice matters far less than people think. A strict Google Docs folder that everyone actually uses beats a beautiful Notion system nobody has permission to edit.

Keeping them alive

Documentation rots. Plan for it rather than being surprised.

The five-minute rule. Whoever follows an SOP and finds it wrong fixes it right then, in under five minutes. Not a ticket, not a message to you. Give everyone edit access. The alternative — a review queue — means errors persist for weeks and readers learn the document is untrustworthy.

Date and owner on every document. An SOP last updated 14 months ago with no owner is a liability. The reader cannot tell if it is stale, so they hedge, so they ask you, so the documentation saved nothing.

A six-month sweep. Twice a year, open the index and check anything untouched in six months. Ten minutes each. Most need one line changed; some need deleting because the process no longer exists. Deleting is a success, not a failure.

Trigger events that force a review. Any of these should prompt an immediate check of the affected SOPs:

• You change a tool in the stack
• A price, fee or turnaround time changes
• Somebody new does the task for the first time
• The same mistake happens twice
• A rule that affects you changes — tax rate, licensing, platform policy

Let new people rewrite. The most valuable edit any SOP gets is from the person following it for the first time. They see the gaps you cannot. Make it an explicit part of onboarding: follow this document, then rewrite it in your own words.

SOPs, checklists and decision guides are different things

Using one format for all three is why documents get bloated. Match the format to the work.

A common mistake: writing a 1,500-word SOP for something that is genuinely a five-item checklist. Another: writing a checklist for something requiring judgement, which produces mechanical decisions and unhappy customers.

If you want a worked example of the checklist format applied end to end, the business launch checklist is that shape — sequenced, binary, scannable.

A realistic first sprint

Here is how to get from nothing to a working set. Two weeks, part-time, one person.

Realistic effort: roughly 8 to 12 hours total for eight SOPs if you record rather than write. Writing them from memory instead typically takes two to three times as long and produces worse documents, because memory-written SOPs skip the automatic steps.

Day 9 to 10 is the part people skip, and it is the part that tells you whether any of this worked. Sit silently while someone else follows the document. Every question they ask is a defect. Write each one down and fix it. If you are documenting the early sales process, this is the same discipline as watching a real prospect move through your funnel rather than assuming — the approach in idea to first customer applies to internal processes too.

If you would rather work from a ready-made template pack and a filled-in example than start from a blank page, our $10 guides include exactly that kind of thing.

What good looks like, measured

You cannot easily measure documentation quality directly, but three proxies work well.

1. Questions per handoff. Count the questions a person asks while doing a documented task for the first time. Falling toward zero over successive handoffs means the document is improving. Rising means it is rotting.
2. Time to first competent run. How long from "here is the document" to the person completing the task correctly without help. Track it for the first three people. If it is not falling, the document is not the bottleneck — the process is.
3. Rework rate. How often the output has to be redone. A good "Done when" line drops this fast, because most rework comes from mismatched expectations rather than incompetence.

None of these need a tool. A note in a spreadsheet is enough. The point is to notice direction, not to build a dashboard.

Common mistakes and the fix

That last one deserves its own sentence. If a process is bad, writing it down makes it permanent. Before documenting anything, ask whether the process should exist at all. Plenty of recurring tasks survive only because nobody has questioned them since the business was set up. Documenting a task you should delete is the most expensive kind of busywork — and once the process is clean, what to automate first is the natural next question.

The short version

• Score tasks on frequency, delegation and cost of error. Document the top 6 to 8 first, not everything.
• Record yourself doing the task and edit the transcript. Writing from memory takes longer and skips the steps your hands do automatically.
• One page, second person, verb-first numbered steps, plus Trigger, Done when, Owner and a date. "Done when" is the field that stops work coming back at 80%.
• Store the SOP inside the task it describes, not in a separate documentation library nobody opens.
• Use AI to convert transcripts into structure and to flag gaps — not to invent steps, prices or policies it has never seen you use.
• Test each document by watching someone follow it cold. Every question they ask is a defect. Fix it in five minutes, not in a review queue.

The SOP Writing Kit turns this into something you fill in: the one-page SOP template with Trigger, Done when and Owner already laid out, the recording-and-transcript method that writes your first draft for you, the scoring sheet for deciding which six to eight tasks to document first, and the cold-read test script for finding the defects before a new hire does.