AI Readiness Checklist Before You Buy a Tool

An AI readiness checklist is the list of questions you answer before you pay for a tool. We use it when an owner has a demo booked. The owner has not yet said which job the tool is for. The questions fall into four groups, which are data, process, people, and the decision. A vendor’s feature list cannot stand in for any of them.

Cited in this note

63%

The Readiness Check scores the same four groups. The assessment note compares the public tools, and the data note stays on the first group. If the process score is your weak spot, the process guide is the page we hand over.

We think of the checklist as a brake. The tour of a tool always looks tidy. The real test comes on the busy afternoon after it, when nobody remembers which screen is the right one. A tick means you can point to the answer, and a blank means you cannot. The blanks are the useful part.

Data and process

Here are the questions for the first two groups. Can you name the one place the facts live for this job? Is it current, and can a system read it without someone retyping it? Is the job written down, including the exceptions, and does one person own the handoff?

We ask these out loud. The person who does the work must be in the room, and not only the person who signs the check. The owner answers from memory, and the person at the counter answers from last Thursday. When the two disagree, the list has already paid for itself.

Every shop we sit in has more than one place where a fact can live. There is the notebook, the spreadsheet the bookkeeper trusts, the supplier portal, and the text thread. The record you mean is whichever one the next person will believe when they disagree. If you cannot name that one, a new tool just becomes another place to hunt.

Next we ask whether the record is current and whether a system can read it. A record that gets patched from memory is more of a souvenir than a source. For an open order, current means the status changed when the part came in. It does not mean someone updated it after they remembered to call. If someone still has to retype the record, the tool will wait on that person. Retyping is the job you have not replaced yet.

The process questions sit beside the data questions because a clean record with no written handoff will still stall. We want the happy path and the exceptions too. What happens when the part is wrong? What if the customer does not answer, or the usual person is out? If those live only as habit, the tool will follow the happy path and make up the rest. One person has to own the handoff, even on the day that person is out. A handoff that everyone owns tends to belong to no one.

In February 2025, Gartner reported that 63% of respondents do not have the data practices that AI needs, or are not sure they do.¹ The same note says that through 2026 companies will abandon 60% of AI projects that lack AI-ready data. We read that as a reason to treat the data questions as the main event. A large firm and a small counter can fail the same way. The record is not ready, and the project dies once the demo fades.

AWS published a checklist in September 2025.² It walks through five steps. It sorts a business into four stages, called Not yet ready, Emerging, Operational, and Scaling. The page does not cite an adoption percentage, and we like that. A stage name is a description you can argue with. If a page will not say how many firms it counted, do not turn its silence into a rate.

We use those stage names as labels and not as a grade. Not yet ready means the job still lives in one person’s head. Emerging means some of it is written down while a lot of it is habit. Operational means your staff can run the job without a hero. Scaling means you repeat a pattern instead of finding it. You do not have to adopt the labels, but you do have to say which one fits.

We open the process guide when this half of the list is mostly blank. We fix the writing before we fix the software. A short written handoff, with the exceptions on the same page, beats a tool that thinks the handoff is already there.

People and the decision

Who may use a tool, and who may send its output to a customer? Those are the people questions, and they are where checklists tend to go soft. “Everyone will use it” is not an answer. A name is an answer, and so is a rule about what can leave the building.

Microsoft’s 2024 Work Trend Index says 75% of knowledge workers use AI at work. It says 46% of those users started less than six months earlier.³ It also says 78% of AI users bring their own tools, and at small and midsize companies that share is 80%. It also says 60% of leaders worry that their company’s leadership lacks a plan and vision to put AI in place.

In a small company those figures show up as one person. Someone is already pasting notes into a personal account because the official way is slow. They are only trying to finish the day. A checklist that never asks who brought a tool in will miss the real system. That system is often the one in a coat pocket.

We ask who uses the tool on a normal day. We ask who may send its words to a customer. We also ask who can stop it when it is wrong. If nobody can stop it, you do not have a people plan. You have a hope that the errors will be obvious.

The decision questions are separate. What would count as success, who can stop the experiment, and what happens if the tool is wrong? “Sam will keep an eye on it” names a person. “The customer hears from the record, not from memory” is a decision. So is “if it sends a wrong message, we turn it off the same day.” We write each one on its own line.

A tick list does not tell you which gap is largest. The Readiness Check turns the same four groups into a band. We still want the paper list first. A band without a talk is just a costume on a number. The list is the talk. The band is what you get when you want the same questions scored the same way next time.

