Where automation actually pays
Automate what is repetitive, rule-based and frequent. Everything else usually needs better information, not less human involvement.
Read this in Bahasa MalaysiaAutomation projects fail in a predictable way: someone picks the most visible process rather than the most suitable one, and discovers halfway through that the process was never really written down.
The three tests
Is it repetitive? The same shape of work, again and again.
Is it rule-based? You could write the decision down without saying "it depends".
Is it frequent? Often enough that the time it consumes is measurable.
Work that fails any one of these is usually a poor first candidate, however annoying it is.
The exceptions are the whole problem
Most processes are simple until you ask what happens when the invoice arrives without a purchase order, or the customer replies to the wrong thread. Those exceptions are where automation projects quietly die.
Document them before building anything. If nobody can enumerate them, that is your finding: the process is not yet understood well enough to automate.
What it is not for
Automation does not fix a broken process, it accelerates it. If the workflow is wrong, you will now be wrong faster and with more confidence.
The aim is to remove the repetitive part of a role, not the role. The work worth automating is usually the work nobody wanted to do by hand.