When should you automate a business process — and when shouldn't you?

What is happening

Automation is proposed as the answer to manual effort. Sometimes it is. But manual effort is a symptom, and the cause may be an upstream data problem, an unnecessary approval, or a process that should not exist at all.

When to automate

• The process is documented and consistently followed.
• Volume is high enough that time saved is material.
• Rules are deterministic; the same inputs always produce the same decision.
• Exceptions are genuinely rare and have a defined handling path.
• Inputs arrive in a reliable, structured form.
• Someone will own the automation, monitor it, and maintain it as the business changes.

When not to automate

• The process is under active dispute or redesign.
• Most cases are exceptions.
• The step requires judgment, negotiation, or context that is not captured anywhere.
• The work exists only to compensate for a defect upstream — fix that instead.
• No one will own the automation after the person who built it moves on.
• The regulatory or contractual position on automated handling has not been checked.

What to do first

• Eliminate before you automate: remove steps that no longer serve a purpose.
• Standardize what remains, and agree the exception path.
• Measure the baseline so the benefit can be verified later.
• Design the failure mode: what happens when the automation breaks, and who is notified?
• Keep a human decision point where the consequence of an error is significant.

Questions to ask

• How often does this process change?
• What proportion of cases are handled outside the standard path?
• Who maintains this in two years?
• What is the cost of an undetected automated error?
• Would eliminating the step be better than automating it?

Warning signs

• The automation business case is built on a time saving no one has measured.
• The process owner cannot describe the exception path.
• The team plans to automate the workaround rather than the process.

When internal teams can handle it

When the process sits within one function, has an owner, and the automation is well contained.

When outside help may be appropriate

When automation crosses systems and departments, when it touches regulated activity, or when previous automation efforts have created maintenance burden without measurable benefit.