An automation should remove a defined burden. Start by understanding the work, the decisions and the exceptions.
Write down what actually happens.
The documented process and the real process may differ. Ask the people doing the work what triggers it, what information they need and where they make a judgment.
Pay attention to the manual step that looks unnecessary. Sometimes it exists because the information is unreliable or an exception needs human attention.
Separate rules from decisions.
Some steps are consistent enough to automate with a clear rule. Others require review. Treating those as the same problem can make a process harder to trust.
Define what the system can change, what it should suggest and when it should stop for a person. That boundary is part of the design.
Design the failure path.
A connection can be unavailable. A record can be incomplete. A task can be repeated. Someone needs to know what happened and how to continue without guessing.
The simplest useful automation is often a good first step. Put it into use, learn from the exceptions and expand only when the work calls for it.