How to Document a Business Process Before Automating It: a Simple One-Page Template
Most automation problems are process problems in disguise. When the rules exist only in people's heads, every developer or tool will encode a different version of them, and the result will not match how the business actually works. A one-page description of the process, written before any automation, is the cheapest insurance you can buy. It also makes onboarding new staff easier even if you never automate anything.
Why write it down first
A written process forces decisions that are easy to avoid in conversation: who owns the step, what happens when information is missing, what counts as done. It exposes steps that exist only because 'we always did it this way'. And it gives whoever builds the automation — your team, a contractor or a tool — a clear specification instead of a guess.
The one-page template
Keep it to one page. If it does not fit, split the process into smaller ones. Each description answers the same questions:
- Name and goal: what the process achieves, in one sentence. For example, 'every website enquiry gets a reply within one working hour'.
- Trigger: what starts it — a form submission, a paid invoice, the first of the month.
- Steps: numbered, each with who does it and in which system.
- Rules: the decisions inside the steps — who gets which enquiry, what discount needs approval, what is a duplicate.
- Exceptions: what happens when something goes wrong, and who is told.
- Result and measure: what 'done' looks like and the one or two numbers that show whether the process works.
How to collect the real process
Do not write it from memory in an office. Sit with the person who does the work and walk through two or three real recent cases step by step, including the awkward ones. Note where they switch between systems, where they copy data and where they wait for someone. The documented process should describe what actually happens, then a separate version can describe what should happen.
From description to automation
With the page in hand, mark each step: can it be automated by clear rules, does it need AI because it involves free text, or must it stay with a person because it needs judgement. The rules section becomes the logic of the automation; the exceptions become its error handling and alerts; the result and measure become its acceptance criteria.
Keep it alive
A process description is useful only while it is true. Store it where the team works, name an owner, and update it whenever the process or the automation changes. A good rule: no change to an automated process goes live without a change to its page.
Frequently asked questions
- What is the difference between a process description and an SOP?
- An SOP (standard operating procedure) is usually a detailed step-by-step instruction for the person doing the work. The one-page process description is higher level: goal, trigger, owners, rules, exceptions and measure. For automation, the description comes first; detailed instructions can follow.
- Do I need special software to document processes?
- No. A shared document or a page in your team's workspace is enough. Diagram tools help for complex processes with many branches, but the text answers matter more than the drawing.
- How long does it take to document one process?
- For a typical small-business process, an hour or two with the person who does the work, plus time to agree the rules with the owner.
- Should I document everything before automating anything?
- No. Document the process you plan to automate first. Describing the whole company before acting is a common way to never start.
Want your key processes documented and measured by someone who has done it many times? The €490 audit produces exactly this: process descriptions, measured losses and a prioritised plan you can hand to any team.
Discuss the €490 audit