You don't need an AI strategy, you need a list

If a board member, a partner or your own sense of falling behind has asked you for an AI strategy, the most useful thing you can produce is not a strategy. It’s a list: the work your organization does, which pieces repeat, which are slow, which go wrong, and which of those a machine could plausibly help with. That list is what a readiness assessment is for. The strategy, if you still want one, is the list plus an order. Most organizations skip the list and start with a model, and that is why so many first AI projects end up as a chatbot nobody opens twice.

This piece covers what an assessment checks, why the model-first route fails, how to build the list yourself in one afternoon, how to score it, and what to do with the top three rows.

What a readiness assessment actually checks

“Ready for AI” sounds like a property of the whole organization. It isn’t. It’s a property of a specific piece of work, and it comes down to five questions asked about that piece of work.

The work itself. Can it be described? Who does it, how often, in what steps, and what are the exceptions? If the people who do it can’t describe it in ten minutes, no system will learn it from a prompt. Predictable steps and judgment steps need to be told apart, because they get different treatment later.

The information. Where does the information the work needs actually live: a line-of-business system, SharePoint or Drive, a shared mailbox, a spreadsheet, or in people’s heads? Is it current? Who is allowed to see it? Does it contain personal information about customers, clients or staff? A candidate whose information sits in a mailbox nobody can search is not ready, whatever the tool.

The rules. Are you permitted to use this information this way? Which decisions inside the work have to stay with a person (hiring, credit, client advice, pricing, discipline)? Is there someone who will own the system after it’s built? Governance at this stage is three questions, not a committee.

The people. Who will use the result, who will look after it, and is there anyone on staff who can tell whether an output is right? A system that produces summaries only helps if someone competent reads them, at least at first.

The budget. Not the build cost alone. The licence, the monthly model bill, the hours a person spends checking output, and the cost of the system being wrong once in front of a customer. Some candidates are cheap to build and expensive to run; the assessment says which.

Notice what isn’t on the list: which model, which vendor, which platform. Those come last, once a piece of work has passed the five questions.

Why starting with the model fails

The model is the easiest part to get and the hardest to point at anything. Sign up, paste, get a good answer, and you have a demo. Demos pass. Then the same idea meets real documents, real permissions and real questions, and one of four things tends to happen.

The chatbot over the whole document library. It’s the project most people think of first. It fails on permissions (the intern can now ask about partner compensation), on stale documents (the 2019 policy answers as confidently as the 2026 one), and on scope (nobody agreed which questions it should answer, so it answers all of them, badly).

The licence for everyone. A seat for every employee, in the hope that uses appear. What appears is a renewal conversation and a handful of people drafting emails slightly faster.

Automating the judgment step first. The step that needs an experienced person is usually the interesting one, so it’s the one people try to hand to a model. It’s also the step with consequences. The predictable steps around it, the re-typing and the routing, are where the time was going anyway.

The vendor pitch you can’t evaluate. Without your own list, every demo looks relevant, because you have nothing to compare it with. With the list, you can ask the only question that matters: which row does this help with, and by how much?

None of these are technology failures. They’re the result of choosing a tool before choosing the work.

How to inventory the work in one afternoon

You don’t need a consultant for the first pass. You need three hours, four to six people who do the work (not only the people who manage it), and a spreadsheet.

Book the time and tell people the purpose plainly: we’re writing down what takes the time, so we can decide what to fix. Don’t say “AI” during the session. The word makes people describe what they imagine a machine could do instead of what they actually do.

Ask each person five questions and write the answers in their words:

What do you do every week that you’d hand off tomorrow if you could?
What takes longer than it should?
What do you re-type, re-enter or copy between systems?
Where do you wait on someone else, and for what?
What goes wrong most often, and what does it cost when it does?

Put each answer on its own row with these columns: the work item; who does it; how often; how long each time; what information it uses and where that lives; whether there’s a judgment call in it; what goes wrong. If a row is vague (“dealing with client emails”), split it until each row is one thing (“reading a change request and updating the order in the ERP”).

