The wrong things automated well.

The most expensive automation mistakes we see aren't technical failures. They're successful builds of the wrong thing. Solutions that work exactly as designed, applied to problems that didn't matter.

This sounds like it should be rare. It isn't. It's so common we've stopped being surprised by it. The pattern goes something like this: a team identifies a process that's annoying, or visible, or recently complained about. They scope a project to automate it. The project ships. The process is now automated. Six months later, the team is just as busy as before, and someone is asking why.

The answer is almost always that the automated process was never the bottleneck. It was just the most legible thing to point at.

Legibility versus impact

Some processes are highly legible. They have names. They show up in meetings. People complain about them by description. These tend to be the things that get automated, because they're easy to scope.

Other processes are less legible. They don't have names. They show up as "Tuesday afternoons feel slow," or "we always lose half a day after the monthly close," or "Sarah is overloaded but we can't quite say why." These are usually where the real time loss lives. But they're hard to scope, hard to defend in a project meeting, and hard to celebrate in a post-launch report.

The result is a systematic bias toward automating the legible, which is correlated with, but not the same as, the impactful.

Three ways this goes wrong

Automating the visible task instead of the hidden one

A finance team complains about month-end reporting. The team automates report generation. Time saved: four hours a month. Meanwhile, the same team spends six hours a week reconciling vendor statements manually, but nobody complained about that, because everyone has always done it that way. The wrong thing got automated well.

Automating a step instead of a workflow

A sales team automates lead enrichment. The leads now arrive enriched. But the team still has to manually score them, route them, and write personalised first-touch emails, which is where most of the time was always going. The single step is now faster. The workflow takes the same time as before.

Automating the easy part of a hard process

A legal team wants to automate contract review. The team builds a tool that extracts key clauses. Extraction was never the hard part, interpretation was. Now the lawyers spend the same amount of time interpreting contracts, but they also have to QA the extraction tool. The team is slightly slower than before.

"Every one of these projects was technically successful. Every one of them shipped on time. Every one of them solved the wrong problem."

How this happens repeatedly

The structure of how automation projects get scoped almost guarantees this outcome. Someone writes a brief. The brief describes a process. The process described is the one that was visible at the moment of writing. The vendor or internal team builds against the brief. The brief is satisfied. The team's actual operations have not been meaningfully changed.

This isn't anyone acting in bad faith. It's the consequence of treating the brief as the problem, instead of as a hypothesis about the problem.

The fix is upstream

You can't fix this with better tools, a better vendor, or a more careful build. The fix has to happen before the build, in how the problem gets defined.

It looks like spending time, before any tool conversation, with the people doing the actual work, and not the kind of time that fits into a one-hour discovery call. A few days, minimum. Real observation. Notes on what consumes time, not what people say consumes time. A willingness to find that the visible problem isn't the real problem, and to scope the project around what you actually find.

This is slower. It's also the difference between an automation project that changes the team's economics and one that produces a successful build of the wrong thing.

If you're starting an automation initiative right now, the highest-leverage thing you can do is delay the build by a week, and use that week to map your operations more carefully than feels necessary. The people who do this find different things to automate than the people who don't. Their projects produce different results.