Free · No email required
Twelve questions to work out whether AI or custom software would actually move the needle in your business — and which of them you need to answer before spending anything.
These are the questions I ask in a first conversation. Working through them yourself is genuinely useful whether or not we ever speak; if several answers come out uncomfortable, that’s the information, not a failure.
Short answer
An AI readiness checklist is a short set of questions that tests whether a business can actually deliver an AI project before it spends money on one. A workable checklist covers twelve things: the specific task that would change, how long it takes today and how often, where the data lives and whether you can get at it, whether everyone does the work the same way, who owns the definitions, what happens when the process fails, how much accuracy the outcome truly requires, who reviews uncertain output, whether you can deploy software safely, who maintains it after handover, what another year of the status quo costs, and what the next project would be if this one works.
If you can answer the first five with specifics, you are ready to scope a build. If you cannot, the honest first project is mapping the process and securing data access — not a model.
“Use AI in operations” is not a project. “Stop the finance team keying invoices by hand” is. If you can’t name the task, the scoping conversation has to happen before any build conversation does.
If the answer is a department rather than a task, you’re not ready to buy yet — and any supplier who takes the brief anyway is selling you discovery at build prices.
Hours per week and frequency are what turn a project into a number. Without them you can’t judge whether a fix is worth its cost, and you won’t be able to tell afterwards whether it worked.
A rough figure from the person who actually does the work beats a precise one from a manager’s estimate.
Not where the architecture diagram says. In practice it’s often split across a database, a reporting tool, somebody’s spreadsheet and a vendor system whose API costs extra.
If an essential system has no API and no export, that constraint reshapes the whole project. Find out before scoping, not during.
Automation encodes one process. If three people each have their own version, the project includes deciding which one is correct — and that’s a management decision, not a technical one.
Undocumented variation is the most common reason automation projects run over.
What counts as an active customer, a qualified lead, a closed month. Reporting and AI projects stall here constantly, because nobody has authority to settle it.
If you can’t name the person who decides, that’s the first thing to fix.
Every process has a failure path, usually informal — someone notices, someone rings someone. Automation has to handle that path too, and it’s rarely in the brief.
If nobody can describe the current failure path, it’s because failures are being absorbed silently. They’ll stop being silent once a system is doing it.
AI systems are probabilistic. For routing a support ticket, occasional errors are fine. For calculating statutory payments, they are not — and that difference decides whether AI is the right tool at all.
If the honest answer is “it must be right every time”, you may want deterministic software rather than a model.
Most systems that work well keep a human in the loop for the uncertain cases. That person needs capacity, and their review has to be quicker than doing the task themselves — or they’ll stop.
An exceptions queue nobody has time to work is just a backlog with better branding.
If releases are manual, undocumented, or depend on one person, that constrains everything built afterwards — including how fast problems can be fixed.
Sometimes the honest first project is the pipeline, not the thing you came in asking for.
An internal team who’ll own it needs different documentation than a system expected to run untouched for two years. Both are legitimate; they cost differently.
If the answer is “nobody”, build for that explicitly instead of pretending otherwise.
This is the number that decides whether to act now or later, and it’s the one most often skipped. Sometimes it’s small, and the right decision is to do nothing.
If you can’t make the cost of inaction concrete, the project will keep losing budget arguments to things that can.
A first project that opens a path is worth more than one that solves a problem and dead-ends. Knowing the direction changes architectural choices early, when they’re cheap.
You don’t need a roadmap. You do need to know whether this is a one-off or a first step.
That’s normal, and it’s not a reason to wait. Questions three, four and five in particular tend to be answered properly only once someone sits down with the people doing the work — which is what the first conversation is for.
Common questions
An AI readiness checklist is a short set of questions that tests whether a business can actually deliver an AI project before it spends money on one. It covers the task being changed, how long that task takes today, where the data lives and whether it is accessible, whether the process is consistent between people, who owns the definitions, what happens when the process fails, how much accuracy the outcome requires, who reviews uncertain output, whether software can be deployed safely, who maintains the result, the cost of doing nothing, and what comes next if it works.
You are ready when you can name one specific task, quantify how long it takes and how often it happens, point to the systems that hold the data and confirm you can extract it, and name the person who will review uncertain output. If any of those four is missing, the first piece of work is scoping and data access rather than model building.
You need the records the task already runs on — documents, tickets, orders, invoices or transactions — in a system you can export from or query through an API, with a recent enough history to be representative. Roughly a few hundred real examples is usually enough to judge feasibility. Perfectly clean data is not required; knowing where it is and being able to get at it is.
Working through the twelve questions on this page yourself takes about thirty minutes. A facilitated assessment with the people who do the work, including data access checks and a written recommendation, typically takes one to two weeks.
Only if it ends in a decision. A useful assessment names the first project, the data it depends on, the accuracy threshold it must meet and what it will cost — or recommends not building anything. If it ends in a maturity score without a next project, it has not paid for itself.
Three dominate: the brief names a department rather than a task, an essential system has no API or export, and the same process is done differently by different people so there is no single version to automate. All three are cheaper to find before a build than during one.
