The readiness checklist, item by item, and why each one is on it

The short answer: seven items, and two that decide

An AI readiness checklist is only worth having if every item says what a missing tick will cost you later. A business is ready to automate a piece of work when seven things are true of it. The work happens often. Somebody has written down how it is done.

One named person can change the process, not merely approve spending on it. The data lives somewhere a system can reach. The records in it are clean enough to be believed. You know what the current number is. And the people doing the work would rather have help than be watched.

Two of those override the total. If the process exists only in people's heads, and if nobody inside the business owns the project, a high score on the other five does not compensate. Those are not weaknesses to be outweighed. They are the conditions the rest of the work stands on, and building without them produces a system that is confidently wrong and has nobody with the authority to correct it.

There is a free assessment on this site that scores six of these in your browser and can return a verdict of not yet. It gives you the score. What follows is the part a scoring sheet cannot do: what each item actually means, and what happens when it is missing.

• Frequency: the work happens many times a week rather than a few times a month
• Documentation: the process is written down somewhere that is currently true
• Ownership: one named person can change the process itself
• Reachability: the data sits in something with an export or an interface
• Record quality: the same customer is not in there three times under three spellings
• A baseline: you can state the current number in units your business already uses
• Appetite: the team would use it rather than route around it

Frequency, because importance is a different question

The first item is on every list and is misread constantly. Owners nominate the process that worries them most, which is usually the one that is occasional, high value and full of judgement. That is the worst possible first candidate, because there is not enough of it to learn from and every instance differs.

What makes frequency matter is not the arithmetic of saved effort. It is that repetition is how you find out whether the thing works. A process running dozens of times a day surfaces its exceptions in the first week. A process running twice a month takes a year to reveal the same problems.

The practical version of this item: could you collect fifty real examples of this work from the last month without asking anyone to dig? If not, pick a different process to start with.

A written process, and what its absence actually does

This is the item most businesses fail and most checklists treat as a formality. An undocumented process gives an automation nothing to be accurate against. There is no correct answer to check the output of, so the system is not wrong, it is merely different from what the person who used to do it would have done, and nobody notices for months.

The failure is quiet and specific. The system handles the ordinary cases the way the builder assumed, which is close enough that nobody objects. Then it handles a category of unusual case in a way that is subtly incorrect, and because there is no written standard, the disagreement about whether it is incorrect cannot be settled. Somebody starts doing that category by hand. Within a few months the manual workaround is the process and the automation handles the easy half.

Writing it down is not a document project. One page per process, written by the person who actually does it, listing the steps, the decisions and the exceptions they can remember. The exceptions are the valuable part and are always the part that gets left out of the first draft.

You cannot automate what you cannot describe, and the describing is where most of the real thinking happens.

An owner who can change the process, not only approve the spend

The ownership item is usually scored as whether somebody senior is sponsoring the project. That is a different thing. A sponsor approves money. An owner decides what happens when the workflow meets a case nobody anticipated, approves a change to the process rather than to the tool, and settles a disagreement between two departments about what the system should do.

The test takes ten seconds and is uncomfortable. Name the person. Then check that changing how the work is done sits inside their job rather than being a favour they would have to ask somebody for. If the honest answer is that this belongs to a committee, that is the finding rather than a technicality: a committee can approve a project and cannot own a system.

In a smaller business the owner is often the owner, which works well right up until the busy season. Worth asking in advance who holds it during the weeks when the person who normally decides is unreachable, because that is exactly when the first awkward case will arrive.

Reachable data, a real baseline, and a team that will use it

Reachability is a plain technical question with a plain answer. Software with a proper interface is straightforward. Software with only an export is workable and slower. Records that live on paper, in one person's phone, or in a chat thread mean the first phase of the project is moving them, and that phase should be priced and scheduled rather than discovered.

