Which Process to Automate First
Most companies automate the process that annoys them most. Four tests that find the one where automation actually pays back fastest.
When a company decides to automate something, the first candidate is almost always the process that generates the most complaining.
It is a reasonable instinct and it is usually wrong. The loudest process is loud because it is painful, and painful usually means messy, full of exceptions, and dependent on somebody's judgement. That is the hardest thing to automate and the slowest to pay back. Start there and the project takes four months, works partially, and convinces everyone that automation does not work here.
The first one should be chosen for a different reason: it should be the one that proves the idea quickly. Here are the four tests I use.
Test 1: how often does it happen
Multiply frequency by the number of people doing it. Not how annoying it is. How often.
Something that happens forty times a day across three people is worth more than something that happens twice a month, even when the twice-a-month task takes an entire afternoon and everyone hates it. Automation pays back per repetition, so repetition is the whole economics of it.
The rule of thumb: daily beats weekly, weekly beats monthly, and anything quarterly is almost never the right place to start.
Test 2: is it rules, or is it judgement
Write the process down as if you were training a new hire. If you can write it as steps and conditions, it is a rules process. If you find yourself writing "it depends" or "you get a feel for it", it is a judgement process.
Rules processes automate cleanly and predictably. Judgement processes can be supported, and modern tools handle far more of them than they did two years ago, but they take longer, need review, and are a bad first project because success is harder to point at.
Moving data between systems, generating documents, checking for missing information, sending the same follow-up, updating a record in two places: these are rules. Deciding which supplier to use, pricing a non-standard job, judging whether a complaint needs the boss: these are not, at least not first.
Test 3: do the inputs arrive in the same shape
This is the test people skip, and it is the one that kills projects mid-build.
If the information arrives as a structured file, a form, an email in a consistent format, or a record in a system, you are fine. If it arrives as a photograph of a delivery note, a voice message, or a PDF whose layout changes depending on which supplier sent it, the work is much bigger than it looks, because most of the build is then about interpreting the input rather than doing the task.
That work is entirely doable and often worth it. Just not first.
Test 4: does somebody actually want it fixed
Name the person who does this today and will use whatever replaces it. Ask if they want it changed.
If there is no name, the process belongs to nobody and the automation will belong to nobody. If the person is defensive about it, you have a people problem to solve before a software problem, and software will not solve it.
The best first projects usually come from someone saying a specific sentence: every morning I copy these numbers from here into there. That person will test it honestly, tell you what is wrong, and tell colleagues when it works.
Score three candidates, not ten
Take the three processes you were already thinking about and mark each out of four. Most of the time one of them wins clearly, and it is frequently not the one that started the conversation.
The one that scores four is your first project. The ones that score two or three are not bad ideas, they are second and third, and they get easier once the first one exists, because the connections and the access are already in place.
Build the simplest useful version
Once you have picked, resist the version with everything in it.
The first build should do the main path and nothing else. Not the edge cases, not the reporting, not the second department that could also use it eventually. The main path, in production, being used by a real person within weeks.
Two reasons. You find out quickly whether it actually helps, which no specification can tell you. And the edge cases you were planning to build are often not the edge cases that show up, so half of that work would have been thrown away.
Everything gets added after, on evidence.
What tends to work first
The reliable starting points, across very different businesses, are dull and similar: data moved between two systems that do not talk, a document generated from information that already exists, a status that a customer currently has to phone to ask about, and a notification when something has not happened that should have.
What tends not to work first is anything that requires the whole company to change how it works on the same day, and anything where nobody can tell you what the current process actually is.
The five-minute version
Pick the thing that happens most often, that follows rules, whose inputs look the same every time, and that one named person wants fixed. Build the smallest version that does the main path. Put it in front of that person within weeks, not months.
If you want a second opinion on which of your three candidates is the right one, that is a short conversation and it does not need a proposal. Tell me one process you want to fix and how often it happens.
