The first automation a company builds decides whether there is a second one. Choose something visible and hard, and a failure becomes the story everyone remembers. Choose something dull and well understood, and you buy the credibility to attempt the harder thing later.
The instinct is to start with whatever is most annoying. That is usually the wrong candidate, because annoying work is often annoying precisely because it involves judgement nobody has ever written down.
The test that predicts success
Could you explain this task to a competent new starter in one page of writing, such that they would do it correctly without asking you anything? If yes, it is ready. If no, the honest first deliverable is that page, not software.
This test is more reliable than volume, cost or enthusiasm, because it detects the thing that actually breaks automation projects: a process that exists only in somebody’s head, with exceptions nobody has enumerated.
What travels well
- Moving structured data between two systems that were never designed to talk to each other.
- Document intake, classification and filing where the categories are already defined.
- Reconciliation work with a clear definition of a match and a clear exception path.
- Status chasing, reminders and routine follow-up that nobody enjoys and everybody postpones.
- Report assembly where the inputs are fixed and only the numbers change.
What resists it
Low-volume work rarely repays the build. Work requiring a judgement priced on instinct resists it because there is no rule to encode. And anything where the rules change faster than the documentation can keep up will produce a system that is quietly wrong within months, which is worse than one that is obviously broken.
The middle category causes most of the disappointment. Processes that look mechanical but hide a decision somebody has been making silently for years, without ever writing it down.
David Kwon, Head of Automation, Engineered With AI
Sequencing the roadmap
Order candidates by how well documented they already are, not by how much time they consume. A well-understood process taking three hours a week is a better first project than a chaotic one taking fifteen, because it will finish, it will work, and it will produce the internal evidence needed to fund the second one.
Measure the manual baseline before you build
Time the current process and record its error rate first. This sounds bureaucratic and settles the only argument that matters later, which is whether the new system is genuinely better than what it replaced. Without a baseline, the assessment collapses into impressions, and impressions are shaped by the failures people remember rather than by the volume that went through cleanly.
Where a person should stay involved
Autonomy is a design decision rather than a goal. A system that prepares the work and waits for approval captures most of the time saving with almost none of the risk, and it is frequently the right permanent design rather than a cautious first step. The projects that get switched off are the ones granted authority over decisions that carry a real cost of being wrong.
For how this plays out by sector, the automation index covers the processes worth automating in specific industries and the ones that quietly are not.
Running the first project so a second one gets funded
Scope the first build so it can be finished inside a few weeks and assessed against a number agreed beforehand. Long first projects fail politically even when they succeed technically, because sponsors lose patience before the evidence arrives and the work becomes something to defend rather than something to extend.
Pick one process, one team, and one measure. Resist the pull to generalise the system while building it, since a design intended to cover four future cases usually serves the present one badly and the future ones never arrive in the shape anyone predicted.
Who has to be in the room
The person who currently does the work matters more than the person who sponsors the project. They hold the exceptions, and the exceptions are what determine whether the system survives its first month. Automation projects that are scoped entirely with managers tend to produce something that handles the described process well and the actual process poorly.
It also matters for adoption. A process automated around somebody rather than with them tends to acquire a quiet manual workaround, and the workaround is invisible in every report until it is the only thing keeping the operation running.
Not sure what to start with?
Describe the work eating the most hours and we will tell you honestly whether it is a good first automation or whether something quieter would pay back faster.
