When Not to Automate: Leaving Good Enough Alone

The default consulting move is to point at a delay and sell a tool. The delay is real. The tool is not the diagnosis. Some friction is the work. Automating it does not remove the cost. It hides the judgement until something expensive happens.

I am in the business of finding inefficiency. That is not the same as removing every pause. The discipline is knowing which pauses to keep.

A scene that should stay human

A small operations team takes on a new supplier. Someone in finance has to decide whether to put them on terms. The form is ugly. The wait is a week. A well-meaning manager wants a score: paste the Companies House number, the website, last year's invoices, and let a model return on/off.

Do not automate that call.

The week of waiting is not the waste. The waste is that three people re-type the same company name into three systems. Fix the re-typing. The decision itself (will we extend credit to this firm, on these terms, given what we know about how they actually pay) is a judgement with a name on it. A score will be wrong in the cases that matter, and nobody will notice until the invoice is ninety days old. The person who used to look at the file will have been told the model “handles it”.

That scene is from a dozen conversations, not a hypothetical. The form is ugly, so the form becomes the enemy. The missing owner is the problem.

What “good enough” actually is

A process is good enough when the people who run it can name the outcome, the wait is understood rather than accidental, and the error that would hurt is still caught by a person who can stop it.

Good enough is rarely pretty, and it is not a demo. It is a named owner, a short path, and a refusal to add a third place to type the same fact.

Three questions before anyone opens a catalogue:

• What is the core problem, in one sentence the people who do the work agree on?
• Which step exists only because a previous tool was weak?
• What breaks when the usual person is away?

If you cannot answer the first, you are not ready to automate. If the second points at a workaround, fix the workaround. Often that is a habit or a smaller glue job, not a model. If the third has no answer, you are about to automate a single point of failure.

The cost of automating the wrong step

Automation that fires without a confirm step does two things. It speeds the happy path. It also speeds the error path, and it removes the person who used to notice.

That is how you get a chatbot that “resolves” a complaint with the wrong customer, a roster tool that publishes a shift nobody agreed, a content system that pushes a rate to every channel before anyone has looked. Each of those was sold as saving time. Each of them spent the saving on recovery.

AI makes the temptation worse, because the draft looks finished. A finished-looking draft is still a suggestion, not a decision.

Leave it alone if the volume is low, the judgement is high, and the failure is expensive. A partner at a six-person firm signing off a one-off credit decision twelve times a year does not need a model. They need the file in one place. A hotel publishing the same fact to eight channels does not need a model to decide the fact. They need a person to confirm it, and then a pipe. Different jobs.

What to do instead

Watch one real case end to end. Write down every hand-off and every “we just email it”. Rank the drag by hours and by risk, not by how embarrassing the tool is. Decide what to leave. Then choose: a better habit, a smaller automation, a focused build, or nothing.

The structured version of that choice (when a rule will do, when a model earns its keep, when a person has to stay) is Automation vs AI: A Decision Framework. This post argues for restraint. That page holds the table. Use the table when you are ready to pick. Use this when someone is trying to skip the picking.

If the operation is leaking and you are not sure which leak to touch, talk to us.