The Automation Consultant's Dirty Secret

I've worked on a lot of automation projects. Across different industries, different tools — n8n, Make, Zapier, custom API glue, full agent systems. The technical implementation varies. The failure mode is almost always the same.

The workflow got automated. The business problem didn't go away.

Sometimes it got worse.

What actually gets automated

Here's how most automation engagements start. A business has a pain point — usually something that involves a lot of manual steps, hand-offs between systems, or repetitive data entry. They hire someone (or use an AI tool) to automate it.

The automation works. The flow runs on schedule. Data moves between systems without anyone touching it.

Six months later, the team is still frustrated. The numbers haven't changed in the ways that mattered.

What happened? Usually one of three things:

The bottleneck was upstream. The manual step that got automated wasn't the actual constraint. It was the visible, annoying part of a deeper process problem. Automating it made the constraint harder to see, not easier to fix.

The workflow was wrong. The process that got encoded into the automation had bad assumptions baked in. Those assumptions now run automatically, at scale, without anyone questioning them. A broken manual process at least has friction that prompts occasional reflection. A broken automated process just churns indefinitely.

The output wasn't connected to a decision. Data moved. Reports generated. Dashboards updated. But nobody changed what they did based on any of it. The automation produced outputs that had no owner.

The question that should come first

Before designing any automation, there's a question worth asking that rarely gets asked:

If this process ran perfectly, what decision would change?

Not "what would be faster" or "what would require less manual effort." What would actually change about how the business operates, what it prioritises, what it does next?

If the answer isn't clear, the automation is probably solving the wrong problem.

This sounds obvious written down. It's remarkably easy to skip in practice. Clients come in with a specific pain point and a specific tool in mind. The engagement pressure is to solve the stated problem. Questioning whether the stated problem is the right problem to solve requires a kind of courage that's easy to rationalize away.

The opportunity audit that changes engagements

The most valuable thing an automation consultant can do before touching a workflow tool is map the full process landscape and rank opportunities by expected impact — not by automation complexity, not by client enthusiasm, but by the change in business outcome if the problem were completely solved.

That ranking rarely matches what the client came in with.

Sometimes the highest-impact opportunity is an automation. Sometimes it's a process change that costs nothing to implement. Sometimes it's a decision about what to stop doing entirely. The tool-agnostic audit surfaces all three.

The engagements that produce real outcomes almost always start there. The ones that don't — the ones that produce technically functioning automations that nobody talks about six months later — usually skipped it.

Automation as a last step, not a first one

The right mental model for automation is that it should come at the end of process improvement, not the beginning. First, understand the workflow. Then simplify it. Then standardise it. Then, when it's as simple and correct as it can be, automate it.

Automating before simplifying is fast. It produces results that look like progress. It also locks in complexity that becomes very expensive to change later.

The dirty secret of automation consulting is that the most technically impressive deliverable and the most business-valuable deliverable are often different things. A consultant who can tell the difference — and is willing to say so — is rarer than the tools would suggest.