Automation is often treated as an obvious improvement. If a task happens more than once, the thinking goes, a script should do it.
But a script also has to be written, understood, and maintained. Sometimes the manual step is still the simplest way to learn what the work involves.
Repetition is only part of the question
Before automating a task, I want to know how often it happens, how much time it takes, and what happens when it goes wrong. A monthly task that takes a minute may not need a tool. A daily task that risks losing data probably does.
The task also needs a stable shape. If the steps change each time because someone has to make a judgment, automating the clicks may hide that judgment instead of removing work.
Make the handoff visible
A useful automation makes its inputs and effects clear. It should be possible to tell what it changed, whether it finished, and what to do after a failure. When the script silently makes decisions, a small time saving can become a hard-to-find problem.
Starting with a manual checklist can help. It shows which steps are routine and which depend on context. Then automation can take over the predictable parts while leaving important decisions visible.
Automate for the people doing the work
The measure is not how many scripts a project has. It is whether the people doing the task spend less effort and can recover when something goes wrong.
Automation is valuable when it removes repeated friction without creating a new system that needs more attention than the work it replaced.