Five Signs You Are Automating a Broken Process

Automation does not fix a broken process. It makes it faster, more consistent, and harder to stop.

That is the uncomfortable lesson of every automation project I have watched go wrong in a small business. The process was already broken. The team knew it was broken. But the tool was available, the demo looked good, and the automation promised to remove the pain. So the team automated the broken process, and the pain came back at a higher speed.

I have made this mistake. I automated a client reporting process that was already producing reports nobody read. The automation produced them faster, in a nicer format, and nobody read them more. The only thing the automation improved was my ability to produce work that did not matter.

This is the checklist I now use before I automate anything: five signs you are automating a broken process. If two or more of these are true, stop. Fix the process first. The automation can wait.

The demo is not the work. The work is deciding whether the process deserves to be faster.

Sign 1: Nobody can explain why the process exists

The first sign is the most common and the easiest to miss.

Ask the person who owns the process a simple question: why does this process exist? If the answer is "because we have always done it," or "because the client expects it," or "because the last person set it up this way," the process is a candidate for deletion, not automation.

A process that cannot explain its own purpose cannot be improved by making it faster. It can only be made more expensive.

I once automated a weekly status report that took four hours to prepare. The automation cut it to twenty minutes. Six weeks later, I asked the client whether they read it. They said they glanced at it. I asked whether it changed any decision. They said no. I had automated four hours of work into twenty minutes of work that nobody needed.

The right move was to delete the report, not automate it. Deleting it would have saved four hours. Automating it saved three hours and forty minutes, and added a new artifact to maintain.

The test: Ask why the process exists. If the answer is a habit, a legacy, or a guess, delete it before you automate it.

Sign 2: The process has no clear owner

A broken process usually has no owner. Everyone assumes someone else is responsible. The request comes in, gets forwarded, sits in a queue, and eventually gets handled by whoever notices it first.

Automating a process with no owner makes the process faster and the ownership problem worse. The automation now runs, but nobody is responsible for the exceptions, the errors, or the decisions. When the automation produces a bad output, everyone assumes someone else will catch it.

In a small business, the owner is usually the implicit process owner, which means the automation creates a queue at the owner's desk. That is not a system. It is a bottleneck with a workflow.

The test: Name the person who owns the process, including the exceptions. If you cannot name them, the process is not ready for automation. Assign an owner first.

Sign 3: The process changes every week

A process that changes every week is not a process. It is a series of improvisations with a shared name.

Automating an unstable process means the automation is out of date as soon as it is built. The template does not match the current work. The prompt does not match the current context. The review step does not match the current approval path. The team works around the automation, and the automation becomes another thing to maintain.

I learned this with a content brief workflow that I automated while the client was still changing the brief format. The automation produced briefs in a format the client had stopped using. The team spent more time correcting the format than they had spent writing the brief manually.

The test: Has the process been stable for at least a month? If not, wait. Automate the process after it stabilizes, not while it is still moving.

Sign 4: The process has no clear definition of done

A broken process often has no definition of done. The work is finished when someone decides it is finished, and that decision changes depending on who is doing the work and how busy they are.

Automating a process with no definition of done produces output that looks finished and is not. The AI generates a draft, and the draft is treated as the deliverable because nobody defined what "done" means. The cleanup tax is paid later, by the person who has to correct the draft or explain to the client why it is wrong.

A definition of done is not a nice-to-have. It is the thing that makes the automation verifiable. Without it, you cannot tell whether the automation worked.

The test: Write down what "done" means for this process, in one sentence. If you cannot, the process is not ready. Define done first.

Sign 5: The process exists only because of a tool limitation

Some processes exist because an old tool could not do something. The team built a workaround, the workaround became a process, and the process survived long after the tool changed.

Automating a workaround automates a limitation. You make the workaround faster and more entrenched, and you make it harder to remove when the tool finally catches up.

I have seen this with client intake processes that exist because an old CRM could not handle a particular field. The team built a manual step to compensate. Years later, the CRM could handle the field, but the manual step remained, and someone proposed automating it. The right move was to remove the workaround, not automate it.

