.png)
What to Automate First
Every automation workshop I have run starts the same way. The whiteboard fills up with the impressive ideas first. Demand forecasting. Dynamic pricing. A chatbot that knows everything. Meanwhile, the person who organised the meeting spends forty minutes every morning copying numbers from three portals into a spreadsheet, and nobody writes that down.
Guess which one pays.
The arithmetic is boring, which is exactly the point. A 15-minute task done daily eats about 60 hours a year. Five of those, and one person loses almost two months of working time to chores a script could do. The impressive task, the one that takes two hours but happens once a month, adds up to 24 hours a year. Automating it feels like progress and buys you three days.
Volume beats drama. The boring column is where the payback lives.
So the first rule of picking automation projects: frequency beats drama. Automation earns its keep through repetition. A small saving on a daily task outruns a large saving on a rare one, every time.
This is also why automation projects should be small. If a task costs an hour a day, an automation that takes two weeks to build repays itself in under two months. At that scale you can afford to be wrong, try again, and still come out ahead within the quarter.
The second rule is about judgment. Tasks split into two kinds: those with clear rules and those that need a human call. If you can write the steps on one page and a new employee could follow them without asking questions, the task automates cleanly. If every third case needs interpretation, you are not automating a task, you are trying to bottle a person.
Put the two rules on two axes and you get a map.
Start in the top left. Visit the top right with assistance, not replacement.
Top left, frequent with clear rules: automate fully, this quarter. The morning numbers, invoice matching, report assembly, moving data from system A to system B.
Top right, frequent but needing judgment: do not replace the human, arm them. Let software read the incoming email, pull up the customer record, and draft an answer, and let a person approve it. This is where AI earns its place, preparing decisions rather than making them.
Bottom left, rare with clear rules: a checklist or a template is enough. Automating the annual license renewal saves an hour a year and costs a week to build. Write it down instead.
Bottom right, rare and full of judgment: leave it with people. That quadrant has a name. It is called the job.
The most common mistake I see is starting in the wrong corner because the wrong corner demos better. An AI that forecasts demand is a better story at the management meeting than a script that moves numbers between systems. But the script pays back in five weeks and builds the trust you need for the bigger projects.
A first win also changes behaviour. Once the morning report writes itself, people start bringing you their own boring tasks, and the pipeline of good automation candidates fills without another workshop.
The second mistake is chasing 100 percent. The first 90 percent of cases follow rules. The last 10 percent are weird, and handling the weird cases in software costs more than the whole rest of the project. Automate the 90, route the 10 to a person, and make the routing obvious. A task that goes from 40 minutes to 4 is a success even though a human still touches it.
Where does modern AI change this picture? In one specific way. It moves tasks from the judgment column into the rules column. Reading a supplier email and extracting the order used to need a person, because the input was messy. Now the messy reading is mechanical and the rules behind it can run. The map stays the same. The population of the top left corner grows.
Be careful with the opposite move too. Do not hand a rules task to an AI model when a plain script does it. A script is cheaper, faster, and does the same thing every time. AI belongs where the input is messy, not where a schedule and an if-statement would do.
If you want to do this systematically, the exercise takes a week. Have every team list its recurring tasks, estimate minutes and frequency, and mark whether the steps follow rules. Multiply, sort, and the top of the list is your automation roadmap. No consultants required for that part, including us.
The forty-minute morning routine from the workshop became a scheduled job that runs before anyone arrives. It repaid its build cost in about five weeks. Nobody will ever give a conference talk about it. The person who used to do it now spends the morning on customers, and that was the entire point.
Questions I hear about automation
What tasks should a company automate first?
Frequent tasks with clear rules: daily data transfers, report assembly, invoice matching, standard confirmations. They carry the highest yearly hour counts and the lowest risk. Rare or judgment-heavy tasks come later, if at all.
What is a realistic payback period for a small automation?
Weeks, not years. A task that costs 30 to 60 minutes a day and takes one or two weeks to automate typically repays the build within two months. If the projected payback is longer than a year, pick a different task.
Which tasks should not be automated?
Rare tasks that need judgment, and the last 10 percent of weird cases inside otherwise regular tasks. Automate the regular 90 percent and route exceptions to a person. Forcing full coverage costs more than the entire rest of the project.
How does AI change what can be automated?
AI moves messy-input tasks, like reading emails, PDFs, and scanned documents, from the judgment column into the rules column. The selection logic stays the same. The pool of tasks that qualify for full automation gets bigger.
