SOPs: writing down how the work actually gets done
'We have always done it this way' is not documentation. Which tasks to write up first, how detailed is detailed enough, and who owns keeping it true.
· 5 min read
'We have always done it this way' is not documentation
In most small businesses the process exists. It is genuinely consistent, genuinely reasonable, and it lives entirely in one or two people's heads, reconstructed slightly differently each time from memory and habit. This works well enough that it is easy to mistake for a system, and the difference only shows up under three conditions: the person is away, the person leaves, or the work has to happen twice as often as it used to.
The reason it feels like a system is that experienced people are very good at silently handling exceptions. They know the one supplier who needs a phone call rather than an email, the customer whose invoice has to be split, the month when the filing deadline moves. None of that is written anywhere, and none of it is visible from outside — which is why handing the task over usually goes fine for a week and then produces a problem nobody can explain. The exception-handling was the job, and it was the part that never got mentioned, because to the person doing it it does not feel like a step. It feels like knowing what you are doing.
What to document first, when you cannot document everything
Nobody has time to write up every process, and a project to do so will stall around item nine. Three categories earn priority, for different reasons.
Tasks only one person knows. This is a continuity risk with no upside; the cost of the gap is entirely borne at the worst possible moment. Start here even if the task is small.
Tasks done rarely. Anything on a quarterly or annual cycle — a filing, a renewal, a licence — gets relearned from scratch every time, usually under deadline. These have the best return per page written, because the person rereading it in eleven months is you, and you will have forgotten.
Tasks with quality or compliance consequences. Where getting it wrong means a penalty, a lost customer or a safety issue, consistency is worth more than speed.
What does not need documenting first: the daily task three people do competently every day. It is the most tempting to write up because it is the easiest to describe, and it is the least valuable.
How detailed is detailed enough
The useful standard is a test rather than a length: can a competent person who has not done this task follow it without asking a question? Not a stranger off the street, and not someone who already knows — a new hire with relevant general skills and no knowledge of your specific arrangement.
This test cuts both ways, which is what makes it useful. It rules out 'process the invoices', which assumes everything. It also rules out the forty-step document explaining how to open a spreadsheet, which nobody reads past step six and which goes out of date the moment the software changes its menus.
The practical way to hit it is to write the steps and then have someone else actually do the task from the document while the author stays quiet. Every question they ask is a missing step, and the author will be surprised by most of them. Watching this happen once permanently changes how someone writes procedures, because the gaps are never where the writer expected. They are in the parts so obvious to an expert that they did not register as decisions at all.
The format matters much less than the trigger
Businesses spend a surprising amount of energy choosing between a document, a spreadsheet, a wiki and a dedicated tool, and the choice barely affects whether the procedure gets followed. What affects that is whether the document is attached to the moment the work happens.
A procedure in a folder is consulted when someone remembers it exists. A procedure linked from the recurring calendar entry, the task template or the checklist that opens the job is consulted every time, because reading it is part of starting rather than a separate act of diligence. This is the single largest difference between documentation that changes behaviour and documentation that is merely correct.
The corollary is worth stating plainly: a beautifully organised knowledge base with no triggers pointing into it will be read during onboarding and approximately never again. If you have to choose between a well-structured library nobody enters and a plain text file linked from the task itself, choose the text file. Structure helps a reader who is already looking. It does nothing for the reader who does not know to look.
Who owns keeping it true
Documentation does not decay gradually; it becomes wrong at a specific moment, when something changes and nobody updates the page. From then on it is worse than nothing, because it is confidently wrong and looks maintained. Someone following it does the old thing correctly.
So every procedure needs a named owner, and 'the team' is not a name. The person who does the task most often is usually the right owner, not the manager, because they are the one who finds out first when a step stops working. Their job is not to rewrite it on a schedule; it is to update it when reality changes, which is a much smaller commitment and a much more reliable trigger.
A review date helps as a backstop for the rare procedures nobody has touched — an annual pass asking only 'is this still what we do?' catches the drift that never had an obvious change event. What does not work is a policy that all documentation is reviewed quarterly. That produces a large recurring obligation, which produces skipped reviews, which produces a review log that is itself out of date.
What an SOP cannot do
It cannot make a bad process good. Writing down a sequence of steps that involves three unnecessary approvals produces a clear, well-structured description of three unnecessary approvals, and gives them a permanence they did not previously have. Documenting a process is a reasonable moment to ask whether it should exist in its current shape, and the person writing it up is often the best placed to notice — but the document itself has no opinion.
It cannot replace judgement in work that is mostly judgement. Steps are the right tool for tasks with a correct sequence: filing, onboarding, dispatch, reconciliation. For work where the skill is deciding what to do, a procedure can supply the inputs to consider and the boundaries not to cross, and pretending it can supply the decision produces a document people work around.
And it cannot transfer motivation. A documented process makes it obvious what should have happened, which is genuinely useful when something goes wrong and does nothing on its own to make anyone want to follow it. If a step is routinely skipped, the fastest thing to check is not whether the document was clear. It is whether the step is worth doing.
Common questions
Where do I start if nothing at all is written down?
With the single task that would cause the most damage if the person who does it were unavailable for two weeks. That is usually not the most complex task — it is often something small and unglamorous like the payment run or a monthly filing. Writing one procedure and having someone else successfully follow it is also the cheapest way to find out whether your organisation will actually use documentation before you invest in producing a lot of it.
Should the person who does the task write it, or should someone else interview them?
Either works, and they fail differently. The person doing it will skip the steps that feel obvious, because expertise makes decisions invisible. An interviewer catches those but introduces errors of their own by mishearing detail. The reliable combination is that the expert writes and a non-expert executes it once — that second pass finds what either approach alone misses.
How do we stop procedures from going stale?
Attach ownership to the person closest to the work and make updating it the normal response to a step breaking, rather than scheduling a mass review. Broad quarterly review policies create a large recurring obligation that gets skipped, and the review log then goes stale alongside the documents. A yearly one-question pass — is this still what we do? — is a useful backstop for procedures with no obvious change event.
Is it worth documenting a process we already plan to change?
Usually yes, briefly, and for a reason people underestimate: you cannot see clearly what to change while the current process only exists as habit. A rough write-up of what happens today is the input to the redesign. Keep it short and mark it as current-state rather than polishing it, so nobody mistakes it for the intended future process.
Related pages