What AI Strategy Consulting Is Supposed to Produce
Search this and you get a category explained back to you. Roadmaps, readiness, use case identification, governance, change management, alignment with business objectives. Every page lists those, several of them in the same order, and the firms writing them are large enough that you will not out-rank them by writing the list again.
What none of the pages says is what you are holding at the end. A strategy engagement is not a workshop and it is not a document, or rather it produces both and neither is the point. What you are buying is a small number of decisions that were ambiguous before and are settled after, written down in a form that survives the person who wrote it leaving.
That is a short list. It is worth knowing what is on it before you pay anyone, because you can reach a usable version of most of it in an afternoon, and the gap between your version and theirs is the actual thing you would be buying.
The decisions, and they are the whole deliverable
There are about six, and they are the same six whether the engagement is a two-week assessment or a six-month programme.
Which problem goes first. Not which problems exist, which one is first. Every organisation that has looked at this has a list of candidates, and the list is rarely the difficulty. Picking one and setting the others down is, because picking one is a statement about what will not happen this year and that is a political act rather than an analytical one.
Whether the data for it is reachable. This is the question that sinks the most projects and it is asked last almost everywhere. Reachable means a named system, a way to query it, and someone who can authorise that. Data that exists somewhere in principle is not reachable, and a plan built on it is a plan with a hole in the middle.
Who owns it after launch. The thing you build will drift. Sources change, permissions change, a provider deprecates a model and the behaviour you tuned against moves. If no named person has that in their objectives, the answer is that nobody owns it, and a year later nobody will be surprised that it stopped working.
What counts as working. Agreed in advance, in a number or a behaviour somebody can check, and agreed by the person who will judge it rather than by the people building it. Most pilots are declared neither successful nor failed, which is a worse outcome than failing, because a failure at least ends.
Build, buy or neither. Including the neither, which no vendor will raise. A surprising share of what gets scoped as a project is better served by a feature in software you already pay for, and the second most common honest answer is to wait, because the thing you want is six months from being a commodity.
What you will not do. Explicit, written, and the part that gets dropped first. Without it the scope grows back to the original list and the sequencing you paid for is gone.
If a proposal does not resolve those six, you are buying a document. If it resolves them, the document is just where they are recorded.
You can run most of this yourself
We publish a free AI readiness assessment that asks six questions, and the questions are not arbitrary. Each one is a known predictor of a deployment that does not survive its first year, which is why they are the questions and not a longer, friendlier set.
It asks how accessible and clean your data is, whether you have identified specific use cases, what in-house skills you have, how mature your cloud and data infrastructure is, whether anything is in production already, and whether there is budget with executive sponsorship behind it. Then it puts you in one of three places: exploring, building or scaling.
Those map almost exactly onto the decision list above, which is the point of mentioning it here. Data accessibility is the reachability question. Identified use cases is the sequencing question. Skills and infrastructure decide build against buy. Production experience changes what a realistic next step looks like. Sponsorship is the ownership question wearing a budget hat, because an owner without authority is a volunteer.
Run it honestly and you will have a usable first draft of the six. That is not a sales funnel observation, it is the reason to run it before talking to anyone: a conversation you enter with a draft is a different conversation from one you enter with a blank page, and it is far harder to sell you the wrong size of engagement.
What a paid engagement actually adds
Three things, and being able to name them is how you tell whether you need one.
The first is adjudication. The sequencing decision is contested inside most organisations, and someone outside it can say the uncomfortable thing and leave. That is a real service and it is not a technical one. It is also the reason an internal person frequently cannot produce this deliverable however capable they are.
The second is the reachability check done properly. Your own answer to the data question is a belief about your systems. Someone who goes and looks returns with a different answer often enough that the checking is worth money on its own, and it is the single most common place where a confident plan turns out to be built on nothing.
The third is calibration against work that has already failed. Whether a thing is six weeks or six months, whether this provider or that one, whether the evaluation approach you have in mind will catch the failures you will actually get. That is pattern recognition from having done it before, it cannot be read off a page, and it is most of what you are paying for.
What it does not add is enthusiasm, and a proposal whose main content is enthusiasm about the category is a proposal to avoid. The same goes for one that resolves the sequencing question in the direction of the largest possible programme, which is the structural bias of the whole category and worth watching for explicitly.
How to tell which engagement you need
If you came out of the assessment at exploring, the honest scope is small: a few weeks, one decision, a written recommendation, and a deliverable you could act on without hiring the same people again. That is the shape described in our piece on what a small business AI consultant actually does, and the trap at this stage is being sold a transformation programme on the strength of ambition rather than readiness.
If you came out at building, you have the opposite problem. The strategy question is largely settled and what remains is delivery, which is a different purchase with different people, and paying for more strategy at that point buys you a restatement of what you already decided. Our piece on what AI automation services leave off the invoice covers the parts that get omitted from delivery quotes.
If you came out at scaling, strategy work is genuinely useful again, for a third reason: cost, governance and the question of which proven patterns go wider. That is closer to ordinary operational consulting than to anything AI-specific, and it should be priced like it.
And the case for buying nothing: you already know which problem is first, the data for it is reachable, somebody owns it, and you have a definition of working that the person judging it agrees with. Build the smallest version and find out what it does under real use. A month of real traffic settles questions that no amount of strategy work can, and it is considerably cheaper than the engagement you were considering.
Five questions for the first call
These work on any firm and none of them is a trick. They are the questions the firm's own engineers ask each other internally.
Ask what the deliverable is, as an object. If the answer is a roadmap, ask what a roadmap contains that you could act on next week without them.
Ask how they will check that your data is reachable, and who inside your organisation they need for it. Vagueness here is the most reliable warning sign available, because it is the part of the work that cannot be done from a slide.
Ask who they expect to own the thing afterwards, and what happens if that person does not exist. A firm that has not thought about this is scoping a build and calling it a strategy.
Ask what they would tell you not to do. A partner who cannot produce an answer is not going to help with the only part of the sequencing decision that has teeth.
Ask what circumstances would make them recommend buying software instead, or waiting. The answer to that one tells you more about whether to work with them than anything on their site does.