Most SOPs sit in a folder nobody opens. They get written during a calm week, shared once and forgotten. Then the busy day comes, someone new is running the process, and they do it from memory or from a WhatsApp voice note.
I have written a lot of process documents for programmes, learner communities and events. The ones that get used share a few habits.
Write it where the work happens
An SOP in a separate drive loses to habit every time. Put the steps inside the tool people already use, at the moment they need them. A checklist inside the tracker, a pinned message in the team channel or a template that opens with the steps already filled in.
For a learner community at ALX, the process for handling a complaint lived in the pinned message of the ambassadors' group: what to ask, where to log it and who to send it to. New ambassadors followed it from day one because it was in front of them.
One action per step
If a step makes someone stop and think, it holds two steps. Break it down until each line is one action a tired person can do without interpreting.
- Weak: Handle the new applicant.
- Strong: Open the applications sheet. Mark the row Accepted. Send welcome template 1. Add them to the cohort WhatsApp group.
Start from the failure
Most SOPs describe the happy path. People need help when something goes wrong. For every process, add a short section called If this happens:
- The payment did not reflect: ask for the M-Pesa confirmation message and check the statement before resending anything.
- A participant missed two sessions: call them the same day and mark them at risk in the tracker.
- The trainer cancels: message the group with the new date within the hour.
Give every process an owner
A process with no owner decays. Put one name at the top of each SOP. That person reviews it after every cohort or event and updates it when something changes. When I ran operations for a startup academy, the owner line alone kept the Google Classroom setup consistent from one cohort to the next.
Keep it to one page
If a process needs more than a page, it is probably several processes. Split them. Short documents get read. Long ones get skimmed and then ignored.
Test it on someone new
Before you call an SOP done, give it to someone who has never run the process and watch them do it. Every question they ask is a gap. Fix the document, then try again with someone else.
A template you can copy
- Name: what the process is, in plain words.
- Owner: one person.
- When it runs: the trigger, such as every Monday or when a new partner signs.
- Steps: numbered, one action each, with links to the tools.
- If this happens: the three most common problems and what to do.
- Last reviewed: a date.
When to turn an SOP into software
Once a process runs the same way every week and many people depend on it, software can take over the repetitive steps. The SOP tells you exactly what to build. That is how most of the systems I build start: a one-page process that already works, turned into a tool so it keeps working when the team grows.
Where to keep your SOPs
Keep one index page that lists every process with its owner and a link. Then link each SOP from the place where the work happens: the tracker, the pinned message in the channel or the first page of the Google Classroom. People should never need to search for a process.
Questions teams ask me
How often should we update SOPs?
After every cohort, event or major change, and at least once a quarter. The owner updates the date at the bottom so everyone knows it is current.
Video or text?
Both work. A two-minute screen recording is great for showing a tool. Keep the written steps too, because people scan text faster when they are in the middle of the task.
If your team runs on processes that live in someone's head, let's write them down together. Related reading: Stop automating the wrong things.
