Document the Process Before You Automate It

The most useful automation tool I know is a blank page. Before you build anything, document the process you are about to automate: every step, every exception, every place a human quietly fixes things without telling anyone. That one page decides whether your automation becomes an asset or an expensive way to make mistakes faster.

Documenting first is the step almost everyone skips, because building is more fun than writing. So this article covers why the order matters, what happens when you get it wrong, and a one-page format you can finish this week.

Why document the process before you automate it

Here is the uncomfortable truth: the process in your head is not the process that actually happens. In every business I have sat with, the two versions differ. Sales adds a step nobody mentioned. Accounts skips one that stopped making sense years ago. Meanwhile, someone re-types data between two systems because that is simply how it has always worked.

When you document the process, you surface all of that while it still costs nothing. On paper, a wrong assumption is a thirty-second fix. Inside a built workflow, however, the same assumption becomes a rebuild, and usually a quiet loss of trust in the whole system.

Think of the page as a specification. You would not ask a builder to start on a house without drawings. Yet most automation requests arrive as one sentence and a feeling.

Automating a broken process makes it worse, faster

A broken manual process fails gently. People notice something odd, patch it on the fly, and never mention it again. In fact, that quiet human patching is often the only thing holding the process together.

Automation removes the human, so it removes the patching too. The same broken logic now runs every time, at speed, with nobody glancing at the output. You did not get a better process. Instead, you got the old process at maximum speed.

Picture a simple example: automatic payment reminders. If your manual habit quietly skips the two clients on payment plans, the automation will not know that. On day one it emails both of them a late notice, and you spend the afternoon apologising. The process was broken before; now it is broken at scale, in writing, with your logo on it.

This is the warning I give every business that arrives excited to automate: automation amplifies whatever you feed it. Feed it a documented, tested process and it compounds value, which is the argument I made in automations are assets. Feed it a mess and it industrialises the mess.

How to document the process on one page

Forget process-mapping software and swim-lane diagrams for now. One page per process is the standard I hold to, and it has five parts:

1. The trigger. What starts this process? An enquiry arrives, an invoice reaches fourteen days overdue, a job changes to complete.
2. The steps, as they really happen. Follow one live example from start to finish and write down what people actually do, not what the manual claims. Shadow the person who runs it, because they will do three things they forgot to tell you about.
3. The decisions and exceptions. Every “unless” and “except when”. These branches are where automations break, so each one earns its own line.
4. The systems and data. Which tools you touch, what goes in, what comes out, and where someone types the same data twice.
5. The owner and the definition of done. One name, plus one sentence describing what finished looks like.

If it does not fit on a page, you have found two processes, so split them up. The discipline matters more than the format. After all, a standard operating procedure is just this page, kept somewhere the whole team can find it.

The test: could a new hire run it tomorrow?

Once you document the process, apply a single test. Could a capable new hire, with no context, follow the page and get the right result? If yes, the process is ready to automate. If no, the gaps you just found are the exact places your automation would have failed in production.

A new hire and an automation have a surprising amount in common. Neither has context. Neither knows that Deb in accounts handles the tricky ones her own way. Both do exactly what the page says and nothing more.

This is also the moment to improve the thing itself. Remove the step that exists for a reason nobody remembers. Merge the two approvals that always agree. Automation comes third: document, then fix, then build. Once you can describe the build in one sentence, the approach I covered in how to build custom apps without code, that sentence writes itself straight off the page.

The document is part of the asset

When I wrote that automations are assets, I made the point that documentation is what makes a system transferable. The documentation starts before the build, not after it. The process page records why the automation does what it does, which is precisely what a new team member, a contractor, or an eventual buyer of your business needs to see.

So before you automate anything this month, spend an hour with the person who runs your messiest process and document the process end to end. That hour usually pays for itself before you build a single workflow, because writing it down exposes the fix. And if you would like a second pair of eyes on what to automate first, book a call and bring the page.