Here is the direct answer: automation is not always the right move. Seven situations make it actively counterproductive. Knowing them saves you time, money, and the specific humiliation of explaining to your team why the automation you spent six weeks building made everything slower.
I have been implementing automation since 2018. In 100+ projects, more than a handful of early conversations ended with me recommending the client not automate yet. That advice is worth more than a €10,000 implementation that solves the wrong problem.
TL;DR
Do not automate a broken process, an unmapped process, a process nobody agrees on, a process that is changing in three months, or a task so rare that the automation costs more than doing it manually for the next decade. Fix it, map it, or leave it alone. Automate what is stable, understood, and worth the investment.
Photo: Pexels
1. The process is broken: fix it first
This is the most common situation I see, and the one with the highest cost when people ignore it. A process is slow and inconsistent, the team has decided automation is the fix. It is not. Automation is a multiplier. Multiply a broken process by machine speed and you get broken at scale.
The pattern I keep seeing: companies come in saying "we need to automate our invoicing" but nobody has ever documented how invoicing actually works. Three people handle it, each with their own method. Invoices arrive by email, by an online portal, and occasionally by fax from a supplier who has not updated their contact details since 2011. (The fax is real. I wish it were not.)
Automating that is not impossible, but it will break the moment the process deviates from whatever version you built for. And it always deviates. The fix: map the process first. Get it on paper. Get the three people who do it differently to agree on one version. Then automate. The build becomes a four-week lift instead of a six-month mess.
2. Nobody has done it the same way twice
Automation requires a stable target. If the process was created in the last three to six months, it is probably still evolving. The team is finding edge cases. Managers are tweaking the rules. Someone has a "better way" they have not mentioned yet.
Automate at this stage and you will build something that reflects the first version of the process, not the settled version. Then you will spend the next six months rebuilding it as the process stabilises around what it was always going to become.
Rule of thumb: run any new process manually for at least 90 days before touching automation. Use that window to surface the edge cases, fix the rules, and get everyone aligned on how it actually works. The automation will be faster and cheaper to build once the process stops moving.
3. The volume does not justify the work
Automation has a setup cost. Building, testing, and maintaining a workflow takes real time: typically four to twenty hours for a basic integration, more for anything with complexity. That cost needs to be recovered by the time the automation saves.
If a task takes fifteen minutes a week, that is thirteen hours a year. (For context, that is also roughly how long my apprentice spent last month explaining why his code works on his machine and nowhere else. The problem was a missing header. We do not need to discuss the timeline.) If the automation takes twenty hours to build and an hour a month to maintain, you will not break even for over three years.
The ROI calculation is not complicated. Hours saved per year, multiplied by hourly rate, minus build cost and annual maintenance. If the payback period is over twelve months, the case is marginal. Over eighteen months, shelve it and spend the time on something with a better return.
4. The exceptions are the entire job
Some processes look automatable on paper. The standard flow is clear and consistent. But in practice, sixty percent of the time goes to handling exceptions: the cases that fall outside the rules.
Customer complaint handling is the example I use most. The scripted response is automatable. The real complaints (the ones that require judgment about what actually happened, what the customer actually wants, and what the right outcome is) are not. If your team spends more time on exceptions than on the standard flow, you do not have a process. You have a judgment call with paperwork around it.
Automating the standard flow in this situation gives you a faster machine for the easy cases and no improvement on the cases that actually matter. Sometimes that trade-off is still worth making. Often it is not. Be honest about where the actual work lives before building anything.
Photo: Pexels
5. The process is about to change
New software incoming. Regulatory update due in four months. Team restructure being planned. These are all reasons to pause before building anything.
Automation built for the current version of a process needs to be rebuilt for the new version. That is wasted effort, and it happens more often than you would expect. A company installs a new ERP system, then discovers the automation they finished building three months ago does not connect to the new platform. The work is thrown away. The rebuild takes another six weeks.
Rule of thumb: if a significant change is coming within six months, wait. Build the automation for the stable version of the process, not the transitional one. The six weeks spent waiting will be recovered in the twelve weeks you will not spend rebuilding.
6. Nobody has mapped it yet
This is a subset of situation one, but it is common enough to name separately. You want to automate a process. Nobody has ever written down what the process actually is.
In 100+ implementations, I will not start building until the process is on paper. Full stop. This is not bureaucracy. It is the difference between building something that works and building something that works for the person I spoke to on Tuesday, which turns out to be different from how everyone else does it.
The good news: mapping a process before automating it does not take six months. A focused afternoon, the right people in the room, and a shared document will get you 80 percent of the way there. The full method is in this post on process mapping. It is not glamorous work. It is the work that makes everything else faster.
7. The ROI calculation does not close
Here is where I am honest about my own lane. I have turned down projects. Not many, but some. The client wants the automation, the budget is there, but the numbers do not work. The task is too rare, or the cost to build and maintain is simply higher than the value it creates.
My rule: if an implementation costs more than €5,000 and you cannot point to a measurable return (hours saved, errors eliminated, capacity created), kill it.Build the case first. If you can point to fifteen hours a week freed up at a team rate of €40 per hour, that is €30,000 in annual capacity recovered. The maths works. If you cannot point to anything specific, you are building technology for technology's sake. I have seen that go wrong too many times to pretend it is a reasonable way to spend money.
A well-scoped automation at €8,000 that saves fifteen hours a week pays back in about four months and runs for years. That is a good investment. An €8,000 automation that saves two hours a week takes seven years to break even. By then, the world has moved on. Spend the money on something that moves faster.
The automation ROI post has the full calculation if you want to run the numbers before committing. It takes about fifteen minutes. Worth it.
What to do instead of automating right now
If any of the seven situations above describe where you are, here is the practical sequence before touching a tool:
Fix the process first
Get it running consistently without automation. If three people do it three different ways, get them to agree on one. Run that version for 90 days. The problems that remain after that are the ones worth automating.
Map it on paper
Every step, every input, every output, every decision point. One afternoon. The right people. A shared document. Do this before opening any automation tool.
Run the ROI calculation
Hours saved per year times the hourly cost of the time, minus build and maintenance cost. If the payback is over twelve months, rebuild the case or shelve the project entirely.
Then build narrow
Automate the core flow. Not the edge cases, not the exceptions. The main 80 percent. Test for 30 days. Expand from there once you know it is stable.
When you are ready to start, the business process automation guide covers the full framework. And if you want to know which tools to use once the process is clean, the no-code automation post has the honest breakdown of what is worth your time.
The research on this is consistent. McKinsey's work on automation and the future of work finds repeatedly that the gap between organisations that get strong ROI from automation and those that do not is not the tool they chose. It is whether the underlying process was sound before they started. The tool was always the easy part.
The OECD's research on automation and work makes a similar observation from a broader angle: the tasks that automate reliably are well-defined, repetitive, and measurable. Ambiguity is automation's natural enemy. Remove the ambiguity first. Then build.
Frequently asked questions
How do you know if a process is ready to automate?
Three things: it runs the same way every time, the volume justifies the setup cost, and you can map it end to end without anyone arguing about the steps. If any of those three fails, you are not ready. The most common failure point is the first one: the process is different every time and nobody has admitted it yet.
What happens if you automate a broken process?
The failures get faster and more consistent. A broken process run manually might produce a few errors a week that someone catches and fixes. The same process automated will produce those errors at volume, faster than anyone notices, before someone has to untangle the mess. I have seen this happen. It is not subtle, and the cleanup is expensive.
Is there such a thing as automating too much?
Yes. The practical ceiling is when the exceptions to your automation start taking more time to manage than the manual process saved. That usually means the scope was too broad, the process was not clean enough, or the edge cases were not accounted for. Build narrow, test for 30 days, then expand.
What is the minimum volume to justify automating a task?
Rule of thumb: if a task takes under 30 minutes a week and the automation will take more than four hours to build, the break-even is likely longer than six months. That is not always the cutoff. Some automations are worth building for reliability, not just speed. As a starting point, the maths needs to work. If it does not, start with a simpler fix first.
Should I automate a process that is about to change?
No. Wait. If a significant change is coming in the next three to six months (new software, regulatory update, team restructure), build the automation for the new process, not the current one. You will thank yourself. So will whoever inherits your setup.
What is the biggest automation mistake small businesses make?
Starting with the tool instead of the problem. The question is not 'what can we do with Make.com' or 'what Zapier workflows exist.' The question is 'what are our most repetitive, highest-volume, lowest-judgment tasks?' Answer that first. The tool is the last decision, not the first.
When should I hire a person instead of automating?
When the value of the work is primarily in the judgment, relationship, or accountability that comes with a human being involved. An angry customer does not want a better-automated response. They want someone who takes responsibility and makes it right. Automate the transactional; hire for the relational.
Tijdo Koster
Automation consultant since 2009. 100–200 projects. Still answers his own emails.
If the main takeaway from this post is that Tijdo will talk you out of a project before he builds it. Yes, that is correct. My apprentice says this is not how consultants are supposed to operate. I told him it is exactly how they are supposed to operate, and the others are simply less honest about it. He is still thinking about whether I am right. (He is. He just does not know it yet.)
When you are ready to automate the right things, there is more on the blog. And if you want the tools shortlist, the products page has what is actually worth using.
Some links in this post may be affiliate links. Read the disclosure.