Automation feels productive, which is exactly why people reach for it too early. A bad process running automatically is just a bad process you now have to debug at eleven at night. The tool is rarely the problem. The judgment about what to automate, and when, is where this goes right or wrong.

Fix the process before you wire it up

If a workflow is messy by hand, automating it just hardcodes the mess and hides it from view. Get it clean, stable, and repeatable first, so a person can run it the same way every time. Only then should you consider removing the person.

Automate the boring, keep the judgment

The best candidates are high-frequency and low-judgment: data entry, reminders, status updates, handoffs. The moment a task needs a real decision, a genuine "it depends," leave a human in the loop. Automate the parts that are dull and certain. Keep a person on the parts that are rare and messy.

Automate the dull and certain. Keep a human on the rare and the judgment-heavy. Confuse the two and you will spend more time babysitting the robot than the task ever took.

Count the real cost, including maintenance

Every automation is a small machine you now own forever. It breaks when a tool updates, when a field is renamed, when someone tweaks a template. If it saves five minutes a month and breaks twice a year, you lost, not in time but in the quiet tax of maintenance and the trust that erodes each time it silently fails. Automate what hurts weekly, not what annoyed you once.

Before you build, ask:

Is the manual version already clean and repeatable?
Does it happen often enough that the saved time beats the build and upkeep?
When it breaks, and it will, who notices and who fixes it?

If you cannot answer the last one, you are not building an automation. You are building a future outage with your name on it.