If you or your team find there's some process that needs to be done regularly, you're right, it should be automated. But there are often barriers to doing that immediately, and you may not even agree on what all the steps are. Here's how you do it then:
1. Write the runbook.
2. Execute the runbook multiple times.
3. Modify and improve the runbook.
4. Automate parts of the runbook.
5. When the entire thing is automated, hook it up to a metric to run automatically.
6. Delete your manual runbook - keep this new piece of code documented with its history and steps of improvement and eventual automation.
This method means you get consistency of a method almost immediately, don't need to fight product to spend a ton of time on it (you can spend 30 minutes here and there on a single step), the team has better conversations about ad-hoc process, and you eventually automate it.
In my job we have to do code releases to customers. This means we take a repo, do some tidying up like removing internal comments, inline some dependencies, make sure the README is in good shape, then make sure several people are notified and can approve it.
I wrote a scrappy runbook with like 10 bullet points because this was being done really inconsistently. A month later it had been improved a ton by engineers with detailed command lines and roll back steps. Now they're starting to automate parts of it. We don't have explicit time for this, but we got a consistent process straight off the bat, engineer buy-in to the process and improving it, and bit by bit we will get to a point where it becomes a one-liner without us feeling we had to carve out a chunk of time specially for it.
What's not to like?