Almost every mid-sized company has tried it - and almost none has an outcome that stayed current for more than a few months. Somewhere there's a folder called "Processes_final", a QM manual from 2021, a wiki with three maintained pages and forty abandoned ones.
This guide explains why that happens - and how to do better: what belongs in process documentation, how to go about it in practice, and how to keep the documentation from turning into waste paper after six months.
Why process documentation fails: the three versions of every process
In every company, every process exists three times:
1. The documented process. What's written in the manual, the wiki, or the ISO documentation. Usually created in a workshop two years ago, unchanged ever since.
2. The assumed process. What management believes happens. "The order goes through SAP, then sales reviews it, then it goes to production."
3. The real process. What actually happens: the order comes in by email, Ms. Behrens types it into an Excel list because the SAP screen is "clunky," then shouts across the hall to ask whether production has capacity. Has worked for years. Written down nowhere.
Most documentation projects fail because they write down version 2 - management's assumption - and never lay eyes on version 3. The people who know the real process rarely sit in the workshop. And when they do, they don't say: "I've been doing this differently from what's on the wall for years."
The second failure mode is effort. Documenting processes traditionally means scheduling workshops, pulling people out of their day-to-day work, and finding someone to write everything up afterward. With 20 processes and a thin roster, the momentum is gone after the third workshop. The rest stays undocumented - usually exactly the processes that live in a single person's head.
The third problem gets its own section below: even good documentation goes stale if nobody maintains it.
What good process documentation contains
Useful process documentation answers the questions a new colleague asks in week two. No more, no less. As a checklist:
The steps
- What triggers the process? (An order, a phone call, month-end close, an error report)
- Which steps follow, in what order?
- What is the outcome, and how do you know the process is finished?
The owners
- Who performs each step - as a role, not just a name?
- Who decides when things are unclear?
- Who covers when the main person is on vacation? (If the answer is "nobody," you've just documented a knowledge risk - that's valuable.)
The systems
- Which tools are used in which step - including the unofficial spreadsheets on the local drive?
- Where does the data live, and who has access?
- Where is information transferred from one system to the next - automatically or by hand?
The handoffs
- At which points does the process change departments or people?
- How is it handed off: a ticket, an email, a word in passing at the workbench?
- Handoffs are the most common source of errors. Document them more thoroughly than anything else.
The edge cases
- What happens with rush orders, complaints, missing information?
- These exceptions are often known to exactly one person - and they're exactly what you'll need the documentation for later.
The glossary
- What does "released" mean at your company? What's an "OC"? What does sales mean by "done"?
- Internal jargon is the biggest hurdle for new hires. Three lines of glossary save thirty follow-up questions.
If you need a process documentation example: take order intake. Trigger (order by email or web shop), steps (entry, review, confirmation), owners (inside sales, head of sales for special pricing), systems (ERP plus the price list in Excel), handoff to production (by ticket, by phone for urgent cases), edge case rush order (approved directly by the CEO). Two pages, and a new hire can ask real questions after reading it instead of basic ones.
Step by step: how to document your processes
1. Prioritize by risk, not by org chart. Don't start at the top left of the org chart. Ask: which process grinds to a halt if a specific person is out tomorrow? Which one regularly produces errors? Those first.
2. Ask the people who do the work. Don't ask the department head how the process runs - ask the person who executes it. Ideally one-on-one, not in a group. In individual conversations, people say things like "officially we do it this way, but actually..." That sentence is the core of every honest process documentation.
3. Follow the references. In almost every conversation, someone says "Max handles that part" or "Hanne maintains that list." Those aren't side notes, they're your map: talk to Max and Hanne next. That way you work your way from one knowledge holder to the next instead of guessing who might know something.
4. Write down the as-is state, not the wish. The most common mistake: "optimizing" while documenting - writing down how things should be. The result is documentation that's wrong from day one. First the honest as-is state, with the Word template from 2019 and the inbox serving as the filing system. You can improve afterward, based on facts.
5. Make contradictions visible instead of smoothing them over. When the boss says "it runs through SAP" and the team says "it runs through three spreadsheets and that one USB stick," that's not an editing problem. That's a finding. Write both versions down side by side with their sources and resolve it - the resolution is usually worth more than the documentation itself.
6. Decide how the documentation stays current. More on that in a moment - but decide it before you write the first page. Documentation without a maintenance plan is a project with a built-in expiration date.
If you simply lack the capacity for steps 2 and 3 - and in mid-sized companies that's the norm - there's now another way: at wissa.ai, an AI interviews your employees individually via chat, 15 to 20 minutes per person, no workshops. If "Max and Hanne handle that" comes up in a conversation, both are invited automatically - the snowball principle from step 3, except nobody has to conduct and write up the interviews. Contradictions between statements appear side by side with their sources, and every statement in the finished documentation is traceable back to the interview.
The maintenance curse: why documentation goes stale - and what helps
The moment process documentation is finished is the moment it starts going stale. A new tool is introduced, a colleague leaves, a step is dropped - and nobody thinks to update the manual. Why would they: maintenance is invisible work that nobody feels responsible for and that always loses out to the day-to-day.
After a year, 70 percent of the documentation is still accurate - but nobody knows which 70 percent. From that point on, it's worse than no documentation at all: new hires rely on wrong information, veterans ignore it entirely. The PDF graveyard is born.
What helps:
- Name one owner per process. Not "the QM team," but a person with a name who touches the page when things change.
- Tie maintenance to events, not dates. A "quarterly review" gets postponed until it dies. Better: every tool rollout, every personnel change, every process change triggers a documentation update.
- Keep it small. Two current pages beat twenty stale ones. Cut everything that doesn't answer a question a new colleague would ask.
- Living documentation instead of a document. The more fundamental approach: documentation isn't an end product that's created once and then administered - it's continuously fed by recurring conversations. At wissa.ai, for instance, the process documentation updates after every interview, with a visible diff against the previous version - you see what changed since the last state instead of guessing.
The yardstick is uncomfortable but simple: if nobody can say when your documentation was last updated, it's dead.
Process documentation template: when Word is enough - and when it isn't
Searching for a "process documentation template" turns up hundreds of Word and Excel templates. The sober assessment:
A template is enough if you have five to ten processes, one person genuinely treats the documentation as their job, and your workflows rarely change. A two-page template with the fields from the checklist above - trigger, steps, owners, systems, handoffs, edge cases - is then perfectly sufficient. You don't need BPMN software or swimlane diagrams to capture order intake.
A template is not enough if the actual problem isn't the form. A template doesn't solve three things: it doesn't get the knowledge out of people's heads (the empty "edge cases" field doesn't fill itself), it doesn't reveal that the documented process and the real one have drifted apart, and it doesn't maintain itself. If you have 30 processes, high turnover, or critical knowledge locked in individual heads, templates mostly get you one thing: 30 empty forms and a guilty conscience.
The rule of thumb: the template solves the structure problem. For the capture problem and the maintenance problem, you need a process - or a tool that handles both.
If you want to try the second path: wissa.ai is currently in beta - €149 per month with 12 interview credits, free for interviewees, GDPR-compliant with EU hosting and a DPA, no performance evaluation and voluntary participation, so it also sits well with a works council. Join the beta waitlist.
FAQ
Where do I start when nothing is documented yet?
Not with the org chart, and not with all processes at once. Pick the two or three processes with the biggest risk - where knowledge hangs on a single person or errors happen regularly. Talk to the people who do the work, write down the as-is state on two pages, name an owner. Then the next process.
How detailed does process documentation need to be?
Detailed enough that a new colleague can keep working after reading it - no more. Every click-by-click screenshot epic goes stale faster than it gets read. Trigger, steps, owners, systems, handoffs, and edge cases on one to three pages is almost always the right level.
Who should document the processes - the manager or the team?
The content has to come from the people who do the work; otherwise you're documenting the assumption instead of the reality. The manager prioritizes, resolves contradictions, and makes sure there's time for it. If you delegate the writing entirely to someone who doesn't execute the process themselves, at least make sure that person talks to the right people.
Do I need special software for process documentation?
For a few stable processes: no, a Word template or a wiki is enough. Software becomes worthwhile when capturing (getting knowledge out of many heads) or keeping things current is the actual problem - that is, with many processes, turnover, or knowledge spread across individual heads. Don't buy a tool for a problem you don't have, and don't get a template for a problem a template doesn't solve.
How often does process documentation need to be updated?
Events beat a fixed schedule: a new tool, a personnel change, a modified workflow - each of these triggers an update. If you want a schedule on top: having the owner reread each process once a year is more realistic than the quarterly review that gets dropped after the second quarter.