We first measure what each repetitive task actually costs, then automate in that order. With reversible actions, a complete log and a stop on anything unusual.
When you ask a team what they would automate, you get the list of annoying things. It is a useful list, but it is not the right list, because annoyance and cost do not overlap.
The task everybody complains about often consumes two hours a month and is annoying because it is unpleasant. The task consuming ten hours a week does not appear on the list, because it has become invisible: it has been done for years, it is part of the routine, and nobody perceives it as a problem any more.
That is why we start by measuring. A week in which people record what they do and how long it takes almost always changes the order of priorities, and the result surprises everybody, management included.
| Characteristic | Verdict | Why |
|---|---|---|
| Repeats often, with the same steps | Good candidate | Volume makes every second saved count, and fixed rules can be described completely |
| The rules are clear and can be written down | Good candidate | If you can explain the process to a new person in ten minutes, it can be automated |
| Human error has consequences | Good candidate | The gain is not only time, but the elimination of transcription errors |
| It happens at inconvenient hours | Good candidate | Overnight reports, weekend synchronisations, month end processing |
| It requires case by case judgement | Partial automation | We automate the preparation and leave the decision to a person. The hybrid works better than either extreme |
| The rules change monthly | Not yet | The automation would have to be rewritten constantly. Stabilise the process first |
| It happens a few times a year | No | The cost of building and maintaining exceeds the saving. A written procedure is better |
| The process should not exist at all | Remove it | The best automation. It happens more often than you would think: reports nobody reads, formal approvals |
The difference between a helpful automation and a dangerous one is not what it does when things go well, but what it does when something falls outside the pattern.
Every important action has to be undoable. An automation that deletes, sends or invoices irreversibly, with no way back, turns a logic error into a real incident with your customers.
In practice: actions are marked rather than deleted, messages go through a queue with a short delay in which they can be stopped, and financial operations require confirmation.
A case that does not match the rules must not be guessed at. The automation stops, flags the case and calls a person.
The alternative, a system trying to cope on its own, produces wrong decisions at scale. A hundred incorrectly issued invoices cost more than a hundred unissued ones, because the second situation is noticed immediately.
Every run recorded: what it received, what it decided, what it did, how long it took. Without that, the first question on any problem, meaning what happened on Tuesday, has no answer.
The log is both the evidence for an audit and the way you discover that the automation started working incorrectly three weeks ago.
People have to see what has run, what succeeded and what is waiting for intervention. An automation nobody can inspect becomes, within a few months, something the team is afraid to touch.
A simple dashboard with the recent runs and what needs attention solves that and builds confidence in the system.
People record what they do and how long it takes. Without that, prioritisation is an opinion, and the most insistent opinion wins.
Hours per year, multiplied by their real cost, compared against the cost of building and maintaining. We show you the threshold for each candidate.
Step by step, exceptions included. This is where the special cases known to one person and written down by nobody come to light.
The one with the best ratio. A clear success buys the team's confidence for the rest far better than a presentation does.
For a period, the automation and the person do the same work, and the results are compared. That is how differences are caught before they matter.
The team understands what the system does and how to intervene. Then we take the next one on the list.
An automation project most often fails for human reasons, not technical ones. If people believe the point is to replace them, you will never find out how the process really works, and the special cases, which are precisely the hard part, will go unmentioned. Tell them from the start what is being automated and why. In our projects, what disappeared was the part of the work nobody wanted anyway.
From measurement, not from impression. We ask the team to record for a week what they do and how long it takes. The result almost always surprises: the task everybody complains about consumes two hours a month, while the one nobody mentions consumes ten hours a week. We automate in the order the numbers give.
In the projects we have done, it has not happened. What disappears is the part of the work nobody wanted: copying data, checking files, sending the same messages. People end up doing the things you hired them for. It is worth telling the team this from the start, though, otherwise the project meets resistance and you lack exactly the information you need.
It is designed from the start on the assumption that it will. Every important action is reversible and recorded, decisions with large consequences ask for human confirmation, and any unusual case stops and calls a person instead of guessing. An automation that gets things wrong silently is worse than manual work.
For well chosen tasks, between three and nine months. We do the calculation beforehand, with the measured hours and their real cost, and show you the threshold. If payback exceeds two years, we tell you it is not worth it, even if it is technically possible.
Most of the time yes. The automation sits on top of the existing systems and uses them through their interfaces. Sometimes, though, we discover that the process itself is the problem, and automating it would mean doing faster something that should not be done at all. We tell you when that is the case.
The answer to that question usually produces the list of automations worth building, in the right order.