How to Document a Business Process (So You're Actually Ready for Automation)
By Stephen Kearney
Every week I talk to business owners who want to automate something. They know it takes too long. They know their team is sick of doing it manually. They’re ready to invest.
Then I ask the question that stops most conversations dead: “Can you walk me through exactly how that process works today?”
What follows is usually a pause, then something like: “Well, Sarah handles most of it, and she just… knows.” Or: “It depends on the situation.” Or my personal favourite: “We tried to document it once but gave up.”
Here’s the thing - automation doesn’t fix chaos. It scales it. If you can’t clearly explain how a process works today, you’re not ready to automate it. But documenting a business process doesn’t have to be painful. You just need the right framework.
The Five Elements Every Process Document Needs
Forget flowcharts for now. Forget swimlane diagrams and BPMN notation. Before you get fancy, every process document needs five things answered clearly.
1. The Trigger: What Kicks This Off?
Every process starts somewhere. A customer submits a form. An invoice arrives in someone’s inbox. It’s the first Monday of the month. A stock level drops below a threshold.
If you can’t name the trigger, you don’t have a process - you have a habit. Write down what starts the chain of events. Be specific. “When we get a new lead” is vague. “When a contact form submission arrives in the shared inbox” is something you can actually automate.
2. The Steps: What Happens, in What Order?
Walk through the process from trigger to completion. Write each step as a simple action: “Open the spreadsheet,” “Copy the client name into the CRM,” “Send the confirmation email.”
Don’t worry about being too detailed at first. Get the big steps down, then come back and break down any step that takes more than a minute or two. The goal is that someone who’s never done this task could follow your document and get roughly the right outcome.
3. The Decisions: Where Does the Path Split?
This is where most documentation falls apart. Processes aren’t straight lines - they branch. “If the order is over $5,000, it needs manager approval.” “If the client is in Queensland, use this template; otherwise, use that one.”
These decision points are gold for automation. They’re also the bits that live in Sarah’s head and nowhere else. Ask your team: “Is there any point where you have to make a judgement call?” Then document what they base that judgement on.
4. The Exceptions: What Goes Wrong?
Every process has edge cases. The payment that bounces. The form that’s missing a field. The client who sends the wrong document. What happens then?
Exception handling is where manual processes eat up the most time, and it’s where automation delivers the most value. Document the common exceptions and what happens when they occur. You don’t need to cover every possible scenario - just the ones that happen regularly.
5. The Systems: What Tools Are Involved?
List every application, spreadsheet, email account, database, or shared drive that gets touched during the process. This becomes your integration map when it’s time to automate.
Pay attention to where information moves between systems manually. If someone copies data from an email into a spreadsheet and then types it into a CRM, that’s three systems connected by a human - and that’s exactly the kind of thing automation handles brilliantly.
How to Actually Get This Done Without Losing the Will to Live
Here’s my practical advice for getting through the documentation process without it becoming a project that drags on for months.
Start with the process that annoys people most. Don’t try to document everything at once. Pick the one task your team complains about regularly. Motivation is highest when people can see the payoff.
Record someone doing it. Sit with the person who runs the process and watch them do it once. Take notes or, even better, record a screen share. You’ll catch steps they’ve forgotten to mention because they’ve become automatic.
Use plain language. This document is not for a software vendor. It’s for you and your team. Write it in normal English. If you catch yourself using jargon, simplify.
Accept “version one.” Your first pass will be incomplete. That’s fine. A rough document is infinitely more useful than a perfect document that doesn’t exist. You can refine it as you go.
Time-stamp it. Processes change. Put a “last reviewed” date on your document so you know when it needs updating.
Why This Matters Beyond Automation
Even if you never automate a single thing, documented processes are valuable. They make onboarding new staff faster. They reduce the bus factor - the risk of everything falling apart when one key person is unavailable. They make it easier to spot inefficiencies.
But when you are ready to automate, having this documentation means the difference between a project that takes weeks and one that takes months. It means your automation partner (or your internal team) isn’t spending the first half of the engagement just trying to understand what you do.
The Bottom Line
You don’t need a business analyst or a consulting firm to document your processes. You need someone who does the work, an hour of their time, and a willingness to write things down in plain English.
Get the trigger, steps, decisions, exceptions, and systems onto paper. That’s your automation-ready process document. Everything else - the flowcharts, the optimisation, the actual automation build - flows from there.
And if you get stuck? That’s what we’re here for. Sometimes it helps to have someone from outside the business ask the obvious questions that everyone inside has stopped noticing.