Five process automation mistakes that cost the most
Automation rarely breaks because something was badly built. Far more often it fails before anyone starts building it. Here are the five mistakes we see most often — and what to do so that none of them happens in your company.
The short answer
The five mistakes that most often ruin an automation project are: automating a process nobody has written down, starting with everything at once, having no one accountable on the company side, skipping the team at launch and not measuring before the start.
Four of them are preparation mistakes, not technology mistakes. That is why a good implementation starts with questions about the process, not with choosing a tool.
1. Automating a process nobody has written down
This is the most common and the most expensive mistake. A company orders enquiry-handling automation, and partway through it turns out that three people do it three different ways and nobody knows which one is right. The project turns into a process clean-up workshop — necessary, but not what anyone expected or budgeted for.
The rule is simple: automation speeds up the process as it is. If it is orderly, you gain time. If it is a mess, you get the same mess, only faster and without a person to fix it along the way.
How to avoid it: before anything is built, ask the person who knows the process best to write it down step by step — who does what, where the data comes from, what happens in unusual cases. It usually takes an hour. You can use our process map template.
2. Starting with everything at once
The company decides that if it is getting into automation, it will do it properly: five processes, every department, one big project. Three months later there is a system the team does not use, because in all that time nobody checked whether the solution fits day-to-day work.
A big project has another drawback: the first result appears only at the end. By then priorities, people and the board’s patience have all changed.
How to avoid it: start with one process that repeats a few times a week and hurts the most. Automating it takes five to ten working days, and after two weeks you can see how much time came back. Only with that knowledge should you plan the next step.
3. No one accountable on the company side
Every implementation needs decisions: who gets notifications, what to do with an unusual enquiry, which fields are mandatory, when a case goes to a person. These are not technical questions — they are questions about how the company wants to work.
If nobody has the authority to settle them, the project stalls or the supplier guesses. Guesses are sometimes right, but every wrong one is paid for in rework.
How to avoid it: appoint one person who knows the process and can make decisions without calling a meeting. They do not need to be technical. An hour or two a week is enough for the duration of the implementation.
4. Skipping the team at launch
The system works, but nobody knows what has changed. People fall back on old habits because they feel safer. A month later the automation runs alongside the manual work instead of replacing it — and the company pays for both at once.
This mistake is sneaky, because technically everything is fine. It only shows when someone notices that enquiries are still being retyped by hand even though they have long been reaching the system on their own.
How to avoid it: show the team in fifteen minutes what is changing and why. Give them a one-page guide. And set a specific day from which the old way stops — without it, two paths will live side by side.
5. Not measuring before the start
If you do not count how much time the process took beforehand, you will never prove the implementation paid off. A few weeks later nobody remembers how things used to be — and “it seems better” will not convince a business partner or an accountant.
Measuring has a second purpose: it shows whether automation is worth it at all. A process that takes half an hour a week will not pay back the cost of an implementation.
How to avoid it: for one week, write down three numbers — how many times the process ran, how many minutes one run took and how many cases got lost or needed fixing. With that data you can calculate the payback in the calculator on our pricing page.
The common thread
Four of the five mistakes happen before anyone starts building. The fifth — skipping the team — happens at launch. None of them is about the technology itself. Building the automation is usually the easiest part of the project.
There is also a technical mistake we see more and more often: building an AI agent where a simple “if–then” rule would do, or the other way round. We cover it separately in A rule or an AI agent.
| Mistake | How to avoid it |
|---|---|
| Undocumented process | write down the steps before the build |
| Everything at once | one process, results in two weeks |
| No owner | one person with the authority to decide |
| Team skipped | a fifteen-minute walkthrough and a cut-off day for the old way |
| No measurement | one week of counting before the start |
Pre-launch checklist: five questions
If you can answer “yes” to each of these questions, the implementation has a very solid foundation.
- Is the process written down well enough that a new person could follow it without asking?
- Are we starting with one process, not several at once?
- Is there one person who makes decisions about this process?
- Do we know when we will show the change to the team and from when the old way stops?
- Do we have the numbers from before — repetitions, time, lost cases?
If you are not sure whether your company is ready, check with the readiness test — it takes five minutes.
Frequently asked questions
Most often not for technical reasons but because of preparation: the process was never written down, the company tried to automate everything at once, nobody owned the decisions, the team did not know what had changed, or nobody measured the starting point. Building the automation itself is usually the easiest part of the project.
One that repeats at least a few times a week, follows clear rules, runs on digital data and where a mistake can be undone. Most often that is enquiry handling, reminders or copying data between systems.
Less than people usually expect: a conversation at the start, a few answers along the way and a test on real data at the end. There is one condition — someone in the company must be able to make those decisions.
By comparing the situation before and after: how many times a week the process runs, how many minutes one run takes and how many cases get lost or need fixing. Without a “before” measurement, that comparison is impossible.
Write it down before the implementation — it is usually an hour’s work for the person who knows the process best. List the steps, who does them, where the data comes from and what happens in unusual cases.
Usually, yes. First find out whether the problem lies in the tool or in the process. In most cases the automation does exactly what it was told to — but the process it mirrors was never settled, or the team is still working the old way.
He spent five years building operations at WebWave: from creating a support department from scratch to the role of Head of Operations and leading the integration after the company was acquired. While putting those processes in order he noticed how much time is taken up by work that develops nobody — and that the tools capable of taking it over already exist. A graduate in corporate finance from the SGH Warsaw School of Economics.
LinkedIn profile →