If the room goes quiet, prompt with the kinds of work AI tends to touch: finding answers across internal knowledge, searching or reviewing documents, extracting information from them, first drafts with human review, triaging incoming requests, supporting a customer-service team, moving information between systems, repetitive administration, and controlled multi-step workflows. Most people recognise a few of these from their own week.

Expect twenty to forty rows. That spreadsheet is the inventory, and it’s already more useful than a strategy document, because every row names a person, a frequency and a place where the information lives.

How to score the candidates

Add five columns and score each row 1, 2 or 3.

Volume. How often, times how long. A daily two-hour task scores 3; a quarterly one scores 1.

Variability. How predictable are the inputs and the steps? The same fields from the same form every time scores 1; a different PDF from a different sender every time scores 3.

Consequence of error. What happens if the output is wrong and nobody catches it? An internal draft scores 1; anything that reaches a client, a candidate or a regulator scores 3.

Data sensitivity. Public or harmless information scores 1; internal but not personal scores 2; personal, regulated or under a confidentiality duty scores 3.

Current pain. How much do the people doing it want it gone?

Then add a sixth column, the kind of fix, and fill it from the pattern of the scores rather than from preference:

High volume, low variability, low consequence: plain automation. A rule, an integration, a form. No AI needed, and it will be cheaper and more reliable without it.
High volume, high variability at the input (emails, PDFs, free text), predictable steps after: an AI-assisted step. The model reads the unstructured part; everything after it stays deterministic.
A genuine judgment call with real consequences: the person stays. AI may draft or suggest for them, which is still worth having.
High sensitivity: whatever the fix, it runs only on tools you’ve approved for that tier of information, or on de-identified copies.
Many steps, several systems, real decisions along the way: possibly an agent, and possibly not. Agents cost supervision. Ask whether the same work could be three simple automations with a person between them.

An illustration of how three rows might come out:

Work item	Volume	Variability	Consequence	Sensitivity	Fix
Re-typing order changes from email into the ERP and the carrier portal	3	2	2	2	Automation for the re-typing, an AI step for reading the email, a person on the terms decision
Finding the right precedent in the document system	3	2	1	3	Retrieval over one practice group’s documents, permissions mirrored from the source
Deciding whether a client gets extended credit	1	3	3	3	Stays with the finance lead. AI may summarise payment history

Sort by volume and pain, and mark the rows whose fix is “not AI”. They’re wins too, often the quickest ones.

What to do with the top three

Pick one pilot, not three. The second and third go on a roadmap in order, and the “not AI” rows go to whoever handles process improvement. Writing the whole list down, including what you decided not to build, is what turns the roadmap into a strategy.

For the pilot, before touching a tool, run a feasibility trial: take a month of real inputs (real emails, real documents, real questions) and spend an hour pushing them through the candidate approach by hand. What worked, what didn’t, what it would take. This is where a vendor demo gets replaced by evidence, and it costs an afternoon.

Then set five things down in writing. One measure, in plain units: minutes per change, hours per week, days to first reply. A fixed period, four to six weeks. A named owner. The smallest useful slice: one team, one customer, one document type. And a stop rule: the number at which you’d call it off.

Check the data and the rules before the build starts. Who may see the information the pilot uses, whether personal information is in it, and whether the tool you’ll use is approved for that tier. It’s a short check, and skipping it is how a pilot becomes an incident.

At the end of the period, look at the measure, not the impressions. If it moved, the roadmap tells you what’s next. If it didn’t, you’ve learned something for the price of one slice, and the second row on the list is waiting.

Where to go from here

If you’d like the inventory, the scoring and the pilot recommendation done with you, that’s what our AI Readiness & Opportunity engagement is. If you’d rather find your starting point first, take the free AI check: fourteen questions, five minutes, no email needed.