Almost every business has a folder of procedures. Most of them were written for an audit, a certification visit or a new manager's enthusiasm, and most of them have not been opened since. The staff who do the work learned it from a colleague, and when asked how something is done, they show you rather than point to the document. If that sounds familiar, the issue is not that your people are lazy. It is that the documents were written for the wrong reader, in the wrong form, in the wrong place.
This article describes how to document a workflow so that it is used, because it is accurate, short, easy to reach and owned by the people who rely on it.
Start with why people ignore documents
A written procedure loses to a colleague's advice for good reasons.
- It describes the intended process, not the real one. The gap between the two is explored in why the official process is often not the real process. Staff quickly learn that the document leaves out the workaround that actually gets the job done.
- It is too long. A twelve-page document cannot be consulted in the middle of a task. It can only be read in advance, which means it is read once or never.
- It is hard to find. If locating it takes longer than asking, people ask.
- Nobody owns it. Documents with no named owner drift away from reality because no one is responsible for updating them.
- It was written by someone who does not do the work. The language is that of policy rather than of the task.
Atlassian's guide to internal documentation frames the purpose well. It describes the practice of recording clearly detailed processes and procedures for reference by your own team, and opens with the picture of a long-serving employee who resigns with two weeks' notice, taking knowledge nobody else has. That is the risk documentation exists to reduce, and it is the same one explored in what happens when the only person who understands the system leaves.
Document what happens, not what should happen
The first rule is to watch the work before writing a word. Sit next to the person doing the task and write down what they actually do, including the steps they skip, the checks they add and the places where they open a different tool. Atlassian's guidance on process mapping describes the idea of visualising a process so the steps, people and decisions become visible and can be examined. You do not need special software. A list of steps on paper, confirmed by the person who does the job, is enough for most workflows. For a method that stays simple, see how to map a business workflow without making it complicated.
Atlassian defines a workflow as a sequence of steps that guide work from start to finish, detailing the roles, processes and tasks required. That definition is a good checklist. A workflow document should therefore cover the trigger that starts it, the steps in order, the person who does each, and the point at which it ends.
What a usable workflow document contains
Aim for one page. If you cannot fit it on one page, the workflow probably needs splitting into two. The page should answer these questions in this order.
- What starts this workflow? A customer order, a supplier invoice, a new starter form.
- Who owns it? One named role, plus a deputy.
- What are the steps? Numbered, with one action per line, written as instructions: "Open the order in the accounting package and check the VAT number against the customer file."
- Where are the decisions? If the amount is over R50,000, who approves? Spell out the rule, not the principle.
- What does done look like? A statement of the result: invoice sent, stock reserved, confirmation logged.
- What goes wrong most often? Three or four known problems and what to do about each. This section is usually the most valuable.
- Where do I get help? The name of a person and how to reach them.
- Last reviewed on, and by whom. A date, so readers can judge whether to trust it.
Include a screenshot or a sample record where it removes ambiguity. Leave out background, history and policy statements. If a regulation applies, such as the Protection of Personal Information Act when handling customer data, state the one step that satisfies it and link to the full policy rather than quoting it.
Put it where the work is
A document stored three folders deep on a shared drive will not be used mid-task. Place the workflow description inside or next to the tool where the work happens: a link in the top bar of the order system, a pinned message in the team chat, a printed card at the packing bench. The test is simple: how many clicks from the moment someone is unsure to the moment they see the step? The aim is one or two.
This is part of treating documentation as part of the system rather than something bolted on afterwards, an idea developed in why documentation is part of the business system, not an add-on.
Let the people who do the work write it
The most reliable way to produce a document people follow is to have those people draft it. Ask the person who does the task to write the first version, or interview them and write it up in their words, then ask two colleagues to try following it exactly as written. Every point at which they hesitate, or ask a question, shows a missing step. Fix it and test again with someone new. This is the most effective review you can do, because it finds problems that no amount of proofreading will.
Keep it alive
Documentation decays at the speed that work changes. Three habits keep it current.
- Review on a schedule. Set a review date, perhaps every six months for important workflows, and let the owner confirm it still matches reality.
- Update at the moment of change. Add "update the workflow page" to the checklist for any system change, new tool or staff handover.
- Make correction easy. Let anyone flag an error with a comment or a message to the owner. If staff can fix a mistake in two minutes, they will. If it takes a form and an approval, they will not.
Prioritise by risk. If you are unsure where to begin, what business processes need documentation first offers a way to rank them, and how to design workflows that can survive staff changes shows what to build around them.
An illustrative example
The following is a hypothetical case. A Durban distributor has a seventeen-page procedure for processing customer returns. New staff are trained by sitting with Thandi, who has done the job for nine years. When Thandi takes extended leave, returns back up for three weeks, because the document describes a credit-note approval that no longer exists and omits the step where the warehouse photographs damaged stock.
The operations manager spends an hour watching Thandi process returns and writes a one-page workflow in eleven numbered steps. Thandi corrects two. A new employee follows it without help on her first day and finds one unclear instruction, which is rewritten. The page is linked from the returns screen in the order system, names Thandi as owner and a colleague as deputy, and carries a review date six months ahead. The seventeen-page document is archived. The next time Thandi is away, nothing backs up.
The point
A workflow document is followed when it is accurate, short, easy to reach and owned. Watch the real work, write one page in the words of the people who do it, put it inside the tools they use, and keep it current with a named owner and a review date. Do that for the handful of workflows that carry the most risk, and your procedures stop being a folder and become a working part of the business.
Sources and further reading
- How to Ace Internal documentation - The Workstream (last verified 10 October 2026)
- Exploring Agile Workflows in Project Management - Atlassian
- What is Process Mapping? [+How to Create One] - The Workstream
Related Mellorca reading
- How to Keep SOPs From Becoming Outdated PDFs
- How to Move Operational Knowledge Out of People's Heads
- Before you automate, understand how the work actually moves