The businesses that get the least from AI are the ones whose process was never written down.
"Are we ready for AI?" almost always arrives as a budget question or a technical one. It is neither. Readiness is a question about process clarity.
What readiness means
Readiness for operational AI means you have at least one process that is documented, owned, whose data is reachable, and that contains a decision you are willing to hand to a system.
None of those four conditions concerns budget or technical expertise. A small business with one clear process is readier than a large organisation with a large budget and implicit processes.
Ten questions in three groups. One point per yes.
Questions 1 to 4 — is the process documented and owned?
- Can you write this process out, step by step, in under one page? If writing it requires asking three people, the answer is no.
- Does each step have a named owning role? Not a team — a role.
- Are the exceptions defined? If the answer is "it depends on the case", the system will learn exactly that.
- Do two different people running this process produce the same result? This is the most practical test on the list.
Questions 5 to 7 — is the data reachable and trustworthy?
- Is the data this process needs readable from one place? If it is spread across three systems and a spreadsheet, that is your first project, not AI.
- Do you know what share of records are incomplete or stale? Not that they are complete — that you know the figure.
- Do you have history? At least six months of past outcomes for this same process, so you can tell whether the system is better.
Question seven eliminates the most candidates. Without a baseline there is no way to know whether the project succeeded, and it ends in an argument about taste.
Questions 8 to 10 — is there a decision to hand over?
- Is there a specific decision the system is allowed to make? Not "decision support" — a real decision with an output.
- Are you willing to accept the outcome when that decision is wrong? If every error requires explaining to a stakeholder, the system effectively has no authority.
- Is the escalation path defined? Who, and within what deadline.
Scoring
| Score | State | Next step |
|---|---|---|
| 8 to 10 | Ready | Start with one process, not a platform |
| 5 to 7 | Close | Close the "no" answers — usually two to four weeks of work |
| 3 to 4 | Early | Write the process and ownership first; automation later |
| Below 3 | A different problem | AI will not solve it and will not hide it |
An important note on the last band: a low score does not mean a bad business. Plenty of profitable businesses run on implicit coordination and are entirely healthy. They simply lack the surface automation sits on.
Why documented process is a necessary condition
This gets lost in most discussions. An intelligent system does not discover your process; it executes it.
If the process lives in three people's heads and each holds a slightly different version, the system encodes one of those three — or a blend. The result is a system that sometimes works, and nobody can say why it sometimes does not.
This is what gets reported as model hallucination and frequently is not a model problem at all. The model is reflecting the ambiguity of its input.
The question deliberately left off the list
There is one question almost everyone asks first and it does not appear in these ten: "do we have a technical team?"
Its absence is deliberate. Having a technical team is neither necessary nor sufficient. Organisations with strong teams have failed AI projects, because the process being automated was never defined.
Technical capacity is a sourcing problem — it can be bought, rented, or trained. Process clarity is an internal problem nobody outside can solve for you, because it requires decisions only you are permitted to make.
Which is why all ten questions concern things inside your control.
After you reach an acceptable score
A score of 8 does not mean starting a large project. Three rules that work in practice:
- Start with the narrowest process available, even where its financial value looks small. The first project exists for organisational learning, not for return.
- Record the baseline before changing anything. After deployment, nobody can recall the previous state impartially.
- Write the stop criterion. Under what conditions do you halt this project? Without one, unsuccessful projects continue for years on the strength of sunk cost.
A worked example: a score of 4 and a project that paused
A services company wanted to automate responses to inbound enquiries. Volume was high and the problem was real.
The assessment scored 4. Three key questions came back no: the process was undocumented, two different specialists gave two different answers to the same enquiry, and there was no baseline for current response quality.
The decision was to delay three months. In those three months the process was written, the disagreement between the two specialists was examined — which itself exposed two genuine ambiguities in company policy — and a sample of past responses was recorded as a baseline.
When the project did start, it took three weeks. The original estimate had been three months.
What those three months achieved was straightforward: they removed the ambiguity the system would otherwise have had to wrestle with.
The limit of this assessment
These ten questions concern operational readiness, not whether the work is financially worth doing. You can score 10 and still find the project uneconomic because volume is too low.
The economic test is separate and simple: human time released, multiplied by frequency, against build and maintenance cost. If payback runs beyond eighteen months, you have probably chosen the wrong process.
My score is low. Where do I start?
Question four. Making two people's output consistent resolves most of the other questions automatically.
Can we write the process and build the system in parallel?
In theory yes, in practice almost never. A team under delivery pressure fills ambiguity with assumptions rather than resolving it.
What size of business is this for?
Any size. The questions concern clarity, not scale.
Closing
Readiness for AI is not a technology question. It is whether you can describe what you do precisely enough that someone — or something — could repeat it.
If you want this run against one specific process, a strategic session is where that starts.
Comments (0)
You need to log in to post a comment.
Login / Sign up