The AI Automation Readiness Checklist (Before You Automate Anything)

Key takeaways

• Readiness is decided by process fit, data quality, team capacity, and workflow stability — not by how exciting the technology is.
• The best first candidate is high-volume, repeatable, and rule-based, with a clear owner and clean inputs.
• Automation amplifies whatever you feed it: bad data produces fast, confident, wrong results.
• If a process is still changing month to month, document and stabilize it before encoding it in a system.

How to use this checklist

Run through each of the four areas below and answer honestly. For each item, give yourself a simple yes or no. The point is not a perfect score — it is to surface the weak spots that quietly sink automation projects, so you can fix them before they cost you. If an area is mostly 'no', that is where to focus before building anything.

If you have already estimated the time and money a process costs you with our Automation Savings Calculator, bring those numbers here. The calculator tells you how much a process is worth fixing; this checklist tells you whether you are ready to fix it well.

1. Process readiness — is this the right thing to automate?

The instinct is to automate the most painful process. That is usually a mistake — the most painful process is often painful precisely because it is full of exceptions and judgment calls, which are the hardest and riskiest things to automate. The best first candidate is boring: high-volume, repeatable, and rule-based.

• This process runs frequently — daily or weekly, not once a quarter.
• The steps are largely the same every time, with few one-off exceptions.
• The rules can be written down — a new hire could follow them from a document.
• It consumes meaningful hours across the team each month.
• The cost of a mistake is understood, and where it is high there is a clear point for human review.

If you answered no to 'the rules can be written down', stop here. A process you cannot describe step by step is a process you cannot reliably automate yet — document it first.

2. Data readiness — can the system trust its inputs?

Automation amplifies whatever you feed it. Give it clean, well-structured data and it produces consistent results at scale. Give it duplicated records, missing fields, and three spreadsheets that disagree, and it produces fast, confident, wrong results at scale. Data quality is where more automation projects quietly break than anywhere else.

• The data this process relies on lives in a known, accessible system — not only in someone's inbox or head.
• Records are reasonably accurate and current, not riddled with duplicates or stale entries.
• The important fields are filled in consistently, in a predictable format.
• Systems that need to share data can actually connect, through an API or a clean export.
• There is a clear source of truth when two systems disagree.

If you would not trust the underlying data to make a decision by hand, do not trust a system to make that decision a thousand times an hour.

3. Team readiness — will the change actually stick?

A technically perfect system that no one trusts or maintains is a failed project. The human side of readiness is the most overlooked and often the most decisive. Automation changes how people work, and people route around changes they do not understand or believe in.

• There is a named owner who will be responsible for the system after it ships.
• The people whose work changes have been involved early, not informed at the end.
• Someone can handle exceptions and escalations the system hands back.
• Leadership is prepared to redirect the recovered time, not just expect more output for free.
• The team trusts that automation is meant to remove drudgery, not to remove them.

Capacity matters too. A team already underwater rarely has the bandwidth to adopt a new system well, even a good one. Sometimes the right first move is to free up a little capacity before asking people to change how they work.

4. Stability readiness — is the workflow settled enough to encode?

Automation encodes a process as it exists today. If that process is still changing every month — new steps, new tools, shifting rules — you will spend the build chasing a moving target and rebuilding what you just built. Stable processes are cheap to automate; volatile ones are expensive.

• This workflow has run roughly the same way for several months.
• There is no major reorganization, tool migration, or policy change imminent for it.
• The tools involved are ones you intend to keep using.
• Any recent changes have settled, rather than being mid-rollout.

If a process is genuinely in flux for a good reason, that is fine — just stabilize and document it first, then automate. Encoding a moving process is one of the most common ways automation budgets get wasted.

Reading your results

If a process scores well across all four areas, it is a strong first candidate — start there and you stack the odds in your favor. If one area is weak, treat that as the prerequisite, not a reason to abandon the idea: clean the data, name an owner, or stabilize the workflow first. If several areas are weak, you have found something more valuable than an automation project — you have found the groundwork that makes every future automation succeed.

This is exactly the assessment we run in the Diagnose phase of an engagement, with the benefit of an outside operator who has seen these patterns before. If you would rather have it done with you than do it alone, that is where a discovery call starts.

Frequently asked questions

Sources

• The state of AI — McKinsey & Company
• Artificial intelligence research and insights — MIT Sloan Management Review

See where your business is losing time

Book a free discovery call. We'll map where your operations leak time and money and show you which systems would fix it.