How to Choose Your First Process to Automate
Your first automation is not really about the process. It is about proving the operating model on something real. Here is how to choose a candidate that will survive contact with production.
The first process an organisation automates is rarely the one with the largest theoretical saving, and it should not be. The first process has a different job: proving that the integration path works, that the operating model holds, and that the people who will own the result trust it. Choose it for those reasons and the second process is dramatically easier. Choose it for the headline number and you will often spend nine months learning why the headline number was wrong.
Six criteria worth scoring
- 1Volume high enough to matter. The process should run often enough that a week of observation gives you a real sample. Something happening four times a month will take a year to prove anything, and the exceptions will not have shown themselves.
- 2Rules that can be written down. If the people running the process can articulate the decision logic, even messily, it can be encoded. If the honest answer is that they just know, you are looking at judgement rather than repetition, and that is a poor first candidate.
- 3Stable inputs. The formats, systems and upstream sources should not be mid-migration. Automating a process that feeds off a system due for replacement next quarter is building on a foundation somebody has already scheduled for demolition.
- 4Accessible data. Every system in scope should have a viable way in, whether an API, a database, a file drop or a robot. Confirm this during discovery rather than assuming it. Access approvals inside your own organisation are, reliably, the single most underestimated line in the plan.
- 5A named owner who wants it. Somebody must own the process, want it improved, and be available for the build. Automation imposed on a team that did not ask for it and does not trust it produces a workflow everybody routes around.
- 6Measurable today. You need a baseline: current cycle time, touch count, volume, error and rework rate. If you cannot measure it before, you cannot prove anything afterwards, and the business case becomes an argument rather than a calculation.
Score candidates against all six rather than optimising for one. A process that scores well on five and badly on one is usually a better first choice than a high-volume process with no owner.
Four kinds of process to avoid first
Some processes are perfectly good automation candidates but terrible first ones. The distinction matters, because rejecting them permanently is as much a mistake as starting with them.
- The company-wide process. Anything touching six departments has six sets of politics attached. The technical work is rarely the hard part, and a first project has no credibility to spend on negotiating a shared definition of done.
- The one nobody has documented in ten years. Undocumented is fine and normal. Undocumented and running on the knowledge of one person who is retiring in March is a discovery project wearing an automation project as a disguise.
- The heavily regulated one. Not because automation cannot meet the requirement, but because the approval cycle will dominate the timeline and the team will conclude that automation is slow, when what was slow was the compliance review.
- The one already scheduled for replacement. If the underlying system is being retired within a year, automate around it later. You will build twice.
The shape of a good first candidate
In practice, good first processes tend to look similar across very different organisations. They run daily or several times a week. They touch two or three systems, not eight. The rules fit on a page. They have a clear start trigger and an unambiguous finish. Somebody currently spends a meaningful part of their week on them and would rather not.
Supplier invoice capture and matching, employee onboarding across HR and IT, service request routing, and standard report assembly all fit this shape. None of them are glamorous. That is precisely the point: an unglamorous process that goes live in six weeks builds more organisational appetite than an ambitious one still in design review at Christmas.
The purpose of the first automation is to make the second one uncontroversial. Judge the candidate on how well it does that, not on the size of the saving.
Set the baseline before you touch anything
Before any build begins, record four numbers: how long the process takes end to end, how many human touches it involves, how many cases run through it per period, and how often it needs rework or correction.
Collect them by observation rather than by asking. Estimates given in a meeting are consistently wrong in both directions, and a baseline nobody trusts is worse than no baseline, because it turns every later conversation about benefit into a dispute about the starting figure. This is unglamorous work that takes a week. It is also the only thing standing between you and a benefits claim that cannot be defended.
Decide the exception policy before the build
The last thing to settle before building is what happens when a case does not fit. Which exceptions get handled automatically, which go to a person, who that person is, how quickly they are expected to respond, and what happens if they do not.
Teams that leave this until testing invariably discover that the exception path is half the work. Teams that decide it upfront find the build shorter, because the exception design usually simplifies the happy path as well: once you know precisely which cases you are not trying to handle automatically, the ones you are get considerably easier to specify.
