The Problem With Automating a Bad Workflow

Repeated manual work can be a useful signal. Copying the same information, sending the same reminder, or checking the same status may consume time without requiring much judgment. That does not mean automation should be the first step.

Automation makes a defined action happen consistently. If the action is unnecessary or the rule is wrong, consistency only helps the wrong thing happen faster.

Understand the work first

Before choosing a tool, map the practical workflow:

1. Actors: Who starts, completes, approves, or depends on the work?
2. Handoffs: Where does responsibility or information move?
3. Rules: Which conditions determine the ordinary path?
4. Exceptions: When does a person need to make a decision?
5. Evidence: How often does the work happen, and what burden does it create?

This separates stable repetition from the judgment that should remain visible and owned.

Simplify before automating

Consider a clearly hypothetical example: staff receive a web request, copy it into a spreadsheet, and then re-enter it into a scheduling tool. Automatically copying the request into the spreadsheet may save a step, but it preserves the question of why the spreadsheet exists.

Perhaps the scheduling tool can collect the request directly. Perhaps the spreadsheet supports a necessary review. Perhaps the volume is so low that changing anything would cost more than it saves. Understanding comes before implementation.

Choose among alternatives

The sensible outcome is not always automation:

• Configure an existing tool when the needed capability is already present.
• Integrate systems when a necessary handoff creates duplicate entry.
• Automate stable, understood repetition.
• Custom Build only when existing approaches are insufficient and the economics justify ownership.
• Leave Alone when the current burden is smaller than the cost and complexity of change.

Good automation removes understood friction. It should not make an unexamined process harder to see.