The best first automation is high-volume, stable, low-consequence when wrong, and touches systems that already have an API. Choosing the most painful process first is the most common and most expensive mistake.
Four questions, in order
Score each candidate process against these before considering anything else.
- Volume. How many times per week? Below roughly ten, the engineering rarely pays back, however annoying the task is.
- Stability. Has the process changed in the last six months? A process still being redesigned will outrun any automation built against it.
- Consequence. What happens if it is done wrong and nobody notices for a day? This decides how much verification the build needs, and therefore its true cost.
- Access. Do the systems involved have APIs? A process that requires driving someone's user interface is several times more expensive to build and far more fragile.
Three bad first candidates
The most painful process
It is usually painful because it is complicated, exception-heavy and politically contested. It is the worst possible place to learn what your organisation's automation actually requires.
The process nobody owns
Without an owner there is nobody to decide what the correct behaviour is at the edges, and the edges are the whole job. The project stalls in definition.
The process about to be replaced
If the underlying system is being changed within a year, automate around it and you will build it twice.
Design for the exceptions, because they are the work
Nearly every automation that quietly fails does so because the happy path was built and the exception path was assumed. Before building, ask the person who currently does the task what percentage of cases are unusual. The answer is rarely below fifteen percent, and it is where their expertise actually lives.
The design consequence: an automation that handles eighty-five percent cleanly and routes the rest to a person with full context is a success. One that attempts all cases and gets the difficult ones subtly wrong is a liability.
Measure before, or you cannot claim after
Record how long the task takes today, how often it is done, and how often it is currently done wrong. Without a baseline the improvement is an anecdote, and the next automation is harder to justify.
AI & Intelligent Automation
Most useful AI work is not a model. It is retrieval, tooling, evaluation and the boring parts of integration done properly. That is the part we build.
AI & Intelligent Automation