What this checklist actually checks
This isn't a maturity model with a score out of a hundred, and it isn't a sales qualifier dressed up as a favor. It's five short sections — the process, the data, the systems, the people, and the commercial case — each with a handful of specific questions. Work through them against one real candidate process, not "AI" as a category picked from a wishlist.
If you're weighing several candidate projects at once and need to rank them against each other, that's a wider job than a checklist can honestly do. That's what an AI strategy engagement is for — an audit that compares several candidates side by side and sequences them. This page is the pre-flight version: is the business ready to automate anything at all, using one real process as the test case.
The process: is there actually a process to automate?
Automation formalizes whatever you give it. If the underlying process is vague, undocumented, or different every time someone does it, automating it just makes the mess run faster.
- Is it documented anywhere, or does it live in one person's head? If the only description of how this works is "ask Sarah," that's not a gap you can automate around — it's the first thing that needs fixing, documentation before software.
- Does the documented version match what actually happens? Plenty of process docs describe how work was supposed to run two reorganisations ago. Walk the real thing, live, with the person who does it, before assuming the flowchart is still true.
- Does it happen often enough to be worth automating? A process that runs twice a month rarely justifies a build, however annoying it is when it happens. Save the automation budget for something that repeats weekly or more, where a small win compounds.
- Is it stable, or about to change? If the team is mid-reorg, switching CRMs, or renegotiating the vendor contract this touches, wait. Building against a process that's about to move is building on ground that's already shifting.
The data: does it exist somewhere a system can reach it?
Every AI project is downstream of data, and this is where good ideas most often stall once the build actually starts.
- Does the data exist at all? Not "could someone find it out" — does a record of it already get created somewhere as a normal part of doing the work.
- Is it in a system, or in someone's head, a spreadsheet, or a stack of paper? Data that lives in a system is a starting point. Data that lives in a person's memory or a personal notebook isn't data yet — it's a process problem wearing a data problem's clothes.
- Is it consistent enough to act on? Free-text fields where everyone spells things differently, five ways of recording the same status, duplicate customer records — these don't block a human doing the job by eye, but they quietly break an automated one.
- Who owns it, and can they get you access? Someone needs to be able to say what a field means, whether it's trustworthy, and grant a system permission to read it. If no one can answer that today, that's the finding.
The systems: can anything actually connect to what you have?
Good process and clean data still need a door in. This is the section that most often surprises people who assumed "it's all in the cloud" meant "it's all reachable."
- Do your systems have APIs, or only a screen a person logs into? An AI agent is only as capable as the systems it can reach programmatically. If the only way in is a human clicking through a browser, that changes what's realistically buildable, not whether anything is.
- Who holds admin access, and are they available? Every integration needs someone with the authority to grant a connection. If that person left the company, is a contractor who's moved on, or is a vendor's support queue with a multi-week backlog, know that before you scope anything.
- How long does it take your organisation to grant access to anything new? Some businesses can provision a new integration the same afternoon. Others need a change request, a security review, and three signatures. Neither is wrong, but the second one changes your timeline more than the build itself does.
The people: who's going to own this after launch?
A system that nobody owns after the handoff degrades quietly until someone notices it's been wrong for weeks.
- Who owns it after launch? Not who commissioned it — who will notice when it needs a small adjustment, and who has the standing to make one. If the honest answer is "nobody yet," that's worth solving before the build starts, not after.
- Who can actually decide? Every project needs someone who can approve scope, sign off on the finished system, and say yes to the next change without escalating it three levels up. If that person isn't identified, delays show up later as an unowned decision, not as a missing feature.
- Will the team actually use it? A system that's technically correct and practically ignored is a failed project with a working demo. If the people doing the work today weren't part of shaping what gets built, that's a real risk, not a detail.
- Whose job changes? Automating a task changes what the person who used to do it does next. Naming that plainly, and having an honest answer for it, heads off the quiet resistance that sinks otherwise well-built systems.
The commercial case: can you actually measure what this costs today?
An AI project is a bet that a cost you can see is worth paying to remove. That only works if you can actually see the cost.
- Can you measure the current cost? Hours spent, error rate, how often something slips or gets followed up late, how long customers wait. A rough figure, honestly estimated by the person doing the work, is enough — you don't need a finance team's precision, just a real number instead of a feeling.
- Would you actually redeploy the time saved? If the time this frees up will get filled with other real work — more calls handled, more deals moved forward, faster turnaround — the case is strong. If the honest answer is that the same three people would still be just as busy doing something else, the return is smaller than the automation looks on paper.
Once you can put a number on the current cost, you're also in a position to weigh build against buy honestly, instead of defaulting to whichever option a vendor's sales call steered you toward.
What your score actually means
Don't tally this into a single number. Read it in three groups instead.
Strong across most sections. The process is documented and stable, the data exists somewhere reachable and consistent, the systems have a way in, someone will own it, and you can name a real cost today. You're ready to scope a first project — the first AI project guide covers how to pick a good one to start with.
Mixed. This is the most common result, and it does not disqualify you. It means you have a different first project than the one you walked in wanting to build. If the data is the weak spot, the first project might be cleaning and centralising it. If ownership is the gap, the first step is naming an owner before anyone writes a line of code. A mixed result is information about sequence, not a verdict on whether AI is right for your business.
Failing several sections at once. Specifically: nobody agrees on how the process actually runs, the data that matters lives in five people's inboxes, there's no way to reach any relevant system programmatically, and no one can say who'd own the result. That combination is a strong signal to fix the underlying process or data problem before automating around it — automating a broken process just breaks things faster and with more confidence. That's still not a dead end. It's a different, usually smaller, first project: get the process written down and agreed, get the data into one place, and revisit this checklist in a few months once those are true.
Whichever group you land in, working through this honestly beats guessing. If you're not sure how to read your own answers, or you want a second opinion before committing budget, that's a short conversation, and it's also worth reading how to pick the right partner once you are ready to move, covered in the guide to choosing an AI agency.