When a company decides to automate, the first candidate is usually whichever task makes the most noise — the one that generates complaints in the Monday meeting. But noise is not the same as cost. The task someone complains about most might cost two hours a month, while the one nobody mentions because "we have always done it this way" is eating forty.
The order matters, quite a lot, for two reasons:
- The first project decides whether there will be a second. Without a visible result early, the organisation stops believing in the idea.
- Automating a badly chosen process does not just fail to save time: it entrenches a bad process and makes it harder to change later.
Step 1: inventory, with a stopwatch
Get the people doing the work in the room, not just the people running it. For one week, have them note every repetitive task with three data points: how often they do it, how long it really takes, and which tools it touches.
That week of notes is worth more than any consultancy report. Tasks will surface that management did not know existed, and there is almost always at least one that surprises everybody.
Step 2: score each task on four axes
With the list in front of you, score 1 to 5 on each axis:
- Volume. How many times a month it repeats.
- Time. How long each instance takes.
- Cost of error. What happens when it goes wrong: fixed in a minute, or a lost customer?
- Clarity of rules. If two different people would do the same thing with the same case, score high. If it depends on somebody’s judgement, score low.
Volume times time gives you the hours — that is the size of the prize. Clarity of rules gives you the difficulty: a process with clear rules automates quickly and cheaply; one where everything "depends" first requires deciding what it depends on, which is a different piece of work.
Step 3: start in the right quadrant
Sort the tasks by monthly hours and keep the ones with clear rules. Your first candidate is in there. Not the most ambitious one: the one that returns the most hours with the least argument.
The first project is not there to show what the technology can do. It is there so that in two months nobody is debating whether it was worth it.
High-volume tasks with fuzzy rules are not discarded — they go in phase two, once the team trusts the system and is willing to sit down and define criteria.
The four mistakes that kill a first project
- Starting with the most complex thing to "show the potential". It takes months, nobody sees results and the project dies of boredom.
- Automating without measuring first. With no baseline there is no way to demonstrate the improvement, and the debate becomes a contest of impressions.
- Leaving out the people who do the work. If the system is designed by someone who never runs the task, half the exceptions will be missing.
- Automating a broken process. If the task should not exist, the answer is not to do it faster — it is to remove it. Automating waste only makes it more efficient.
What to expect from the first one
A well-chosen first flow is usually in production in two to four weeks and gives back between ten and thirty hours a month. Not spectacular on paper, but it is the kind of result that holds up and opens the door to the next one.
If you would rather skip the stopwatch week, we run that inventory ourselves as the first phase of the project, and the output is yours whether we continue or not.