Most automation projects fail long before anyone writes code. They fail at the choosing, when someone picks a task because it sounds impressive rather than because it is expensive. Here is the checklist I run first.
Is the task written down anywhere?
If nobody can describe the steps, there is nothing to automate yet. What you have is a habit living in one person’s head, and habits are full of exceptions that only appear once the machine is already running.
Write the steps out. Half the time that reveals three steps you can delete, which is a cheaper win than any tool.
What does it cost today?
A number, not a feeling. Times per week, multiplied by minutes each, multiplied by who does it. Guess if you have to, but write the guess down and date it.
Without a baseline you cannot tell the difference between something that worked and something that felt new.
Thirty days later, this number is the only thing that can tell you whether the change earned its place.
Does it fail loudly or quietly?
A task that fails loudly is safe to automate. The invoice does not send, the report is missing, and you find out the same day.
Quiet failures are the problem. A number wrong by a decimal, a customer reply that is confidently incorrect, a file that never gets filed. Those need a person in the path, and if you cannot name who that person is, the task is not ready.
Where does judgement live?
Almost every workflow has one step that is a decision. Find it and keep it human, at least at first. Automate the fetching and the formatting and the chasing. Leave the call.
Aim for a task where the boring nine tenths happen without you and the interesting tenth arrives on your desk already prepared.
Would you start with it again?
Come back to this one on day thirty. If the answer is no, stop. A trial you end after a month cost you a month. A tool nobody will admit is useless costs you every month for years.