Every operations leader we talk to has a list.
It is usually informal, kept somewhere between a notes app and a recurring complaint in a Monday meeting. It contains the things the team does by hand that they believe a computer should be doing: the reconciliation, the copy-paste between systems, the report that someone rebuilds every month, the intake form that turns into six emails.
The list is almost never the problem. The ordering is.
Most organizations start with the item that generates the most complaints. That item is rarely the one that pays back first, and a first automation project that does not pay back is usually the last automation project the organization funds for a few years.
This article is about how to order the list honestly.
Why the Loudest Process Is the Wrong Place to Start
The process that annoys people most has a specific profile. It is visible, it is emotionally charged, and it is often complicated for reasons nobody has written down.
That last part is what kills the project.
A process generates complaints for two very different reasons:
It is repetitive and mechanical, and people resent doing it
It is full of judgment calls and exceptions, and people resent owning it
The first is a good automation candidate. The second is a bad one, and it is usually the louder of the two. Exception-heavy work feels like it should be automatable because the exceptions are invisible to everyone who does not do the job. They become visible about three weeks into the build, one at a time.
Starting there means the first project runs long, costs more than quoted, and produces a system the team works around. The organization concludes that automation does not work here. It does. The ordering was wrong.
The Four Signals That Actually Matter
A process is a good first candidate when four things are true at once.
1. It Runs on a Predictable Rhythm
Automation pays back per repetition. A process that runs 200 times a month returns the build cost quickly. A process that runs twice a quarter almost never does, however painful each instance is.
Count the repetitions before anything else. The number is usually smaller than the memory of the pain suggests.
2. The Rules Can Be Written Down
Ask the person who does the work to write the rules. Not the ideal rules, the actual ones, including what they do when the input is wrong.
If they can write them in an afternoon, the process is a candidate. If they say "it depends, let me show you," the process contains judgment that has never been made explicit, and the automation project is really a process-design project wearing a technical costume. That project is worth doing. It is not worth doing first.
3. The Inputs Arrive in a Consistent Shape
Automation is cheap when the data arrives in a form a system can read, and expensive when a human is currently doing the reading.
A CSV export from a known system is cheap
A form submission is cheap
A structured record in an existing database is cheap
A PDF from a vendor who changes their layout is expensive
An email whose meaning depends on who sent it is expensive
A phone call is a different project entirely
This is where AI genuinely changes the arithmetic, and it is also where it is most oversold. Language models are good at pulling structure out of messy inputs, which moves some of these items from expensive to merely moderate. They are not reliable enough to be the only thing standing between a messy input and a financial system. The useful pattern is AI as the reader, with a human confirming the output, not AI as the decision-maker.
4. Being Wrong Is Cheap and Visible
The first automation project should fail safely. If the process feeds payroll, contracts, or anything a regulator reads, the cost of a wrong output is high and the cost of proving correctness is higher.
Start where a mistake is caught the same day by the person who would have done the work anyway. This is the same instinct described in Where AI Saves Real Hours on a Small Dev Team: the reliable wins are local, mechanical, and easy to verify.
The Cost Nobody Counts
The build cost is the number everyone asks for. It is not the number that decides the outcome.
The costs that decide the outcome are:
The time the team spends explaining the process during the build
The time spent verifying the output during the first month
The ongoing cost of maintaining an integration against a system somebody else controls
The cost of the exception path, which will exist whether or not it was scoped
An automation that saves twelve hours a month and costs three hours a month to babysit is saving nine hours, not twelve. That is still a good project. It is a worse project than the one on the slide.
Count the babysitting. A candidate that looks marginal before babysitting is not a candidate.
A Ranking You Can Actually Run
For each item on the list, get four numbers and one letter.
Repetitions per month: count them, do not estimate them.
Minutes per repetition: time the person doing it, once.
Percentage of repetitions that hit an exception: ask the person, then add ten points, because they are underestimating.
Number of systems the data has to cross: one is easy. Two is a project. Four is a program.
Blast radius if the output is wrong: rate it A if a human catches it the same day, B if it surfaces in a week, C if it reaches a customer, a regulator, or a bank.
Then rank by annual hours saved, throw out anything rated C, and throw out anything above 30 percent exceptions. What survives at the top of that list is your first project.
It will usually not be the process anyone was complaining about. It will usually be something quiet, high-volume, and boring: the intake step, the weekly export, the status update that three people assemble by hand. Boring is the point. The first project's job is not to solve the hardest problem. It is to prove the mechanism, build the team's confidence in it, and earn the budget for the second one.
What This Looks Like in Practice
Consider a membership organization with a loud problem and a quiet one. The shape here is common enough that most operations leaders will recognize it.
The loud problem is renewals: grace periods, prorating, and a handful of legacy arrangements nobody wants to touch. Every one of those is a judgment call. Everyone wants it fixed, and it is the first thing anyone names.
The quiet problem is that every new member application gets retyped from a form into two systems and acknowledged with a hand-written email. Almost no judgment, a lot of typing, several hundred times a year.
The quiet one should go first. It scores better on all four signals, it fails safely, and it gives the team something they did not have before: a working example of a well-scoped automation inside their own operation. Renewals go second, and go better than they would have, because by then the exceptions have been written down.
Where the Build-vs-Buy Question Fits
Before building anything, check whether the process is common enough that someone already sells the answer. Most first automation candidates are not special, and a tool that fits is cheaper than a system that is yours.
The build case gets stronger as the process crosses systems, because crossing systems is exactly what off-the-shelf tools do worst. The full treatment of that boundary is in Build vs Buy: When a Custom App Beats a SaaS Subscription.
The short version: buy the step, build the seam.
A Simple Rule of Thumb
Automate the process people would not think to complain about, because they have stopped noticing how much time it takes.
The one they complain about is complicated. That is why they complain about it. Get to it second, once the exceptions are written down and the organization has seen the mechanism work.
Final Thoughts
The first automation project is not really a technical decision. It is a credibility decision.
Pick something that repeats often, has rules that can be written down, takes inputs a system can read, and fails cheaply. Count the babysitting cost before you commit. Rank the list by hours saved rather than by volume of complaint, and let the loud process wait its turn.
Organizations that do this end up with a second project, and a third. Organizations that start with the hardest thing on the list usually end up with a story about how they tried automation once.
If your team has a list like this and is trying to work out which item belongs at the top, this is exactly the kind of question our Operations Audit is built to answer. Book a short consult.
