"Let's automate this process" — this sentence often comes up without anyone ever having written down what actually happens today, by hand, step by step. This is one of the most common reasons an automation project slips, goes over budget, or ends up not doing what's actually needed: the problem isn't the automation technology — it's that the process behind it was never clearly articulated.

Why you can't automate what no one can precisely describe

To automate a process, the system needs to know exactly, without exception, what to do in every situation — while in reality, most "manual" processes run flexibly, with unspoken exceptions and human judgment. When someone says "this is simple, you just type the data into the system," they usually forget to mention the ten exceptions they handle automatically in their head — what to do if data is missing, what to do if two systems contradict each other, who to notify if something's urgent.

This is the gap that causes so many automation projects to work "almost fine," then get stuck at the first real exception — because the developer automated exactly what they were told, but what they were told didn't include the hidden rules the colleague currently doing the process manually carries in their head, without even realizing it counts as a rule at all.

Documentation that isn't bureaucracy, it's discovery

Good process documentation isn't about writing a formal policy no one reads — it's a simple practice: sit down with whoever currently does the process by hand, and ask them to show exactly what they do, with a specific, real case — not explain it in theory, but actually perform the steps while you watch and ask questions. This practice almost always uncovers steps and exceptions the colleague would have simply left out if explaining it in theory — not deliberately, just because it's so routine to them they don't even think of it as a separate step.

This process often leads to surprising discoveries on its own: it turns out a process runs in three different versions in parallel, because three different colleagues do it three different ways; or a step everyone thought was important is actually never used by anyone; or an exception thought to be rare actually happens in a third of cases. These discoveries are valuable on their own — regardless of whether you end up automating the process, or just simplifying and standardizing it.

What should go in the document — and what's enough

You don't need to draw a formal, official flowchart to produce useful documentation. A simple, step-by-step list — what's the first step, what kicks off the process, what decision points exist, and at each decision point, what happens in one case versus the other — is already enough for a developer or automation specialist to understand exactly what they're building on. The most important element many people leave out is the list of exceptions: what happens if a piece of data is missing, what happens if two sources contradict each other, what happens if the customer doesn't respond within a given time.

The most expensive automation mistake isn't that the technology doesn't work — it's that it automates exactly the process it was told about, which was never actually the same as what really happens.

Practical advice: before starting any automation project, spend an hour or two walking through and writing down the process, with a real case, including every exception. This time pays off disproportionately later — because an automation built on a well-documented process gets stuck at the first real exceptional situation far less often than one built on just a short, theoretical description.

If you'd like to automate a process but haven't yet precisely written down what actually happens now, we can help you think it through and document it — before a single line of code gets written.