When the room is being polite, we add one more decision question. What will you stop doing if this works? If the answer is nothing, the tool is a hobby. The checklist is allowed to end with a no. A no that names the blank box is a better result than a yes that names a logo.

A worked example

Say we are sitting after close with the owner of a neighborhood hardware shop. A counter lead and a bookkeeper are there too. This is an example we walk through, and it is not a report of a shop we measured.

The owner wants a tool that drafts the message saying a special order is in. It would also suggest which supplier to chase. The demo was slick, but the checklist is the part where we ignore the demo.

We start with data. The owner says the computer is the one place the facts live. The counter lead keeps a notebook because the computer is wrong whenever a quantity changes at the counter. The bookkeeper trusts a spreadsheet she updates from supplier emails. She has to pay someone, and the other two records disagree. So the box for one place the facts live stays blank. We ask which record he would trust if the owner were out, and the counter lead says the notebook. Then he says he would call the bookkeeper. That makes a person the record. A person can be a bridge, but a tool cannot read a person.

Then comes the process. A part arrives, someone calls, the customer picks up, and the bookkeeper marks it paid. That is the easy happy path. A damaged part goes on the back shelf until the counter lead deals with it. A customer who does not answer gets one more try, and then the order just sits. None of that is written down. On days when the counter lead is at the other site, the handoff has no owner. We refuse to count the happy path as the whole process.

Then people. The counter lead already uses a chat tool on his phone to reword messages. He does it when he is tired of sounding stiff, and the owner did not know. We do not scold him. Instead we write down the question the checklist was made for. Who may send those words to a customer, and who may not?

Then the decision. The owner says success is less chaos, so we push once. Success is that a customer hears about an arrival from the record, and not from the counter lead’s memory. The bookkeeper should also see the same status the counter lead sees. If a message goes out wrong, the owner can stop the trial herself without waiting for a vendor. That line is what lets her buy later without betting the shop on a login.

We leave with blanks on data and process and a surprise on people. The decision is finally a sentence. Nobody bought anything, and that is the checklist working.

How we’d run it

We run it as a short working session and not as homework we email into the void.

First, we pick one job, and not the whole business. We want one job with a start and a finish. In the shop that job is the special order. It runs from the promise to the moment the customer has the part or hears that it failed. If you pick every job, you will not tick anything honestly.

Second, we put the people who touch that job in the room. The owner alone will describe the job she wishes existed. The counter lead will describe the job that exists, and the bookkeeper will describe the job that gets paid. All three answers belong on the sheet.

Third, we walk through data, then process, then people, then the decision, and we write the blanks in ink. We do not shop for tools in the middle. If someone says the new software would handle that, we write “not handled today” and keep going.

Fourth, we read the blanks back and name one owner for the next change. If the missing record is the blank that matters, the two of them agree on what they will treat as the record on ordinary days. The owner’s job is to back that choice when it is inconvenient.

Fifth, and only then, we look at tools with the sheet on the table. Any feature that does not touch a ticked box or a named blank is a distraction. If the blanks are still the whole story, we stop. A process blank goes to the process guide. The same four groups go to the check when we want a band instead of ticks.

We book the session after the rush. We keep it short so the counter lead is not watching the door. A checklist filled in by the owner alone at midnight will be full, but it will be wrong.

Common mistakes

The mistake we see most is ticking the box you hope is true. “We have a process” often means a binder from a quieter year. If the counter lead cannot find the page for a damaged part, you do not have a process for the job you are buying for.

Another mistake is letting the vendor’s questionnaire replace yours. Their questions ask whether you can be a customer. Yours ask whether the job can survive contact with a tool. Keep yours, even if yours is a notebook page.

A third mistake is calling a shared inbox a system of record. An inbox is a pile that happens to be searchable, and it is current only if someone sorted it. The checklist asks whether a system can read the record without a person retyping it. A pile fails that test.

We also watch owners score their own confidence and write down only the happy path. Confidence is a mood, but the checklist is a pointing exercise. The exceptions are the list.

What we’d do

We would not buy in the meeting where the checklist is first filled in. We would buy later, for one job. First the one place the facts live needs a name, and the handoff needs a person. Our view is simple. A tool on top of three records will just make another record. You will pay a fee and still call the bookkeeper.

If we were the owner, we would spend the next few ordinary days on one thing. The counter lead and the bookkeeper would write status in one place, including the damaged-part case. We would also pause the counter lead’s phone tool for customer messages. It stays paused until the owner says what may be sent. That is a smaller project than a new platform. It is also the project the checklist was trying to start.

We would treat a full page of ticks with suspicion and a short page of blanks with respect. The blanks are the work, and the tool can wait.