The short answer
Automate a frequent, stable task with a clear result and a manageable failure path. Measure the manual effort first, then pilot one workflow. Avoid starting with high-impact decisions or processes whose rules keep changing.
Watch the work happen
Ask the person doing the task to walk through a real example. Record what starts it, where the information comes from, which tools they open and how they know it is finished. Include the corrections and workarounds. A process diagram that leaves out the awkward parts is not ready to build.
Look for a small, useful win
Shortlist work that is frequent, follows stable rules and is easy to check. Copying approved form data into a CRM is often a more manageable starting point than automatically approving a complex customer request. Choose a task that matters to someone, not a demonstration built only because the technology is interesting.
Count the actual effort
For a week, record the number of times the task happens and the minutes spent each time. Include checking, chasing and fixing errors. Estimate what would still need human attention after automation. This gives you a baseline to compare against setup cost, subscriptions and maintenance. It is an estimate of capacity, not a promise of cash savings.
Write the failure plan
Decide what happens when a field is missing, a record already exists, a tool is unavailable or someone changes their mind. Give exceptions an owner and a place to wait. Make it possible to see what happened without reading technical logs.
Pilot before expanding
Run a limited pilot with representative cases and compare it with the manual process. Keep the original route available until the result is dependable. Expand only when the team can explain the workflow, recognise a failure and recover from it.
Your next step
Bring one real example, your current tools and a rough weekly volume. That is enough to start a useful conversation.
Explore the related solution