“AI readiness assessment” has become a category, which means it has also become a way to sell a deck. Here is what we actually do in one, and what you should expect from anyone else offering it.
The assessment exists to answer one question: should you build this, and if so, what exactly? A good one frequently concludes that you should not, or not yet, or not this. If a firm’s assessments always recommend a build, they are not assessments.
Question one: what is the workflow, really?
Not the workflow on the process map. The one people actually perform, including the spreadsheet someone maintains privately and the step everybody skips.
This matters more than any technical question because AI applied to a documented process that nobody follows produces a system nobody uses. We spend the first days of an assessment talking to the people who do the work, not the people who own it. Two or three conversations is usually enough to find the gap.
The output is a short list of candidate points where AI would remove genuine friction, ranked by how much time or money each is worth.
Question two: does your data support it?
This is where most enthusiastic projects die, and it is better to find out in week one than in month five.
Concretely we look at: whether the content exists in a form a machine can retrieve; whether it is current, or whether half of it describes a process from three years ago; whether it is consistent enough that two documents do not confidently contradict each other; and whether there is any labelled example of a correct outcome to evaluate against.
That last one is the quiet killer. Without examples of right answers you cannot measure quality, and without measurement you are shipping on vibes and finding out from customers.
Question three: what does “correct” mean here?
Every AI system needs a definition of a good answer that is specific enough to test.
For a support assistant it might be: cites the right policy document, does not invent a refund window, escalates anything about an account balance. For a document extraction system it might be per-field accuracy with a defined tolerance.
Writing this down is often the most valuable hour of the whole engagement, because it forces the disagreement that would otherwise surface after launch. It also becomes the evaluation set.
Question four: what happens when it is wrong?
Not if. When.
The consequence of a wrong answer determines the entire architecture. If a wrong answer is mildly annoying, you can ship a fast, cheap system and iterate. If a wrong answer has a clinical, financial or legal consequence, you need confidence thresholds, human review paths, audit trails and hard boundaries the model cannot cross — and the cost profile is completely different.
Teams routinely design for the happy path and bolt the failure path on later. It never fits.
Question five: what will it cost to run?
Not to build. To run, per month, at the volume you actually expect in a year.
This means estimating tokens per interaction, interactions per user, users per month, and the cost of the model tier the quality bar requires. It means checking whether latency requirements force you onto more expensive infrastructure. And it means being honest that a system with a per-request marginal cost behaves differently on a P&L than software with a fixed hosting bill.
We produce a cost and latency envelope: a range, with the assumptions visible, so you can see which assumption to challenge.
Question six: build, buy or integrate?
The cheapest correct answer is often that a product already exists.
We have no incentive to hide that, and we say so when it is true. Where the answer is genuinely to build, this question still shapes the scope — much of what looks like a build is integration, and recognising that early usually shrinks the estimate.
What you get at the end
Four things, and deliberately not a large deck:
- A ranked list of candidate use cases with expected value and confidence
- A clear read on whether your data supports the strongest one
- A proposed architecture for it, with a cost and latency envelope
- A recommendation, including “not yet” where that is the truth
Two to four weeks. Access to the system or the data, and a few conversations with the people who run the process. That is all we need.
Why we write these knowing we might have to deliver them
The consulting market is full of assessments written by people who will not be there when the recommendation meets reality. The deck is confident, the roadmap is tidy, and nobody tested the estimates against a real codebase.
We write assessments knowing we might have to build the thing. That changes what goes into one. It makes the estimates more conservative, the risks more specific, and the “do not build this” conclusion much more likely to appear when it is the right call.
It is a worse business model and a better product.