Automation has an unusual failure mode. When it goes wrong, it rarely stops. It carries on, quietly, producing results nobody is checking, until something downstream breaks badly enough for somebody to look.
That is worth keeping in mind before you automate anything.
First: does anyone actually know how the process works?
Not the documented version. The real one, including the step where somebody checks the thing that is usually wrong, and the exception that gets handled by a phone call.
Map it by watching it done, not by asking in a meeting. The gap between the two is where automation projects fail, because the undocumented exception handling is usually the part that mattered. If three people describe the process differently, you have found the real problem, and it is not a technology problem.
Second: is the process stable?
Automating something that is about to change is building on sand. If a process is under review, or the person who owns it is about to leave, or a regulation affecting it changes next quarter, wait. The automation will be rewritten, and the rewrite is rarely cheaper than the original.
Stability matters more than volume here. A stable process that runs twenty times a week is a better candidate than a volatile one that runs two hundred.
Third: what happens when it fails?
This is the question most often skipped, and the one that separates automation that helps from automation that causes an incident.
Every automated process needs three things decided in advance: how a failure is detected, who is told, and what the manual fallback is. If a nightly job stops running, somebody should know within hours, not at month-end. We build alerting into every automation we deliver for exactly this reason -- a silent automation that stopped last Tuesday is worse than no automation, because the whole team has stopped checking.
Fourth: should a human still decide?
Some steps are rules and some are judgement. Rules automate well. Judgement does not, and dressing judgement up as a rule is how organisations end up with decisions nobody can explain.
The useful pattern is almost always partial: automate the gathering, the formatting, the routing and the chasing, then stop and let a person decide. That removes most of the hours without removing the accountability. An approval step that takes thirty seconds because everything is already assembled is not a bottleneck.
Working out whether it is worth it
Once you have mapped the process, the sum is simple. Hours it consumes per week, times the loaded cost of the people doing it, times fifty, against the cost of building and running the automation.
A process consuming a few hours a week usually repays a focused build within months. One consuming twenty minutes a month almost never does, however annoying those twenty minutes are. We run this calculation before quoting, and we have talked clients out of automations on the strength of it.
Start with the one that hurts
Do not begin with a programme. Begin with the single process your team complains about most, automate that one properly, with alerting and a fallback, and let it run for a month.
What you learn from that one will tell you more about where to go next than any amount of planning.