You Automated the Wrong Things

You have automation. I know you do, because every mid-market business I speak to has some. A Zapier workflow that fires a Slack message. A script that regenerates a report every Monday. A bot that routes tickets. An integration that syncs customer records between two systems twice a day.

Each one saves a small amount of time. Each one was built with good intentions. And collectively, they have not made your operation faster, cheaper, or easier to run.

That is not a technology problem. The tools work. It is a targeting problem. You automated the wrong things - and the cost of doing so is not just the wasted investment. It is the confidence it drains from every future automation decision your leadership team has to make.

Here are the five misfires I see most often. You will recognise at least two.

Misfire 1: Automating the symptom, not the cause

Someone complained. The complaint was specific and reasonable. A report was late, a notification was missed, a customer was contacted twice. The business heard the complaint, found the painful step, and automated it.

The step is now faster. The underlying condition that produced the complaint has not changed.

The report was late because the data it depends on arrives late. Automating the report generation makes the late data arrive on time in a prettier format. The notification was missed because nobody had clarity on who owned the follow-up. Automating the notification means it gets sent; it does not mean anyone acts on it. The customer was contacted twice because two systems do not share a state. Automating one of the contact points does not fix the state problem; it just ensures the confusion happens at scale.

Automation amplifies what sits underneath it. If what sits underneath is a symptom of something else, you have now automated the symptom and left the cause in place.

Misfire 2: Automating unstable processes

This is the misfire that looks like success for six weeks and then quietly degrades.

The process was automated based on how it worked at the time. Since then, the product catalogue has changed, a new team took over the downstream step, a supplier was switched, or a regulation forced a new field into the flow. Nobody told the automation. The rules it was built on no longer match reality.

The automation does not break loudly. It works on the majority of cases and fails silently on the edges. Exceptions accumulate. Someone starts keeping a spreadsheet of the cases the automation got wrong. Someone else stops trusting the output and checks every entry. Within a quarter, the automation has quietly become a workaround again - running alongside a manual check that was supposed to be eliminated.

If a process changes every six months, you do not automate the process. You automate the orchestration of the process. That requires IT and process strategy work before a single rule is coded - because the automation has to survive change, not just perform on day one.

This is also where most failures labelled "bad execution" actually originate. Execution was fine. The ground moved underneath it, and the scoping did not account for movement. That is not the developer's fault. That is scoping failing to ask what will change.

Misfire 3: Automating edge cases instead of the 80%

The business chose what to automate by asking the operational team what was most annoying. Naturally, they chose the exceptions. The unusual order. The awkward customer. The end-of-month reconciliation that nobody enjoys.

Exceptions are annoying because they are irregular. That is also why they are a bad target for automation. The rules required to cover them are complex, the data supporting them is inconsistent, and the volume is low - so the payback is small even when the build succeeds.

Meanwhile, the 80% of cases that flow through the same team every day - the ones that are not annoying because they are fast and boring - are still manual. They are where the time actually goes. They are where the real compounding saving lives. They are also where the rules are simple enough for automation to be durable.

If you have to choose, automate the boring majority and leave a human path for the exceptions. A business that automates its exceptions before its baseline is a business that keeps the cost of its exceptions and loses the saving on its volume.

Misfire 4: Automating what humans were never actually doing

This one is the most embarrassing to admit, and it happens more often than you would think.

The business case claimed the automation would save 20 hours a week. It replaced a task that was alleged to consume those 20 hours. After go-live, the team does not feel less busy. When you look honestly at where their time now goes, you discover the original 20 hours never existed - or they did but the work was already being skipped, batched, or done by one person in their head without ever being a formal activity.

The automation faithfully performs a task that was never really the bottleneck. The ROI numbers on the original business case were assumptions dressed as measurements. And because nobody captured a proper baseline, nobody can say whether the automation delivered anything at all.

This is why the first rule of any business automation programme worth funding is a measured baseline. Not "we think it takes a day." Actual timing, counted errors, counted reworks. Without that, the saving is a story, and stories do not unlock the next round of investment.

Misfire 5: Automating before integrating

The final misfire is the most expensive. It looks like progress right up until the moment it stalls.

The automation is built. It works beautifully on test data. Then it encounters production - where the same customer has three different names across three systems, where dates are stored as strings in one place and timestamps in another, where a field that is supposed to be mandatory is populated in roughly half the records. The automation cannot reliably reason across any of it.

The team starts adding repair logic - a rule to fix one mismatch, a transformation to normalise another, a manual override for the cases the rules cannot handle. The automation expands into a small, unmaintained data-cleaning program with a scheduled job on the front of it. The scope triples. The timeline doubles. The confidence collapses.

Automation cannot clean your data for you. It will expose every inconsistency you have been living with. The cheap version of this lesson is to do data and systems integration before you automate. The expensive version is to discover it in the middle of a delivery and have to stop, scope the integration work as a separate programme, and explain to the sponsor why the original budget was only half the real cost.

The diagnostic

Three questions tell you which misfire you are in.

First: if you removed the automation tomorrow, would anyone notice inside a week? If the answer is no, you probably automated a symptom (Misfire 1) or a task nobody was really doing (Misfire 4). Remove it and reinvest the attention.

Second: when the automation produces an edge case it cannot handle, what happens? If the answer involves a person checking, correcting, or re-running the job, the automation is carrying a workaround on its back (Misfire 2 or 3). The saving you think it is delivering is partly being paid in shadow labour.

Third: where does the data feeding the automation come from, and how reliable is it? If the answer is "a few systems, and we tidy it as we go," you are living in Misfire 5. The automation you have is running on the integration work you have not done.

What good scoping would have caught

Every one of these misfires is a scoping failure, not a delivery failure. Someone skipped a conversation. A process was described but not observed. A baseline was assumed but not measured. A data problem was downplayed because admitting it would have delayed the project. A change manager was not in the room when the team on the ground already knew the process was unstable.

Automation does not disappoint because the platforms are immature. It disappoints because the preparation was optimistic. The work that makes automation land is deeply unsexy: mapping, measuring, honest scoping, integration, and a clean handover to the people who will own it after go-live. Skip any of those and the result is one of the five misfires above - at a cost that is always larger than the original business case admits.

If your automation investment is not delivering the operational change you expected, the honest move is not to add more automation. It is to go back and find out which of the five misfires you are paying for. Fix that first. The next project will look after itself.