I have seen a lot of automation projects, and the ones that failed rarely failed on the technology. They failed because they automated the wrong thing, or the right thing in a way nobody could live with. The ones that paid for themselves — often within weeks — had almost nothing in common technically. What they shared was how the work was chosen.
Start with the time, not the tool
The most useful question is not “what could we automate?” but “where does the time actually go?” Those are different questions with different answers. Ask people what they would automate and they name the task they dislike most. Ask them to track where a week goes and the answer is usually something duller and bigger: re-typing information from one system into another, chasing a status by email, assembling the same report every Monday, checking that a document has all its fields filled in.
So before anything is built, I do something unglamorous: I sit with the people doing the work, and we write down, for two weeks, what they spend time on. Not in detail — a line per task, a rough count. At the end there is nearly always one item that is far larger than anyone guessed. That is the candidate. Not the annoying task. The big one.
The three tests
A task is worth automating when it passes three tests:
- It happens often. Ten minutes a day is forty hours a year per person. Two hours once a quarter is not worth a project.
- It follows rules a colleague could write down. If the person doing it cannot explain when they do what, neither can a computer — and the explanation is the real work.
- A mistake is visible and cheap. Automate what you can check. Keep judgement calls with people (I wrote about this in the piece on trusting AI).
A task that passes all three is almost always cheap to automate and easy to trust. One that fails the second test usually needs a process fix before it needs software.
Pilot small, then decide
The cheapest way to find out whether an automation will be used is to build the smallest version that does real work, for one team, for a month. Not a platform. Not “phase one of the digital transformation”. One process, one group of people, a clear number to beat.
The pilot answers questions no plan can: does the input data actually look the way everyone assumed? What are the exceptions, and how many are there? Does the person whose job changes want it to change? Two of these will surprise you. Better to be surprised in month one for a few thousand euros than in month nine for a few hundred thousand.
At the end of the month, measure. Minutes saved per week, errors caught, backlog cleared — whatever the number was. If it did not move, stop, and be glad it was only a month. If it moved, you now have a business case that is not a projection but a fact, and expanding it is straightforward.
Why things nobody uses get built
Because the person who wanted the automation is not the person who has to use it. Because the demo used clean data and the real data is not clean. Because the exceptions were “edge cases” in the meeting and forty percent of the volume in practice. Because it asked people to work in a new tool instead of fitting the one they already lived in. Because nobody was responsible for it after go-live, so the first time it broke it stayed broken.
Every one of these is avoidable, and every one of them is a process decision rather than a technical one.
What good looks like
The best automation I have built for clients is nearly invisible. A document arrives and the relevant numbers are already in the system when someone opens it. A report is in the inbox on Monday morning without anyone assembling it. A request that used to take four emails takes one form and one click. Nobody talks about it as “the AI” or “the automation” — it is simply how the work is done now. That is the goal: not something impressive, something that quietly gives people their afternoons back.
If you suspect your team is losing hours to work a system should be doing, the two-week tally is a good place to start. I am happy to help you read it.