Most automation projects that fail don’t fail because the technology couldn’t do the job. They fail because nobody had an accurate picture of the process before they started building.
You can’t automate what you don’t understand — and most businesses understand their own processes less well than they think. Skip this step and you don’t get an automation, you get a faster, more confident version of the same mess.
The gap between the manual and reality
Ask someone to describe how a process works and you’ll usually get the tidy version — the one from the induction document, or the one they believe they’re supposed to follow. Watch them actually do it, and you’ll see workarounds, judgement calls, and exceptions that never made it into any document.
That gap is where automations go wrong. Build a workflow around the tidy version of a process and it’ll handle the easy 80% just fine, then fall over on the 20% that was never written down — usually within the first few weeks of going live.
Watch, don’t just ask
The most useful hour you can spend before automating anything is sitting next to the person who does the work and watching them do it. Not interviewing them about it afterwards — watching it happen in real time.
People are surprisingly bad at describing their own processes accurately, mostly because so much of the judgement involved has become unconscious by the time they’re experienced at the job. Note every decision point: what makes them choose one option over another, what they check before moving on, what they do when something looks slightly off.
Write down the exceptions, not just the happy path
Every process has a clean version and a messy version. The clean version is “client fills in the form, we send the contract.” The messy version includes what happens when the form’s missing a field, when the client goes quiet for two weeks, or when two systems disagree about the same customer’s details.
An automation that only handles the clean version isn’t finished — it’s a demo. The exceptions are exactly where manual work tends to pile up, which makes them the most valuable part to get right, and the easiest part to leave out if you’re mapping in a hurry.
Get it down somewhere everyone can see
The map itself doesn’t need to be sophisticated. Numbered steps, a simple flowchart, even a shared document with a few screenshots — what matters is that it’s accurate and visible, so whoever builds the automation is building the real process rather than someone’s best guess at it.
Doing this properly also tends to surface something useful before a single tool gets chosen: the actual bottleneck usually turns out to sit somewhere different to where you assumed it was when you started.
Then pick the tool
Once the process is mapped properly, tool choice gets a lot simpler. Some steps just need a straightforward rule-based workflow — if this, then that. Others need something closer to judgement, like reading a message and working out what it actually means rather than matching a keyword, which is where AI earns its place instead of being bolted on for the sake of it.
Skipping straight to tool selection is how businesses end up with automation that technically runs but doesn’t fix anything. The map isn’t the exciting part of the project. It’s the part that decides whether the rest of it works.
It’s also the first thing we do with every Foundation Client Program pilot, before we touch a single tool.