The usual advice about what to automate first is to pick the highest-frequency task, or the one with the most hours attached. That is defensible on a spreadsheet and it is not what I do. I automate whatever I am dreading, and it has consistently been the better heuristic.
Dread is a decent proxy for risk
The tasks people dread tend to share properties. They are fiddly, so they are easy to get wrong. They have consequences, which is why the dread exists. They usually involve several systems, so context has to be reloaded each time. And they are done rarely enough that nobody is fluent, which is what makes them fiddly.
That combination, error-prone and consequential and unpracticed, is exactly the profile of a task that will eventually cause an incident. Frequency-based prioritization sends you at the opposite end: the things done so often that everyone is fast at them and mistakes are rare.
Motivation is a real input
There is also a straightforwardly practical reason. Automation work competes against feature work, and it usually loses on urgency. The projects that actually get finished are the ones somebody wants to finish. Picking the task you resent means you will still be interested on the third afternoon, when the edge cases show up.
A slightly suboptimal automation that exists beats an optimal one that is permanently three weeks away.
Start with a script that does nothing
The version that works for me is to write it in stages, and each stage is useful on its own.
First, a script that gathers all the information and prints what it would do, changing nothing. This alone removes most of the pain, because the dread is usually about assembling the context correctly rather than about the actions themselves. It is also safe to run any time, so it gets exercised.
Second, the same script performs the actions but asks for confirmation. Now you are watching it be right, repeatedly, in production, which is how you learn what it gets wrong.
Third, once the confirmations have been rubber stamps for a couple of months, the prompt goes away and it runs on a schedule.
Most of the value arrives at stage one, which takes an afternoon. Teams that try to jump straight to stage three often never ship anything.
Write for the reader at 3am
Whatever it prints will eventually be read by somebody tired who did not write it. That means saying what it is about to do in plain language, what it decided and why, and what it would take to undo. A script whose output is a stack trace or a bare exit code has automated the doing and left the understanding behind, which is the half that mattered.
Then delete the runbook
The last step is the one that gets skipped: remove the manual procedure, or the next person will find it and follow it. Two paths that both work is a temporary state, and leaving it in place means you now maintain both.