The test: Ask whether the process would exist if you were designing it today, with the tools you have now. If the answer is no, the process is a workaround. Remove it before you automate it.

What to do instead of automating a broken process

If two or more of these signs are true, the process is not ready for automation. Here is what to do instead.

1. Delete the process if it has no purpose.
The cheapest automation is deletion. If nobody can explain why the process exists, remove it and see whether anyone notices.

2. Assign an owner.
A process with no owner cannot be improved. Name the person responsible for the process and the exceptions. The automation can follow.

3. Wait for stability.
If the process changes every week, it is not ready. Stabilize it first. Then automate the stable version.

4. Define done.
Write the definition of done in one sentence. The automation needs a target. Without it, the output cannot be verified.

5. Remove the workaround.
If the process exists because of a tool limitation that no longer applies, remove the workaround. Automating it makes the limitation permanent.

The Friday Test

Does the process survive a busy, low-patience Friday?

A broken process usually fails on Friday, which is exactly when the automation will be asked to carry the load. If the process requires a clean calendar, a calm team, and a cooperative client, the automation will fail on the day it matters most.

The Friday Test is a good way to check whether the process is stable enough to automate. Run the process manually on a busy Friday. If it fails, the automation will fail too, only faster and with less warning.

What broke when I ignored these signs

The reporting process was the clearest example.

It had no clear purpose. It had no owner. It had been changing every week. It had no definition of done. And it existed partly because of a reporting tool limitation that no longer applied.

I automated it anyway, because the demo looked good and the team was tired of preparing the report manually. The automation worked. The report was produced faster, in a nicer format, with fewer errors.

Nobody read it. The client did not use it. The team spent time maintaining the automation. Six months later, we deleted the report and the automation together.

The lesson was not that automation is bad. The lesson was that automation amplifies whatever the process already is. A broken process becomes a faster broken process. A useful process becomes a faster useful process. The automation does not decide which one you have. You do.

The cleanup tax of automating a broken process

The cleanup tax is usually invisible in the first month, because the automation is new and the team is paying attention. It shows up later, in three forms.

1. Maintenance tax.
The automation needs to be updated as the process changes, which it does, because the process was never stable. The maintenance cost grows over time.

2. Exception tax.
The automation handles the normal case and fails on the exceptions. Someone has to handle the exceptions manually, and that someone is usually the owner. The exception tax is the queue at the owner's desk.

3. Trust tax.
The team stops trusting the automation because it produces output that looks finished and is not. The trust tax is the time spent double-checking the output, which is often more than the time the automation saved.

None of these show up in the generation-time metric. All of them are part of the real cost.

Who should use this checklist

Use it if you are about to automate a process and you are not sure whether the process is ready. Use it if you have automated a process and it is not delivering the expected benefit. Use it if you are the owner and you want to avoid automating a workaround that should be removed.

Who should not use it

Do not use it as a reason to avoid automation altogether. Some processes are ready, and automating them is a clear win. The checklist is a filter, not a prohibition. And do not use it to blame the team for a broken process. The process is a design problem, not a people problem.

The smallest useful version

If you take one thing from this article, take the first sign and the first question.

• Ask why the process exists.

• If the answer is a habit, a legacy, or a guess, delete it before you automate it.

That alone will save more time than most automations. The other four signs make the filter more complete. The Friday Test makes it honest.

Useful beats impressive. A process that deserves to be faster is useful. A faster broken process is not the same thing.

FAQ

How do I know if a process is ready to automate?
A process is ready to automate when it has a clear purpose, a named owner, a stable shape, a definition of done, and no dependency on a workaround that no longer applies. If two or more of the five warning signs are present, fix the process before automating it.

What are the five signs you are automating a broken process?
Nobody can explain why the process exists, the process has no clear owner, the process changes every week, the process has no definition of done, and the process exists only because of a tool limitation. Any two of these is a signal to stop and fix the process first.

Why does automating a broken process create more work?
Because automation amplifies whatever the process already is. A broken process becomes a faster broken process, with a maintenance tax, an exception tax, and a trust tax. The cleanup tax is hidden in the first month and shows up later as rework and double-checking.

For AI tool features, rules and availability, refer to their official sites.