Back to Journal
Process Improvement | 5 min read

AI Won't Save a Broken Process. It Will Just Break It Faster.

Automating a broken process does not fix it. It scales the failure. Here is how to tell the difference between a process that is slow and one that is actually broken.

Process ImprovementAI StrategyAutomation

TL;DR / Key Takeaways

  • Automating a broken process does not fix it — it makes the same mistakes happen faster and at higher volume.
  • A slow process and a broken process are different problems, and they need different solutions.
  • Before you add AI or automation, you need to understand why the current process fails, not just how long it takes.
  • The fix for a broken process is usually clarity, ownership, or better decisions — not a new tool.
  • Start by mapping what actually happens, not what is supposed to happen.

The Most Expensive AI Mistake Is Not Waiting Too Long

Everyone is worried about falling behind on AI. But the mistake I see most often is not moving too slowly. It is moving too fast on the wrong thing.

A business has a painful, time-consuming process. Someone decides AI will fix it. They buy a tool, hook it up, and now the process runs automatically. The problem is, it was already producing bad results before. Now it produces bad results around the clock with no one watching.

That is not progress. That is just faster failure.

Slow and Broken Are Not the Same Problem

This is the distinction that matters most before you automate anything.

A slow process works. It produces the right output. It just takes too long, uses too many steps, or requires more manual effort than it should. Automation genuinely helps here. You can speed it up, reduce the manual work, and get consistent results at lower cost.

A broken process does not work reliably. It produces errors, inconsistencies, or outcomes that require cleanup. People have built workarounds around it. Nobody fully trusts the output. The slowness is often a symptom, not the cause.

If you automate a broken process, you do not eliminate the breakage. You remove the human checkpoints that were catching it.

How to Tell the Difference

Here are the questions I ask before recommending any automation.

What does the output look like when this process goes wrong?

If people can answer this quickly and with examples, the process has a failure mode. That failure mode needs to be understood before anything else happens.

Where do people spend time fixing things?

If there is regular cleanup, rework, or error correction downstream, the process is producing broken output. Automating the front end without fixing what causes the rework just fills the cleanup queue faster.

Who owns this process?

If nobody can clearly answer that question, the process is probably not well-defined. Automation requires a defined process. You cannot reliably automate something nobody fully understands.

What are the workarounds?

Every team has them. The spreadsheet that fills the gap between two systems. The Slack message that replaces a missing step. The person who just knows to check a certain thing. Workarounds are a signal that the official process does not match reality. Automating the official process while the workarounds still exist means the automation will be bypassed.

An Example That Shows Up More Than You Would Expect

A business owner tells me their sales follow-up process is too slow. They want to automate it with AI. Leads come in, somebody eventually sends a follow-up email, but it is inconsistent and often delayed.

Before we touch a tool, I ask some questions. It turns out the follow-up is slow because nobody is sure which leads are supposed to get follow-up, how quickly, or what to say. The CRM has incomplete data. Two people think the other one handles certain lead types. There is no agreed-upon template.

The slowness is a symptom. The real problem is that there is no defined process at all.

If we automate this, the automation will follow up with the wrong people, say the wrong things, and nobody will own it when it fails.

The fix here is not a tool. The fix is defining who handles which leads, in what timeframe, with what message. Once that exists, automation becomes straightforward and actually useful.

The Fix Is Usually Clarity Before Technology

Most broken processes are broken for one of three reasons.

No clear owner. If everyone is responsible, nobody is responsible. The process drifts, workarounds multiply, and errors get absorbed rather than corrected.

No defined decision rules. The process requires judgment calls that have never been written down. Different people make different calls. Automation cannot handle undefined judgment — it will just pick one answer and apply it everywhere, which may be wrong most of the time.

Bad inputs. The data or information entering the process is incomplete, wrong, or inconsistent. No amount of process improvement or automation fixes a bad input problem. That has to be solved at the source.

None of these are technology problems. They are operational clarity problems. And the honest answer is that you should fix them before you spend money on tools.

What to Do Before You Automate Anything

I am not arguing against automation. I use it constantly, and it works well when it is applied correctly. But the sequence matters.

First, map what actually happens. Not what the procedure document says. What people actually do, including the workarounds.

Then ask whether the process produces reliable output when it works correctly. If the answer is yes, it is a candidate for automation. If the answer is no, or if nobody can agree on what correct looks like, stop there and fix the process first.

Once the process is clean and owned, automation usually becomes simpler than expected. The hard work was never the technology.

A Note on AI Specifically

AI tools can do useful work inside a well-defined process. They can draft, summarize, classify, suggest, and flag. But they rely on good inputs and clear criteria. They will not figure out what your process is supposed to do. That is your job to define.

Feeding AI into a process that has unclear ownership, bad data, or undefined rules will not produce useful output. It will produce confident-sounding output that may or may not be right, with no easy way to tell the difference.

That is actually worse than doing nothing.


If you are trying to figure out whether a process in your business is ready to automate or needs to be fixed first, that is usually where I start with new clients. The answer shapes everything else that follows.

The tool is not the strategy. Getting the process right is.

Related practical notes