What a client walks away with after an AI readiness assessment | SUMāTO
An AI readiness assessment delivers four concrete things: a maturity index backed by evidence, a measured cost baseline for the process —what it costs to run today—, a written specification of what should be built, and an enablement roadmap with owners and dates. The organisation keeps all four deliverables even when the conclusion is that it is not yet the moment to proceed.
What follows: what each level of the exercise produces, what every role at the table gains, and what stays in the building when the answer is "not yet".
What is an organisation actually buying when it commissions an assessment?
Rarely is it a report. What it is looking for is a way out of being stuck.
Stuck usually looks like this: there is pressure from the board, there is a budget that appears and disappears, there are three departments proposing different use cases, there is a pilot from last year that nobody dares declare dead, and there is an uncomfortable sense that the competition is moving faster. Nobody knows where to start, and nobody wants to be the person who proposed the project that failed.
The trouble is that most assessments do not solve that. They produce a document with a score, a colour-coded radar and a list of generic recommendations —"strengthen data governance", "build analytical capability"— that nobody can turn into a decision the following Monday.
Our criterion is different, and it is simple to state: an assessment is worth what it changes. If it ends without a decision made, a number that did not exist before, and a next action with an owner and a date, the exercise was expensive regardless of what it cost.
This article describes exactly what a client walks away with. No generalities.
What does each level of the assessment deliver?
SUMāTO AI Ready operates at three levels of depth. Each is a complete exercise with its own deliverables, and each closes one concrete decision. Working through all three is not required: many organisations resolve what they needed at the first.
Level 1 · AI Ready Pulse
One session. 45 to 60 minutes. A one-page output.
It is a structured conversation of eighteen questions, facilitated by a consultant, across the six pillars of the model. It is run as a session rather than a form because unassisted self-assessment systematically overstates maturity, and an inflated diagnosis serves nobody.
| Deliverable | Contents |
|---|---|
| Readiness index | A number from 0 to 100 and a named archetype. It places the organisation in language the board understands without translation. |
| Six-pillar radar | A score per pillar. It shows the real variation rather than the average that hides it. |
| The weak link, identified | The pillar that is blocking progress today, named explicitly. |
| Three findings | Each supported by evidence from the session: verifiable observations, not general opinion. |
| Recognised strengths | Two or three real capabilities that can be built on. |
| One recommended next step | One. Not a menu of options. |
Beyond the document, the Pulse leaves three things behind:
- A shared vocabulary. After the session, technology, operations and finance discuss the same problem in the same words. It sounds minor and it is not: much of the paralysis comes from each area describing the situation in its own terms.
- A conversation that had not happened. The Pulse puts the sponsor, the process owner and the data lead in one room. In many organisations that conversation had never taken place in a structured way.
- A defensible starting point. When the board asks "where are we?", there is an answer with a method behind it.
The decision it closes: is it worth going deeper on this process, or is another one the better candidate?
Level 2 · AI Ready Assessment
Two or three sessions. One to two weeks. Four formal deliverables.
Here the exercise becomes exhaustive: forty-eight scored items across twelve dimensions, plus full capture of the requirement. Security, architecture and the people who run the process take part.
| Deliverable | Contents | What it is for |
|---|---|---|
| Maturity report | Index, twelve-dimension radar, findings with evidence, prioritised gaps | Supporting the conversation with the board |
| Requirement specification | What the system must do, what falls outside scope, inputs, outputs, minimum accuracy, latency, integrations, data and security constraints | Getting quotes from any vendor on a common, comparable basis |
| Value case | Measured baseline, quantified target, return logic, assumptions stated explicitly | Requesting budget with an argument rather than enthusiasm |
| Enablement roadmap | Actions per pillar, sequence, owner, horizon | Starting to make progress the following Monday, even without contracting the implementation |
The requirement specification is written to be comparable: it describes the system in terms any vendor can quote against on the same basis. That is deliberate. A client negotiating from their own specification buys better than one negotiating from the proposal they were handed, and competing on that ground suits us.
The decision it closes: is there an approved ambition, with an owner, a budget and a stated position on risk and data?
Level 3 · AI Ready Blueprint
A three to five day workshop, plus two weeks of preparation.
This is the level for organisations with several candidate processes that need to decide a portfolio rather than a single case.
| Deliverable | Contents |
|---|---|
| Prioritised portfolio | Every candidate case placed on a value-versus-feasibility matrix, with a recommended sequence |
| Target architecture | Reference design: deployment, integration, data, identity, network isolation, service levels |
| Consolidated business case | The economic logic of the whole portfolio, not of one isolated case |
| Phased plan with gates | A sequence of work with approval and cancellation criteria at every control point |
| Proposed governance framework | Usage policy, classification of cases by risk level, decision forum, traceability |
One sequencing rule comes out of the portfolio: the first delivery always comes from the high-value, high-feasibility quadrant —the quick wins— even when the organisation insists on starting with the strategic bet.
This is not conservatism. It is that the credibility earned in the first wave is what funds the second. An organisation that delivers a visible result in one quarter secures budget for the ambitious work. One that spends two quarters on the big bet without a result loses its sponsorship before it arrives. It is the same sequencing logic we apply in strategic consulting.
The decision it closes: what gets built first, on what architecture, and under what governance?
Why is the cost baseline the deliverable that carries the most weight?
It is the one that causes the most discomfort in the session and the one that leaves the most value.
The question is simple: what does it cost to run this process today? How many cases per month, how many people assigned, how much time per case, what rework rate, what an error costs. In a high proportion of organisations, nobody has those figures.
Without that number there is no way to demonstrate return. It is why so many initiatives die at the first budget review: they did not fail technically, they simply could never prove that they worked.
The market data points the same way. McKinsey, in The state of AI: how organizations are rewiring to capture value (March 2025), found that fewer than one in five organisations track defined KPIs for their generative AI solutions — and that of all the practices measured, that tracking is the one most strongly correlated with bottom-line impact.
When the Assessment finishes, that number exists, it has been validated by finance, and it is signed off. It is an asset that serves this project and every project after it — even if the AI project is never built. Where the process under consideration is an analytical one, that same groundwork feeds into data analytics work.
What changes in the organisation after the exercise?
The deliverables are what gets handed over. These are the changes they produce.
Clarity: you know where you stand
Before the exercise, the answer to "how ready are we?" is an opinion, and it tends to vary with who is answering. Afterwards, it is a number with a method behind it, broken down by pillar, with the evidence that supports it.
That enables something that was not possible before: arguing about the data instead of about impressions. When technology says the data is ready and the business says it is not, the radar settles it in thirty seconds.
Focus: you know where to start
The assessment produces one identified weak link and a single recommendation, rather than a list of twenty improvements.
It is the difference between "we need to strengthen data governance, build capability and improve infrastructure" —which nobody can execute— and "the process you chose has no owner with authority to change it; resolve that before spending anything on technology".
Evidence: you can ask for budget
The baseline and the value case turn an investment request into an argument. The board stops hearing "we need to invest in artificial intelligence" and starts hearing "this process costs us this much a year, this intervention reduces it by this proportion, the result is measured with this indicator, and this person signs for it".
It is an entirely different conversation, and it is the one that gets approved.
Protection: you avoid the wrong project
This is the least visible benefit and probably the one with the greatest economic value.
The public data is consistent on one point: most initiatives never demonstrate financial impact. The GenAI Divide: State of AI in Business 2025, from MIT's Project NANDA (July 2025, covering more than 300 publicly disclosed initiatives, 52 interviews and 153 executive survey responses), concluded that roughly 95% of generative AI pilots produced no measurable P&L impact. And RAND, in The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed (2024, based on 65 interviews with data scientists), found that the dominant causes of failure are organisational —a badly framed problem, insufficient data, no owner with authority— rather than technical.
That is precisely the ground an assessment covers. An exercise that concludes "not yet" and avoids that spend is worth more than one that gives everything a green light. This is why the method includes an explicit rule: any pillar at the lowest level triggers a mandatory remediation condition, however high the overall average.
Speed: the path shortens when you do proceed
The counterpart to the previous point. When the assessment gives a green light, the organisation starts with the specification written, the baseline measured, the architecture defined and the governance drafted.
What is normally three months of discovery at the start of a project is already done — and done in writing, not in the heads of three people.
Autonomy: the capability stays in the building
Deliverables are produced in editable formats and the method is explained during the exercise: what was asked, why, and how it was scored.
By the end, the organisation can repeat the assessment on another process on its own. Many clients do, and that suits us: a client who understands the method buys better and argues better.
What does each role at the table gain?
An assessment that only serves the technology department does not win budget. These are the real interests of each seat.
| Role | Their real question | What they walk away with |
|---|---|---|
| Chief executive | Are we falling behind, and what does it cost to find out? | A position with a method behind it and a single recommendation. They stop deciding from headlines. |
| Chief technology officer | What am I going to be asked to support when this reaches production? | Platform, integration and operating requirements made explicit at the start, not discovered mid-project. |
| Chief operating officer | Will my team adopt this? | The process documented, the friction points identified and the adoption risk assessed before committing. |
| Chief financial officer | How do I know this returns anything? | A validated baseline, a quantified success criterion and a written cancellation criterion, all before approval. |
| Chief data officer | Will my data support what is being proposed? | An honest evaluation of quality, accessibility and the legal basis for use — with the gaps named. |
| Legal and compliance | What is our exposure? | The case classified by risk level, regulatory requirements mapped and a control framework proposed. |
| The team that runs the process | What happens to my job? | A part in the assessment, and an explicit answer about where the freed-up capacity goes. |
That last row deserves a note. We include the people who run the process for a practical reason: their reading of it is usually more accurate than their manager's, and their disposition towards the change predicts the outcome better than any technical variable. It is consistent with what RAND found: what decides the fate of an AI project is organisational before it is technological.
What does the organisation keep if it decides not to proceed?
This section matters more than the ones before it.
An organisation that runs the exercise and decides not to move forward is left with documentation it did not have:
- The process documented and mapped, which it probably was not.
- The cost baseline for the process, which probably did not exist.
- The inventory of data sources, with quality and legal basis assessed.
- The legal and contractual constraints on using that data, mapped.
- The requirement specification, written to be comparable across vendors.
- The method, explained during the exercise.
None of that is specific to SUMāTO. It serves just as well if the organisation decides to build internally, hire someone else, or wait two years.
We work this way out of conviction and out of calculation. Out of conviction, because an assessment conditioned on the sale stops being an assessment. Out of calculation, because an honest exercise that concludes "not yet" is the longest-lived commercial asset we can leave in an account: when that organisation is ready —in six months or in two years— it knows who to call.
What is the scope of the exercise?
Being precise about the limits is part of the offer.
It is a decision-making exercise. The work is on the process, the data and the business case; no technology is demonstrated in the sessions. A reader looking to see a tool running wants a different kind of meeting.
It evaluates the governance posture and maps the applicable regulatory requirements. It is an input to the compliance conversation, not an audit opinion or a certification of conformity with any standard.
It defines what should be built, with what success criterion and what cancellation criterion. Building is the phase after.
It builds the baseline and the economic logic with stated assumptions. The assumptions are stated precisely because they are assumptions: the exercise produces an auditable return hypothesis, not a guarantee.
The conclusion may be "not yet". A share of these exercises conclude that the chosen process is not suitable, or that another one is the better candidate. That conclusion is delivered in the same detail as any other.
How does it start?
The first step is a 45 to 60 minute session.
Three people are needed in the room: the sponsor of the initiative, the owner of the process being considered, and the data lead. If the process owner cannot attend, we would rather reschedule — without that role the exercise loses its validity.
Within the following 48 hours the one-page brief is delivered, with the index, the archetype, the radar, the three findings and the recommendation.
And if the conclusion is that the process is not ready, we will tell you so. That is, in the end, the only reason it is worth running an assessment at all.
Next step: request your AI readiness assessment, or see how it fits into our enterprise artificial intelligence work.
Frequently asked questions
How long does an AI readiness assessment take?
It depends on the depth. The entry level is a single 45 to 60 minute session with a deliverable within 48 hours. The full assessment takes one to two weeks across two or three sessions. The portfolio exercise requires a three to five day workshop plus two weeks of preparation.
What deliverables does the client receive?
At the entry level, a one-page brief with the readiness index, the archetype, a six-pillar radar, three findings and a single recommendation. The full assessment adds four documents: a maturity report, a requirement specification, a value case with a measured baseline, and an enablement roadmap.
What is a cost baseline and why does it matter?
It is the measurement of what the process costs and how it performs before any intervention: cases per month, people assigned, time per case, rework rate, cost of an error. Without that number there is no way to demonstrate return afterwards. It is why so many initiatives die at the first budget review.
What happens if the assessment concludes we are not ready?
It is delivered all the same, in the same detail, including the enablement roadmap that says what to resolve first. A share of these exercises conclude that the chosen process is not suitable or that another one is the better candidate.
Who needs to take part in the sessions?
Three roles at minimum: the sponsor of the initiative, the owner of the process being considered, and the data lead. The full assessment adds security, architecture and the people who run the process day to day.
Is it useful if our earlier AI pilots did not work?
Especially then. A history of abandoned pilots is one of the most diagnostically valuable findings, because it indicates the root cause is organisational rather than technological — and that cause is still present until it is resolved.
Read also: the benchmark of AI adoption frameworks from the major consultancies and technology vendors, and what is missing to apply them in a mid-sized company.