Most AI automation projects that disappoint did not fail on the technology. They failed because the process was fuzzy, the data was not really available, or nobody agreed what success meant. A short readiness check before you build catches almost all of these problems while they are still cheap to fix.
This checklist is not about gating good ideas. It is about pointing them at processes that will actually reward automation, and about surfacing the missing pieces early so the project starts from solid ground rather than optimism.
Is the process clear and stable?
If you cannot describe the process in steps, with the rules and the common exceptions, it is not ready to automate. Automating a vague process just encodes the confusion faster. Write down the happy path, the branches, and what a good outcome looks like, and confirm that the people who run it actually agree with that description.
Stability matters too. A process that changes every few weeks, or that everyone runs differently, needs to be settled before it is worth automating. If it is genuinely in flux, standardize it first, then automate the version you have agreed on.
Is the data actually available and trustworthy?
Almost everyone says the data exists. The real questions are whether you can access it programmatically, whether it is complete, and whether it is correct often enough to rely on. Pull a real sample and inspect it: how many records are missing fields, how many formats appear, how stale is it, who changes it and when.
This is also where you find the unstructured inputs, the PDFs, emails, and photos that carry critical information. AI can read these, but you need to know their volume and variety upfront so the design accounts for the messy cases instead of assuming clean input.
Where do humans stay in the loop?
Decide before go-live which steps run unattended and which require a person to confirm. Anything that commits money, touches a contract, or closes a customer issue usually warrants review until you have measured evidence of reliability. Name the owner for each exception type so flagged items have somewhere to go instead of piling up.
The aim is a fast review, not a bottleneck. The system should propose, show its reasoning, and let a person confirm or correct in seconds. That correction data is also how the automation improves, so treat review as part of the design, not an afterthought.
How will we know it worked?
Agree on the metric before you start and capture a baseline: hours spent today, error or rework rate, cycle time, backlog size. Without the before, you cannot prove the after, and the project becomes a matter of opinion. Pick one or two metrics that leadership already cares about and measure them the same way before and after.
Finally, plan the change with the people doing the work. Automation that lands as a surprise gets resisted or worked around, no matter how good it is. Involve them in defining the process and the review points, show them how exceptions reach them, and the same tool that felt threatening becomes something they rely on.