Article
The Manual Work Audit
Four questions to find out what one process is really costing you — before anyone tries to sell you automation.
Most automation decisions get made backwards. Someone sees a demo, gets excited, and then goes looking for a process to apply it to. The result is a pilot that impresses everyone in the room and changes nothing in the business.
Do it in the other order. Pick your single highest-volume repetitive process — the one someone would name immediately if you asked which task eats the day — and answer these four questions honestly.
Question one — How many times a day does it happen?
Count for a week if you don't know. Nearly everyone underestimates this by half. Include the instances handled by people who weren't supposed to be handling them.
Question two — How long does one instance actually take?
Not the typing — the whole thing. Reading it, working out what it means, finding the information, checking the information, replying, logging it, and the cost of being interrupted to do it. Ten minutes is typical for something that feels like two.
Question three — What does that cost?
Use the fully loaded hourly cost of whoever does the work — salary plus roughly 30% for employer costs.
How many times the task happens
End to end, including the interruption
Salary plus ~30% employer costs
21 is the usual figure
70–85% is typical
Hours consumed / month
420
Full-time people equivalent
2.6
Of which is lookup, not judgement
£79,380
Annual cost of this one process
£105,840
This is worth solving.
You are effectively employing 2.6 full-time people to do lookup and formatting. A build at this scale typically pays back inside a year.
Nothing is sent anywhere. The numbers stay in your browser. Verdict bands are calculated in GBP; $, € and AED figures are converted approximately (AED ÷ 4.7, $ and € × 0.79) for that comparison only — the amounts shown above always stay in your selected currency.
Question four — How much of it is genuinely judgement?
This is the question that decides everything else. Take twenty real instances and mark each one: did it need a human being's judgement, or was it lookup and formatting?
In most operational processes, 70–85% turns out to be lookup. That share is what can be automated. The remainder — the exception, the angry customer, the case with commercial consequences — is what your team should have been spending their day on all along.
Two things to insist on before anyone writes code
An evaluation set, built first. If you cannot measure whether the system got better or worse after a change, you are not engineering — you are guessing. On the largest system I've run, roughly a third of the changes that felt like improvements measurably weren't. We only knew because there was a scored test set to check against.
An escalation path, designed before the happy path. Every system worth having here is a human–machine system. The ones that fail are the ones where the machine had no way to say “I don't know” — so it answered anyway, fluently and wrongly, and trust was gone after the first customer noticed.
Be suspicious of anyone who shows you a demo without showing you what happens when it's wrong.