Write a standard operating procedure
An SOP is a document that lets a competent person who has not done this before do it correctly, without asking. That is the whole test. If they still have to ask, it is not finished.
Most SOPs fail the test in the same way: they describe the process from the perspective of someone who already knows it. They say “process the order” to a reader whose only question is what “process” means.
Before writing
Establish who reads this. A new hire on day three, an experienced person doing an unfamiliar task, and a contractor covering leave need different documents. Ask. The answer changes how much you explain.
Establish when they read it. An SOP read once during training is a different artefact from one held in one hand while the other does the work. The second must be scannable, numbered and short.
Establish where the knowledge is. Usually in one person’s head, and they are busy. See references/from-an-interview.md for extracting a process from someone who has never written it down, which is the most common way an SOP actually gets made.
The structure
Use this. It is boring on purpose, because a reader who knows the shape can find what they need in any of them.
1. Purpose why this exists, in one or two sentences
2. Scope when this applies, and when it does not
3. Roles who does what
4. Prerequisites access, tools, information needed before starting
5. Procedure the numbered steps
6. Exceptions what to do when it does not go to plan
7. Definitions terms and codes a new person would not know
8. Revision version, owner, last reviewed
Sections 2, 4 and 6 are the ones people leave out, and they are the ones that cause the questions.
- Scope stops the SOP being applied to a situation it was never written for
- Prerequisites stop somebody getting to step 4 and discovering they need access they do not have
- Exceptions are where the real knowledge lives. Anyone can write the happy path
Full detail on each in references/structure.md. A copy ready template is at assets/sop-template.md.
Writing the steps
One action per step. If a step contains “and”, consider splitting it.
Start with a verb. “Open the job in ServiceM8.” Not “The job should be opened.”
Say exactly where. “In ServiceM8, go to Forms” beats “navigate to the forms area”. Name the menu, the button, the field.
Put the decision in the step, not after it. When a step branches, say so in the step:
6. Check whether the customer has an account.
- Account holder: go to step 7
- No account: go to step 12
Give the check, not just the action. “Save the record” is an instruction. “Save the record. The job number appears at the top of the page. If it does not, the save failed” is a step someone can follow alone, which is the point.
Name the thing they will actually see. If the button says “Submit for approval”, write “Submit for approval”, not “submit it for approval”. Quote the interface.
State the numbers. Not “wait a while”, but “wait two minutes”. Not “if it is a large order”, but “if the order is over $5,000”. Every vague quantity is a decision you have handed back to the reader.
Length
As short as it can be and still pass the test.
If the procedure runs past about fifteen steps, it is probably two procedures. Split it and link them. Long SOPs do not get read, and an SOP that is not read has negative value: the business believes the process is documented when in practice it is not.
Move background, policy and reference material out of the steps and into an appendix or a separate document. The steps should be steps.
What kills an SOP
| Problem | Looks like | Fix |
|---|---|---|
| Written for someone who already knows | ”Process as usual” | Write it for day three |
| Passive voice hiding the actor | ”The form is then reviewed” | Say who reviews it |
| No exception handling | Only the happy path | Ask “what if this fails” at every step |
| Screenshots that go stale | An interface from two versions ago | Describe in words, screenshot only where words fail |
| No owner | Nobody’s name on it | Name a person, not a department |
| Never reviewed | Last updated three years ago | Put a review date in and honour it |
| Too long | Fifteen pages | Split it |
Reviewing an existing one
Ask three questions:
- Could someone follow this without asking? Best tested by having someone actually do it. Second best: read it as though you know nothing and mark every point where you would need to ask
- Is it still true? Systems change and SOPs do not follow. Check every named button, field and system
- Is it being used? An SOP nobody opens is either wrong, unfindable, or covers something that does not need documenting. All three are worth knowing
Keeping it alive
- One named owner. A person, not “Operations”
- A review date, honoured. Annually at minimum, and immediately after the process changes
- A version and a date on the document
- One findable place. An SOP nobody can find is not an SOP
- Update it when the process changes, not later. Later never arrives, and a wrong SOP is worse than none because it is followed
Reference files
Everything the skill tells your AI to read, exactly as it ships in the zip.
references/from-an-interview.md 3.7 KB
# Getting the process out of someone's head
Most procedures worth documenting exist only in one person's head, that person is the busiest in the business, and they have never written it down because they do not experience it as a process. They experience it as "what you do".
This is how to extract it without a two hour meeting.
## Do not ask them to describe the process
"Can you talk me through how you do X" produces a summary. Summaries skip exactly the parts that need documenting, because the expert has stopped noticing them.
You will get: "I check the job, make sure it is all there, then invoice it." Three steps, twenty minutes of real work, and every decision invisible.
## Ask about the last time instead
"Walk me through the last one you did. What did you open first?"
A specific instance produces specifics. It surfaces the incidental detail that is actually the procedure: which screen, which field, what they looked at before deciding, what they did when it was not right.
Follow the thread with mechanical questions:
- "Then what?"
- "What did you look at to decide that?"
- "What would you have done if that had been empty?"
- "How did you know it worked?"
## Ask the four questions that find the real knowledge
1. **"What goes wrong most often?"** This produces the exceptions section, which is where the value is
2. **"What do new people always get wrong?"** These become the notes and the checks. They are the steps that look simple and are not
3. **"When would you do this differently?"** This is scope, and it stops the SOP being misapplied
4. **"Who do you ask when you are not sure?"** This is the escalation path, and it is usually a person nobody has written down
## Watch for the invisible steps
Experts skip steps they no longer notice. Three things reliably go missing:
- **Checks.** They glance at something before continuing. Ask what they are looking for
- **Judgement calls.** "It depends" is a decision with criteria behind it. Push until you get the criteria, even approximate ones
- **Setup.** Access they already have, a screen they always have open, a file they keep
When a step seems too small to write down, that is usually the one a new person will fail at.
## Use a recording or transcript if you have one
If the conversation happened on a call and there is a transcript, work from it. The value is that people say things in a walkthrough they would never write down: the aside about the system being slow on Mondays, the offhand mention of who to call.
Pull out: every action in order, every decision point, every number mentioned, every named system or field, and every "except when".
Then write it up and give it back to them.
## Give it back and watch them read it
The draft is not the document. Two rounds are usually enough:
**Round one, with the expert.** They will find the things you got wrong and, more usefully, the things you left out. The prompt that works: "Read this as though you have to do it tomorrow. Where would you get stuck?"
**Round two, with someone who has never done it.** Ideally have them actually do the task with only the document. Every question they ask is a defect. Do not answer it verbally, fix the document.
That second round is the one people skip and it is the one that finds the real gaps, because the expert cannot un know what they know.
## Turning it around fast
The realistic version of this, for a busy business:
1. A fifteen minute conversation, recorded
2. You draft, same day
3. They read it, five minutes, mark it up
4. You fix it
5. The next person to do the task uses it and reports every place they got stuck
6. You fix it again
That is under an hour of the expert's time for a document that survives them leaving. Framing it that way is usually what gets the fifteen minutes booked.
references/structure.md 4.2 KB
# The eight sections, and what belongs in each
## 1. Purpose
One or two sentences: what this achieves, and what goes wrong without it.
The second half is what makes people follow it. "Ensures accurate invoicing" is a policy statement nobody reads. "Jobs that sit uninvoiced get forgotten, and after a month the detail needed to invoice them accurately is gone" tells the reader why the two day rule in step 1 exists, which is the difference between a rule followed and a rule worked around.
Do not write a purpose that restates the title.
## 2. Scope
When this procedure applies, and explicitly when it does not.
The negative half is the valuable half. Most process failures are not people doing the steps wrong, they are people applying the right procedure to the wrong situation. "Do not use this for warranty jobs, use [other procedure]" prevents a whole class of error and costs one line.
Also state any thresholds: applies to orders under $10,000, applies to domestic customers only. A threshold in the scope is a decision the reader does not have to make.
## 3. Roles
Roles, never people's names. A named person leaves and the SOP is wrong. A role survives.
Keep it to who acts in this procedure. This is not an org chart.
Where an approval is involved, say who approves and what happens if they are unavailable. Unavailable approvers are the single most common reason a documented process stalls, and almost no SOP addresses it.
## 4. Prerequisites
Everything needed before step 1, in three groups:
**Access.** The system and the permission level. "ServiceM8 access" is not enough if the procedure needs `manage_forms`. Say which.
**Information.** What has to be in front of them: the job number, the signed quote, the supplier invoice.
**Tools.** Software, hardware, physical equipment.
This section exists to prevent the worst failure mode in any procedure: getting six steps in, discovering you cannot proceed, and abandoning it half done. Half done is worse than not started, because now the system holds a partial record.
## 5. Procedure
The numbered steps. Covered in the main skill body. The rules that matter most:
- One action per step
- Start with a verb
- Name the exact interface elements
- Put branches inside the step that causes them
- Give a check after any step where failure is silent
- Replace every vague quantity with a number
Add a check specifically where the system will not tell you it failed. A save that silently does nothing, an email that goes to spam, a sync that runs overnight. Those are the steps where a reader needs to know what success looks like.
## 6. Exceptions
The section that separates a real SOP from a description.
Get it by asking, at each step: what goes wrong here, and what does the experienced person do about it. The answers are in one person's head and nowhere else, and they are the actual reason that person is hard to replace.
Format as a table: condition, response, who to escalate to.
Always include a final row for the unanticipated: "Something you have not seen before: stop, do not improvise, escalate to [role]". Explicit permission to stop is worth a great deal. Without it, people guess, and a guess in a process they do not understand is how small problems become large ones.
## 7. Definitions
Every term, code and abbreviation a new person would not know.
The hard part is noticing your own jargon. Internal words stop looking like words after a few months: a status name, an abbreviation for a customer type, a nickname for a system. A useful test is to read the SOP aloud to someone from a different part of the business and watch for the moment they stop tracking.
Include internal codes and their meanings. A step that says "code it to 6-1400" is useless without a line saying what 6-1400 is.
## 8. Revision
Version, owner, last reviewed, next review, and a change history.
The change history matters more than it looks. When someone asks why the process changed, the history answers it, and without it the SOP gets argued with instead of followed.
Set the next review date to a real date and put it in a calendar. A review date that passes unnoticed is the same as no review date, and an SOP that quietly went out of date is worse than none because people still follow it.
assets/sop-template.md 3.0 KB
# [Procedure name]
Name it as the task, starting with a verb: "Onboard a new client", "Close out a completed job", "Process a supplier invoice". Not "Client onboarding process".
| | |
|---|---|
| **Owner** | [A person's name, not a department] |
| **Version** | [1.0] |
| **Last reviewed** | [Date] |
| **Next review** | [Date] |
| **Applies to** | [Which roles] |
---
## 1. Purpose
One or two sentences. Why this procedure exists and what goes wrong without it.
> Example: Makes sure every completed job is invoiced within two working days. Jobs that sit uninvoiced get forgotten, and after a month the detail needed to invoice them accurately is gone.
## 2. Scope
When this applies.
**Use this procedure when:**
- [Situation]
- [Situation]
**Do not use it when:**
- [Situation, and what to use instead]
## 3. Roles
Who does what. Name roles, not people, so it survives someone leaving.
| Role | Responsibility |
|---|---|
| [Role] | [What they do in this procedure] |
| [Role] | [What they do] |
## 4. Prerequisites
Everything needed before starting. This section prevents someone getting to step 6 and discovering they cannot proceed.
**Access:**
- [System, and the permission level needed]
**Information:**
- [What they need in front of them]
**Tools:**
- [Anything physical or software]
## 5. Procedure
One action per step. Start each with a verb. Name the exact buttons and fields.
1. [Action]
2. [Action]
- **Check:** [How they know it worked]
3. [Action]
- **If [condition]:** go to step [N]
- **If [other condition]:** go to step [N]
4. [Action]
> **Note:** [Anything easy to get wrong here]
5. [Action]
6. [Action]
- **Check:** [How they know it worked]
## 6. Exceptions
What to do when it does not go to plan. This is the section that carries the real knowledge, and the section most often left out.
| If this happens | Do this | Escalate to |
|---|---|---|
| [Common failure] | [Response] | [Role] |
| [Common failure] | [Response] | [Role] |
| [Something you have not seen before] | Stop. Do not improvise | [Role] |
## 7. Definitions
Terms, codes and abbreviations a new person would not know. Include the internal jargon, especially the jargon nobody notices is jargon.
| Term | Meaning |
|---|---|
| [Term] | [Plain explanation] |
## 8. Related
- [Other procedure this hands off to]
- [Other procedure that hands off to this]
- [Policy or reference document]
---
## Revision history
| Version | Date | Changed by | What changed |
|---|---|---|---|
| 1.0 | [Date] | [Name] | First version |
---
## Before publishing, check
- [ ] Someone who has not done this task could follow it without asking
- [ ] Every step starts with a verb and contains one action
- [ ] Every system, button and field is named exactly as it appears
- [ ] Every vague quantity has been replaced with a number
- [ ] The exceptions section covers the failures that actually happen
- [ ] Prerequisites list every access permission needed
- [ ] It has a named owner and a review date
- [ ] It is under fifteen steps, or it has been split
