The most common reason an automation project stalls isn't the technology. It's that the workflow underneath it wasn't actually stable yet, and nobody checked before starting to build. Here's the short version of what we check before we recommend automating anything.
1. The process has run the same way at least a few dozen times
If a process is still changing shape every few weeks — new steps getting added, ownership shifting between people — automating it just means you'll be rebuilding the automation on the same cadence. Let it settle first. A process that's genuinely still being figured out benefits more from a simple checklist than from a system.
2. You can describe the exceptions, not just the happy path
Anyone can describe what happens when everything goes right. Readiness means someone on the team can list, off the top of their head, the five or six ways this specific process usually goes sideways, and roughly how often each one happens. If the honest answer is "we just kind of handle it when it comes up," that's useful information — it means those edge cases need to be defined before a business process automation can be trusted with them.
3. The data it depends on actually exists in a usable form
A workflow that depends on information locked in someone's inbox, a shared drive full of inconsistently-named files, or a person's memory isn't ready, no matter how well-defined the steps are. Sometimes the real first project isn't the automation at all — it's getting the input data into a structured, reliable place, and the automation follows naturally once that's true.
4. Someone can own it
Every automated workflow needs a human owner — not a committee, one person who gets the notification when something looks wrong and has the authority to fix it. If nobody on the team is positioned to take that ownership, the risk isn't that the automation fails. It's that it fails quietly, for weeks, before anyone notices. This applies just as much to a rule-based RPA bot as to anything with AI in the name — an owner-less bot is the single most common cause of the failures we get called in to fix.
If two or more of these are missing
That's not a reason to abandon the idea. It's a reason to spend two or three weeks stabilizing the process manually first — tightening the exceptions, cleaning up the data, assigning clear ownership — before bringing in automation. We'd rather tell a client to wait three weeks than build something on a foundation that's still moving underneath it. The systems that last are the ones built on a process the team already understands cold.