Every company runs on a set of undocumented manual bridges. An export from one system. A spreadsheet. A check somebody does from memory. An import into another system. None of them appear on an org chart, and together they consume an astonishing amount of time.
The cost is invisible because it is distributed. Nobody spends all day copying data between systems. But eleven people spend forty minutes each, every day, and that is a full-time role nobody budgeted for.
Why this work is where errors live
Manual transcription between systems is precisely the task humans are worst at. It is repetitive enough to disengage attention and detailed enough that mistakes matter. It reliably produces a background rate of errors that the organisation absorbs as normal.
It is also where institutional knowledge goes to hide. The rules governing these bridges — which records to skip, how to handle the odd cases, what to do when the totals disagree — usually exist only as habit, in the head of the person who has done it longest. When they are on holiday, the process degrades. When they leave, it breaks.
Map before you automate
The single most common failure in automation projects is automating the documented process rather than the real one.
The documented process is what the policy says. The real process is what people actually do, including the exceptions they have quietly absorbed for years. These are never the same, and the difference is precisely the part that matters.
So: watch it happen. Sit with the person doing the work. Ask "what do you do when…" until you run out of questions. Write down every rule, including the ones that sound trivial. Then read it back to them and let them correct you — they are the authority, not the document.
This phase takes longer than anyone estimates. Compressing it is the most reliable way to build an automation that handles the happy path and quietly mangles everything else.
Keep the checks, remove the typing
The instinct when automating is to remove steps. The better instinct is to distinguish between two kinds of step.
Judgement steps exist because someone has to decide something. They are usually the reason the process is trusted. Keep them.
Transcription steps exist because two systems do not talk to each other. They add no information and consume most of the time. Remove them.
An approval that used to require exporting a file, checking it, and re-entering the result becomes: a notification in the tool the approver already uses, showing the relevant data, with an approve/reject action. The judgement is intact. The forty minutes are gone.
Fail loudly
An automation that fails silently is worse than the manual process it replaced, because the organisation has stopped watching.
Every workflow needs, without exception:
- Validation on the way in. Records that do not match the schema are quarantined, not dropped.
- Idempotency. Running the same operation twice must not produce two results. Retries are inevitable; duplicated invoices should not be.
- Retries with backoff. Transient failures are the common case, not the exception.
- Alerting to a named person. Not a shared inbox, not a dashboard nobody opens. A person, by name, agreed at handover.
- An audit trail. What ran, what it did, what it skipped and why.
The quarantine mechanism is the one teams most often skip and most often regret. Without it, bad records either break the run or vanish — and vanishing is worse, because it is discovered months later during a reconciliation.
Do you actually need AI for this?
Often, no — and it is worth saying so plainly, because the current enthusiasm pushes in the other direction.
A large share of manual work is fully deterministic: if this field, then that action. That is better served by a plain, testable integration. It is cheaper to build, cheaper to run, easier to debug, and it behaves identically every time.
Reserve AI for the genuinely fuzzy steps: unstructured input that needs to become structured data, classification where the rules cannot be enumerated, extraction from documents that vary in layout. Those are real problems that rules cannot solve well.
Using a language model to decide whether a number is greater than a threshold is not innovation. It is an expensive way to be occasionally wrong about arithmetic.
One process at a time
Automation programmes fail in a characteristic way: four workflows started in parallel, none finished, no owner for any of them, and a general sense that the initiative did not work.
Finish one. Hand it over. Confirm it is running unattended and someone owns it. Then start the next.
This is slower on paper and dramatically faster in practice, because a finished automation continues to pay while the next one is being built — and because the first one teaches you things about your own systems that no amount of planning would have.