Start with frequency. A task you do once a quarter almost never earns a system, no matter how tedious it is: the time spent mapping it and building it outweighs what it saves. A task you do daily, or one that fires on an event like a new lead or a support message, is a different story. The more often it runs, the faster it pays for itself, and the more it matters that it runs the same way every time instead of depending on who's doing it that day.
Then look at the decisions inside the workflow, not just the steps. If you can write down the rule you'd use to make a call, like which type of lead goes to which list or which invoice needs a second look, a system can make that same call and act on it, sending the message or updating the record without waiting on anyone. If the decision depends on a read of the situation that lives in someone's head and shifts with context, that part isn't ready to hand off. We map the process by hand first, then say plainly which decisions a system can own and which ones need a person to check the output or make the call themselves.
The other test is whether a system can act through real tools and check its own work, not just draft something for a person to copy and paste. That means real access, like a calendar it can read and write to, or an inbox it can send from directly. If it can act, check what happened, and retry or flag a person when something looks wrong, it can run unattended for a long stretch. If the workflow is still changing shape week to week, or a mistake would be hard to undo, like a contract going out wrong or a public reply to an upset customer, keep a person on that step even after the rest is automated. Not every workflow clears this bar. Some are rare enough, or judgment-heavy enough, that leaving them manual is the honest call.