Every week, someone asks us to automate a process. Nine times out of ten, the first thing we do is ask to see the process documented. Nine times out of ten, it isn’t.
This is where most automation projects die — not in the build, not in the tools, but in the gap between how people think a process works and how it actually works. You can’t automate what you haven’t mapped. And mapping a process properly is harder than it sounds, because the people closest to it are usually the least able to see it clearly.
You can’t automate what you haven’t mapped. And most processes have never been mapped — only performed.
The real problem with “just automate it”
When someone asks us to automate a process, they usually have a specific pain point in mind. A report that takes three hours every week. A form that emails someone who copies it into a spreadsheet who sends it to someone else. A task that requires remembering to check something every day.
The instinct is to look at that pain point and build a solution around it. But pain points are symptoms. The process that produces them — the full chain of decisions, exceptions, handoffs, and workarounds — is the actual thing that needs to be understood before anything gets built.
What mapping actually looks like
A proper process map answers five questions: What triggers this? What happens next, every time? What are the exceptions? Who decides what? What does done look like? Most organizations can answer the first question and the last one. The middle three are where the surprises live.
We’ve walked into automations where the exceptions turned out to be 40% of the cases. We’ve seen trigger conditions that sounded simple and had seventeen edge cases nobody had written down. We’ve built systems around a process only to find out halfway through that two people on the team did it differently and nobody had agreed on which way was right.
The exceptions aren’t edge cases. In most processes, they are the process.
What to do instead
Before you touch a tool — any tool — spend a week logging every instance of the process as it actually happens. Not as it’s supposed to happen. As it happens. Who does what, what decisions they make, what they do when something unexpected comes up.
Then map it. A flowchart, a table, a wall of sticky notes — the format doesn’t matter. What matters is that you can look at it and say: this is what we’re actually automating.
Only then does the tool choice become obvious. Usually it’s simpler than you thought. Sometimes the process doesn’t need automation at all — it needs redesign.