The 10-question AI readiness check
Before you buy a tool, answer these ten questions. They tell you whether AI will compound inside your business or quietly rot in a tab nobody opens.
Most AI projects inside operating businesses do not fail on the model. They fail because the process being automated was never written down, the data lives in someone's head, or nobody owns the output once it exists. The check below finds those problems in an afternoon instead of six months.
Score each question 0, 1 or 2. Zero means no, one means partly, two means yes with evidence. Add it up at the end.
Process
- Can you name the single task you want automated in one sentence, without using the word 'and'?
- Does a human do that task today on a repeating schedule, and can you say how many times per week?
- If you asked two people on your team to do that task, would they produce roughly the same output?
- Is there a written definition of what a correct output looks like?
Data
- Is the input the task needs available in a system, rather than in a WhatsApp thread or somebody's inbox?
- Can you export twelve months of past examples of this task, inputs and outputs both?
- Do you know who is allowed to see that data, and is there anything in it you cannot send to a third party?
Ownership
- Is there one named person whose week gets measurably better if this works?
- Does that person have the authority to change the process, not just observe it?
- Have you agreed what number moves, and by how much, for the project to be worth keeping?
Reading your score
| Score | What it means | What to do next |
|---|---|---|
| 16 to 20 | Ready. The process is defined, the data exists, someone owns it. | Scope a narrow first build. Ship in weeks, not quarters. |
| 10 to 15 | Nearly. Usually the gap is a written definition of correct output. | Spend one week documenting before you spend money on tooling. |
| Below 10 | Not yet. Automating here will amplify existing confusion. | Fix the process first. The AI project gets cheaper and faster afterwards. |
The three failure patterns
- Automating the loud problem instead of the expensive one. The thing people complain about is rarely the thing costing the most hours. Count before you choose.
- Building for the exception. Teams describe the hardest ten percent of cases because that is what they remember. Build for the ninety percent and route the rest to a human.
- No owner after launch. A system with no owner degrades silently. Someone has to look at the output weekly and be allowed to change it.
If you want a second read on your score, we do a free discovery call where we walk through it against your actual numbers.
Want a second read on this?
We run a free discovery call and walk through it against your real numbers.
Book a discovery call