Automation is genuinely valuable, but "automate everything" is bad advice. Some tasks should not be automated, and forcing it wastes effort, creates fragile systems, or quietly damages something that mattered. Knowing when to leave a process alone is as useful as knowing when to automate it.

When the process is broken

The most important rule: do not automate a process that is broken or badly designed. Automating it does not fix it. It locks the flaws in and runs them faster.

If a process is messy, fix it first. Map it, remove the waste, correct what is broken (then) decide whether to automate the improved version. Automation should come after the process is sound, never before.

When the task needs human judgment

Automation is excellent at rule-based steps: predictable, the same every time. It is poor at judgment.

If a task genuinely depends on weighing a situation, reading nuance, making a real decision, or applying experience, that is not a good automation candidate. You can often automate the routine parts around it: gathering the information, handling the follow-up, while leaving the judgment to a person. But do not try to automate the judgment itself.

When it is the human contact that matters

Some interactions carry value precisely because a person is involved. A difficult customer conversation, a sensitive issue, a relationship that depends on genuine attention, automating these can save a few minutes and cost you something far more valuable.

Be especially careful here: it is easy to automate a customer touchpoint, watch the efficiency metric improve, and not notice that the relationship quietly got colder. If the human element is the value, keep the human.

When the task is rare

Automation pays off through repetition. Building and maintaining an automation has a cost; that cost is repaid each time the task runs. A task that happens a handful of times a year may simply never repay the effort.

For genuinely infrequent tasks, a good checklist or clear documentation is often the smarter answer: it captures the knowledge without the build-and-maintain overhead.

When it would be too fragile

Some processes could technically be automated, but only with something so complex and dependent on things staying exactly the same that it would break constantly. A fragile automation that needs frequent repair can cost more attention than the manual task ever did. If a reliable automation is not realistically achievable, manual may be the honest choice.

When you do not understand it yet

If nobody can clearly explain how a process actually works, it is not ready to automate. Automating a process you do not understand means encoding mistakes you cannot see. Understand it first, then decide.

A simple test

Before automating anything, ask:

  • Is the process itself sound? (If not, fix it first.)
  • Is it repetitive and rule-based, or does it need judgment?
  • Does it happen often enough to repay the effort?
  • Does it depend on human contact that matters?
  • Do we genuinely understand how it works?
  • Can the automation be reliable, not fragile?

If the answers point the right way, automate. If they do not, leaving the task to a person, well supported by a checklist, is the right call.

The takeaway

"Automate everything" is not a strategy. Do not automate broken processes, genuine judgment, interactions where human contact is the point, rare tasks, fragile setups, or processes you do not yet understand. Automation is a tool, and good judgment about where to apply it is what makes it pay off.

If you would like help deciding what in your business is worth automating, and what is not, the Flexnet Networks team is glad to give you a straight assessment.

Sources