Record quality is the item almost no checklist includes and the one that causes the most damage. A system inherits whatever you give it. If the same customer exists three times under three spellings, and the real price list lives on one laptop, the system will be wrong at speed and with a straight face. Cleaning records is unglamorous, nobody sells it, and it is usually the first fortnight of real work.

The baseline is simple and has to be taken before the build, because afterwards it cannot be recovered honestly. Measure the thing the project claims it will change, in units your business already uses, over long enough to include a bad week. And on appetite, be honest rather than optimistic. A team told about a system after it is switched on will find ways around it, and they will be right to, because nobody asked them what the work actually involves.

• Where each piece of data lives today, and whether it can be read by anything else
• How many duplicate or stale records exist, counted rather than guessed
• The current number, measured over a period that includes a bad week
• Who checks that number afterwards, and on what date
• Which people in the team have been asked what the process really involves

The items a checklist gets wrong

A readiness list assumes you already have a task in mind. If the real question is which part of the business to look at rather than whether to automate a known process, no checklist answers it, and the useful exercise is measuring where time actually goes for a fortnight before scoring anything.

It also assumes the process should exist at all. Some of the most valuable findings are that a weekly report nobody reads has been produced for four years, or that an approval step has never once refused anything. Deleting a task beats automating it, and no self assessment will point that out, because every item on it is phrased as though the work is a given.

And a checklist answered aspirationally returns an aspirational answer. Score the business as it is this week, not as you intend it to be next quarter. The most common way these lists mislead is that the person filling them in is the person who wants the project approved.

The eighth item, and who to ask about the two that decide

There is an eighth item that belongs on this list and never appears on one. Has anybody decided what the system must never do alone? Money, pricing, anything published in the business's name and any complaint that has turned serious should wait for human approval, and a case outside the written process should hand it to a person with the record attached. A missing tick here costs you in month three exactly as the others do, and it costs more, because this failure is visible to a customer rather than only to you.

The two items that decide, a written process and an owner who can change it, are also the two that make an internal build realistic. A business holding both already owns the difficult half, and where somebody on your own team automates things and will still be there next year, the first build belongs with them. That is not a fallback position. The person who can change the process is the right person to be changing the automation.

Moiz Khan owns automation architecture at Wobble and decides what gets built and how it runs, which in practice means refusing a build where the second item is missing rather than working around it. Haad owns growth and client solutions and takes the conversation when a checklist comes back short. Wobble works from Karachi, bills month to month and is answerable for what it operates across 25 engagements in six countries, and a month to month arrangement is the version of this where a missing tick surfaces early rather than at renewal.

Common questions

What should be on an AI readiness checklist?

Frequency of the work, whether the process is written down, a named owner who can change the process, whether the data can be reached by software, whether the records are clean, a measured baseline, and honest appetite from the team who will use it. The first three carry most of the weight.

Which readiness item matters most?

Two override the rest. A process that exists only in people's heads gives the system nothing to be accurate against, and a project with no internal owner does not survive its first disagreement about scope. Scoring well on everything else does not compensate for either.

What counts as a documented process?

One page per process, written by the person who actually does the work, listing the steps, the decisions and the exceptions. It has to be current rather than approved. A procedure document written two years ago and quietly abandoned is worse than nothing, because a build will be measured against it.

Who should own an AI project inside the business?

A named person for whom changing the process is part of the job rather than a favour they must request. A sponsor approves spending. An owner decides what happens to a case nobody anticipated and settles disputes between departments about what the system should do.

Do we need clean data before starting?

You need records good enough that the system is not confidently wrong. Duplicate customers under different spellings, a price list that lives on one laptop, and stale contact details all get inherited. Cleaning them is usually the first fortnight of real work and should be planned rather than discovered.

What if we score badly on the checklist?

A low score is a work plan rather than a refusal. Write one process down, name one owner, and count one number. Those three cost an afternoon each and change the score more than any purchase does. Automating on top of missing groundwork makes the gaps look like facts.