Ask most businesses whether they have documented their processes. Most will say yes. Ask whether those documents are current, accessible, and actually used when someone needs guidance. The answer changes.
Process documentation in most organisations exists in two states: it was never written, or it was written once, stored somewhere, and has not been touched since. Neither state is useful.
The reason is not that the people writing the documentation are careless. It is that most process documentation is written for the wrong purpose, in the wrong format, and stored in the wrong place.
Why Process Documentation Fails
Wrong purpose. Most process documentation is written for an audit, a compliance requirement, or a new hire onboarding exercise. The goal is coverage, not usability. The result is comprehensive documents that describe every edge case but cannot answer the question "what do I do next?" quickly.
Wrong format. Process documentation that lives in Word or PDF is difficult to update and difficult to navigate. People who need guidance in the middle of executing a task cannot quickly scan a twelve-page document to find the relevant section. The format should match the use case: something that can be navigated quickly under time pressure.
Wrong location. Documentation stored in a shared drive that requires three clicks to find, or in a system that most of the team does not have on their taskbar, is documentation that does not exist in practice. Accessibility is not a nice-to-have — it determines whether the document is used.
The Principle: Document the Decision, Not Just the Steps
The most common failure in process documentation is describing what to do without explaining why. Step-by-step instructions without context produce brittle processes: people follow the steps mechanically and get the wrong outcome because they lack the judgement to handle variations.
Useful process documentation has three layers:
The what: The steps in sequence, clearly stated. Short sentences. Active voice. One action per step.
The why: The business logic behind the process. Why does this step happen before that one? What is the process trying to achieve? What would go wrong if a step were skipped?
The exceptions: The most common variations and what to do in each case. Not every edge case — just the three or four situations that come up regularly and where the default process does not clearly apply.
The Format That Actually Gets Used
For most operational processes, a structured wiki page outperforms a Word document. The key structural elements:
A one-sentence summary at the top. What does this process produce? Who is it for? This lets someone scan a list of processes and find the right one in five seconds.
Trigger and ownership. What event starts this process? Who is responsible for running it? Without these two pieces of information, the process will not be initiated correctly.
Step list. Numbered, short, active voice. Avoid combining multiple actions in one step. "Open the CRM, navigate to the client record, and update the status" should be three steps, not one.
Decision points. Where the process branches depending on circumstances, use a simple if-then format. "If the client is on a retainer, go to step 8. If they are on a project basis, go to step 12."
Related documents. Links to the templates, forms, or other processes that this one depends on.
Revision date. When was this last reviewed? A document with no revision date cannot be trusted.
Making Documentation Stick
The reason most documentation becomes stale is that there is no ownership of the updating process. Someone writes it, files it, and moves on. When the process changes — as it always does — nobody updates the document.
The fix is to assign each process document an owner: one named person who is responsible for keeping it current. This does not mean they write every revision — it means they are the person who notices when the document drifts from reality and makes sure it gets updated.
The Right Scope
Not every process needs documentation. Over-documenting creates its own problem: so many documents that nobody can find the right one.
Prioritise documenting:
- Processes that run repeatedly (daily, weekly, monthly)
- Processes that are currently owned by one person and would stop or degrade if they left
- Processes that have produced errors or inconsistencies when run by different people
- Processes that are required for compliance or client commitments
Processes that happen rarely, involve genuine expert judgement that cannot be codified, or are already handled reliably by tools do not need detailed documentation.
The Connection to Onboarding
Process documentation has a compounding return that is easy to miss: every well-documented process reduces onboarding time for new team members. A business with documented processes can bring a new hire to productive contribution in weeks rather than months. A business where operational knowledge lives in people's heads requires each new hire to reconstruct that knowledge from scratch.
At ten employees, undocumented processes are a nuisance. At thirty, they are a growth constraint. The cost of documentation always looks higher than the cost of not documenting — until a key person leaves, a process breaks, and the real cost becomes visible.
The System Audit Kit includes templates for building your process library — including the process inventory worksheet, the documentation format template, and a ownership assignment matrix.
