Automation readiness checklist: 15 questions before you start
Fifteen questions that tell a small business whether a process is ready to automate, and what to fix first if it is not.
The short answer
Automation projects fail for reasons that were visible before they started: nobody could describe the process precisely, the data lived in five places in five formats, no system was the source of truth, no person owned the result, no number defined success, and nobody had thought about what happens when the automation meets an exception. The fifteen questions below surface those problems while they are cheap to fix. They cover the process, the data, the systems, the people and the risk. A process that answers most of them well is ready to automate. One that does not is not a lost cause; it needs a smaller first step, usually writing the process down and connecting the data, which often delivers value by itself. Run the checklist on three candidate processes and the ranking of which to automate first usually picks itself.
The fifteen questions
| # | Area | Question | Ready when | If not |
|---|---|---|---|---|
| 1 | Process | Can the people who do it describe every step and every decision? | Yes, and they agree | Write it down together first |
| 2 | Process | How often does it run and how long does it take? | Frequent and time-consuming | Pick a higher-volume process |
| 3 | Process | What share of cases are exceptions, and what happens to them? | Exceptions are known and a person will handle them | Define the exception path before building |
| 4 | Process | Is the process stable, or about to change? | Stable for the next year | Wait, or automate the stable core |
| 5 | Data | Where does the data it needs live, and is it complete and consistent? | In known systems, in usable shape | Clean and connect the data first |
| 6 | Data | Which system is the source of truth for each piece of data? | Named for each | Decide, and make it so |
| 7 | Data | Does the process touch personal or sensitive data, and under what rules? | Known, with the legal basis and processing terms in place | Involve your data protection adviser before building |
| 8 | Systems | Do the systems involved have usable APIs or connections? | Yes | Check before promising; some systems block automation |
| 9 | Systems | Where will the automation run, in whose account, with what access? | Business-owned accounts, least privilege | Fix ownership first |
| 10 | People | Who owns the automation after launch? | A named person who wants it | Do not start without one |
| 11 | People | Do the people whose work changes know and agree? | Involved from the start | Involve them; they know the exceptions |
| 12 | People | Who handles what the automation cannot? | Named, with time | Plan the review queue |
| 13 | Risk | What happens when it is wrong, and how would you know? | Errors visible, reversible, monitored | Add validation, review and logging to the design |
| 14 | Risk | Can it be switched off in one step without breaking the process? | Yes, with a manual fallback | Design the fallback |
| 15 | Measure | What number will show it worked, and what is that number today? | Defined and measured now | Measure for two weeks before building |
Using the checklist
- Choose three candidate processes where people feel the repetitive load.
- Answer the fifteen questions for each, with the people who do the work, honestly.
- Score readiness and note the fixes each would need.
- Pick the process with the highest volume, the fewest fixes and a willing owner.
- Do the fixes first: document, clean, connect, decide the source of truth, name the owner.
- Measure the baseline for two weeks.
- Build small, with the exception path, the switch and the log designed in.
- Review at one month against the number, and run the checklist on the next candidate.
What readiness looks like
A process the team can describe and agree on. Data in known systems with a named source of truth. Connections that exist. Ownership in business accounts. A person who wants to own the automation and people who helped design it. An exception path, a switch, a log and a number measured before the build. A process like that is automated in weeks and works for years, and the checklist is how you get one.
What this means for you
Before automating a process, ask fifteen questions about the process, the data, the systems, the people and the risk. Honest answers show whether it is ready and what to fix first, usually documenting the process, connecting the data and naming an owner. Run the checklist on three candidates and pick the one with the highest volume, the fewest fixes and a willing owner. The project that starts ready is the one that finishes.
Frequently asked questions
Do we need to answer all fifteen before starting?
You need to have asked them. Some answers will be no, and each no is either a small fix before the build, such as writing the process down, or a reason to choose a different first process. The purpose is to find out now what would otherwise be found out mid-project, when it costs more and undermines confidence in automation generally.
What if the process is not written down anywhere?
Then writing it down is the first step, and it often delivers value on its own: people discover they do it differently, that some steps are unnecessary, and that the exceptions are where the time goes. A process cannot be automated until it can be described, and the description is a morning's work with the people who do it.
Which of the fifteen matters most?
The owner. An automation without a named person who answers for it, watches its log, handles its exceptions and decides when to change it will fail silently and be discovered late. Everything else can be fixed during a project; the absence of an owner is discovered after it.