Map the manual process before you automate it

Automation sells itself on speed, and speed is tempting. It’s also the wrong thing to chase first. If the manual process is a muddle, all automation does is run the muddle faster.

So before anyone writes code or sets up a workflow tool, map what actually happens. Not what the policy document says. Not what the manager reckons happens. What people do on an ordinary busy day.

The gap between those versions is bigger than anyone expects, and it’s worth understanding why it exists, because it’s nobody’s failure. Processes accrete. The official version was true once, maybe at half the current headcount, and then reality intervened one small patch at a time: a customer who needed special handling, a step added after something went wrong in 2021, a workaround invented while a system was down that simply never stopped. Each patch made sense on the day. Nobody wrote any of them down, because they were temporary. Five years later the documented process describes a business that no longer exists, and the actual process lives in the combined habits of the people running it. Automating the documented version means automating fiction.

The hidden process

Most manual workflows come in two versions. There’s the official one, which is tidy: request, review, approve, done. Then there’s the real one, full of side messages, half-filled fields, exceptions, corrections, reminders, and calls someone makes because they happen to know that customer or that job’s history.

That second version is where automation projects live or die. Ignore it and your staff will quietly keep doing all their unofficial work around the shiny new system.

Here’s what that looks like in practice. A wholesale business automates order processing based on the official flow: order arrives, credit check, pick, dispatch, invoice. Goes live, and within a week the exceptions surface. Three big customers phone their orders through and always have; the system has no entry point for a phone call. The credit check auto-blocks a 15-year customer who always pays late and always pays, and the sales manager overrides it with an email, which the system can’t see. The warehouse holds Friday-afternoon orders for Monday because the courier’s last pickup is 3pm, knowledge that lived in one bloke’s head and nowhere else. None of this was in the workshop, because the workshop asked how the process works and everyone described the official version in good faith. Two months later the “automated” process has a shadow spreadsheet tracking all the cases the system can’t hold, and the business is running two processes instead of one.

What to capture

A useful map answers plain questions. Who kicks the work off? What information do they need? Which systems get touched? Where do the files end up? Who signs off? What holds things up? Which exceptions keep cropping up? What has to be recorded for audit or compliance?

It doesn’t need to be a pretty diagram. It needs to be honest, and honesty takes a particular method: watch the work, don’t survey it. Sit with the person doing the job for a morning and write down what they actually touch. Every “hang on, I just need to check something with Karen” is a process step that no workshop would ever have surfaced. Ask for the last ten times the process ran, and trace them individually; if three of the ten took a detour, your exception rate is 30%, not the “rare” everyone estimated. And ask the person the two magic questions: what do you do when it goes wrong, and what do you know that a new hire wouldn’t? The answers to those two are usually the whole hidden process, dictated for free.

Find the judgement points

Some steps are pure admin. Once the rules are clear, you can automate them safely. Other steps need a person to weigh things up: approving a risky job, reading a contract clause, deciding whether a customer’s exception is fair, checking safety evidence.

Good workflow automation leaves the judgement with the human and strips out the repeat handling around it. The system gathers the context, routes the request, runs the simple checks and keeps the record. The person still makes the call.

The mapping exercise is where you find out which steps are which, and the answers surprise people in both directions. Steps everyone assumed needed judgement often turn out to be rules in disguise: “I just know which jobs need the senior estimator” decomposes, on inspection, into three checkable conditions about value, site type and customer history. And steps everyone assumed were mechanical turn out to carry judgement: the admin who “just types up the quotes” is quietly correcting unit prices from memory, and automating her typing without capturing her correcting removes an error filter nobody knew existed. That’s the single most dangerous automation mistake, deleting an invisible safeguard, and process mapping is the only reliable way to spot it before it’s gone.

Do not automate every exception

An exception that turns up once a year probably doesn’t warrant custom logic. Route it to a person with a note and move on. An exception that turns up every week isn’t an exception, it’s part of the process, so design it properly.

Drawing that line is what keeps an early automation project from collapsing under its own complexity. The maths is blunt: handling the common path plus the frequent exceptions might be 70% of a realistic build’s effort, and chasing the long tail of rare cases is where the remaining budget triples. So don’t chase it. Build a good escape hatch instead, a queue where the weird cases land with their context attached, visible and waiting for a human, exactly the same pattern that makes integrations trustworthy. An automation that handles 85% of volume flawlessly and hands the rest to a person gracefully beats one that attempts 100% and jams weirdly on the edge cases, every time. And occasionally the map hands you a better prize: an exception that exists only because of an upstream mess, which you can delete at the source instead of automating at all.

Keep the mapping bounded, though, because the exercise has its own failure mode: the business that maps for six months and builds nothing. A useful map of one process takes a few days, a week if the process is properly tangled. If the mapping is still going after a month, it’s become procrastination with sticky notes, usually because the map has quietly expanded from one process to all of them. Map the process you’re about to fix, fix it, and let the next map wait its turn.

Build from the map

Once the process is out in the open, the build gets a lot clearer. Forms can demand the required fields. Integrations can kill the duplicate entry. Notifications can replace the chasing. Dashboards can show real status instead of guesswork. Audit logs can capture who did what and why.

The map also does quieter work. It gives you the baseline numbers, how long things take now, how often they go wrong, which makes the after-state measurable instead of vibes. It sharpens the quote, because a scoped build against a real map carries far fewer of the mid-project surprises that blow budgets; when we scope automation work, the first question is always whether the map exists, and it’s why we’d rather see a messy honest map than a beautiful official one. And it builds the team’s buy-in before a single screen exists, because the people who helped draw it can see their real work in it, exceptions, workarounds, Karen and all.

The automation projects that work aren’t the ones with the most moving parts. They’re the ones where staff look at the design, recognise their own work in it, and then watch the pointless steps disappear. If there’s a process in your business everyone complains about but nobody can quite describe, that’s the tell. Tell us which one it is and we’ll help you map it properly, including the honest possibility that the map shows you a fix that doesn’t need us at all.