STEP 04
WRITE IT FOR THE
PERSON DOING IT.
Almost every business that has attempted documentation has a folder of process documents nobody opens. They were written once, by someone senior, in a week when things were slow, and they were obsolete within a quarter.
The problem is not discipline. It is that the documents were written for the wrong reader and had no mechanism for staying true.
Why the binder fails
Three reasons, and they compound.
It was written from memory. Someone described a process they perform automatically, which means they skipped every step they no longer notice. The document is accurate and incomplete, which is the worst combination because it looks trustworthy right up until it fails.
It was written as prose. Nobody reads three paragraphs while holding a phone and a customer. A process document is consulted mid-task, in a hurry, by someone who needs one specific thing.
Nobody owned it. The process changed in March and the document did not, because updating it was no one's job. After the second time someone follows it and gets a wrong result, the whole folder is dead. Trust in documentation is binary and it does not come back easily.
The shape that gets used
Keep every process document to the same small skeleton, and keep it short.
- Trigger. What starts this. A form submission, a phone call, a date, a completed prior stage. If you cannot name the trigger, the process starts when someone feels like it.
- Owner. The seat responsible, not the person's name. Names change and seats do not.
- Steps. Numbered, imperative, one action each. Screenshots or a short recording where a screen is involved.
- Definition of done. The checkable conditions that must be true before this moves on. This is the load-bearing section.
- Exceptions. The two or three situations that come up and what to do about them, including what escalates.
If a document runs longer than a page or two, it is probably two processes. Split it. Long documents are not more thorough, they are less read.
If this was useful, Ben's published resources goes deeper.
Definition of done is the whole point
Everything else in a process document is instruction. The definition of done is the contract, and it is the reason documentation reduces the owner's workload rather than just describing it.
Write it as checkable conditions, not as a state of mind. Not 'the file is complete' but 'signed agreement uploaded, scope field filled, deposit recorded, start date entered, customer confirmation sent.' Someone other than the person who did the work should be able to verify it in under a minute without asking a question.
This is what makes handoffs stop failing. The next stage does not begin because someone said they were finished. It begins because the conditions are visibly met. Ambiguity at that boundary is where the majority of small business follow-up quietly dies.
Capturing the steps nobody mentions
Do not write documentation from an interview. Capture it from the work.
The cheapest method available: have the person perform the task while recording their screen and narrating. Twenty minutes of that contains every step they would have omitted, including the workaround, the field they always leave blank, and the message they send to a colleague that is not in any system. Then write the document from the recording.
The second method is to have someone who does not do the job attempt it using the draft, with the expert watching and silent. Every question the newcomer asks is a missing step. Every place the expert wants to interrupt is an undocumented decision. Silence is the whole technique and it is harder than it sounds.
Keeping it alive
A process document is not a deliverable. It is a maintained asset, and it needs the same three things any asset needs.
- An owner. The seat that performs the process owns the document. Not the manager, and not whoever wrote it originally.
- A change trigger. The rule is simple and it has to be enforced once loudly: if you change how the work is done, you change the document in the same week. Not later.
- A review point. Read it when a new person is trained on it, because training is when errors surface for free.
One more rule that saves an enormous amount of wasted effort: do not document everything. Document what is frequent, what is expensive when done wrong, and what you want to hand to someone else. A rare task done by one experienced person does not need a document. It needs a note about who knows how.
Sequence the work the same way. Do not attempt to document a business. Document one process, in use, and let the people running it correct it for a month before you write a second. An organization that has one document it trusts is in a far better position than one with forty that nobody has tested, and the first accurate document teaches you the format your business will actually read.
Frequently asked
Questions people actually ask
Where should process documents live?
Wherever the work happens, linked from the stage that uses them. A document in a shared drive that requires searching is a document that gets skipped under pressure.
Video or written?
Both, for different jobs. A short recording is the fastest way to capture and to teach. The written version is what someone scans mid-task when they need one step. The recording is the source; the document is the reference.
Who should write the SOP?
The person who does the work, from a recording of themselves doing it, edited by someone who does not know the job and will therefore notice the gaps.
How detailed should steps be?
Detailed enough that a competent person new to your business could complete it without asking. That is the test, and the only way to know is to have someone try.
What should not be documented?
Anything rare, anything that genuinely requires judgment, and anything about to change. Documenting a process you are about to redesign is a way of feeling productive while accomplishing nothing.
How do I get my team to actually use them?
Make the definition of done a requirement for the work to advance, so following the document is the path of least resistance. Compliance built on reminders decays; compliance built into the workflow does not.
Make your next move
A year from now, what will you be glad you started today?
You don't need another promise that everything will be easy. You need something useful to learn — and a next step you're willing to take.