An AI readiness assessment framework you can run in a week

Somebody on the leadership team asks whether the company is ready for AI. Three vendors have pitched in the last month, each with a different answer, and nobody can compare them. The answer is another question: ready for what?

Readiness belongs to a process. A business can be fully ready to automate supplier invoice matching and nowhere near ready to let a model answer customer emails. That difference is why an AI readiness assessment is worth doing at all, and why the usual maturity score for the whole company tells you less than it seems to.

You can run this AI readiness assessment framework yourself with a spreadsheet and about a week of your time, spread across the people who know the processes. It starts from the three checks we run in client assessments (is the data usable, can the systems be reached, can the team run the result) and adds two more: can someone describe the process in order, and what does a mistake cost.

Why one score for the whole company is the wrong unit

A maturity score from one to five is fine if you want to compare your organization with a benchmark or track progress year over year. It won't help you decide what to build next Tuesday.

Decisions that cost money get made one process at a time. Should finance put an agent on invoice matching? Should support let a model draft replies? Each has its own data and its own systems, and a mistake costs something different in each. A company can score a respectable three out of five across the whole business while one process has clean data and a patient owner and another has a shared drive that nobody trusts.

So list ten processes, run the five questions on each, and compare the results.

The five questions to ask about each process

Run these on one process at a time and write the answers down. A week from now you will not remember what the finance lead said about month end.

Question 1: can someone describe the process in order?

Sit with the person who does the work and ask them to walk you through the last three cases they handled. The textbook version of a process is always tidier than the real one. If they can give you the order of steps and name the one where it goes wrong, you have something to automate. If the answer is "it depends" every time, the process hasn't settled, and an AI system will inherit the confusion.

Listen for workarounds: the spreadsheet on one person's desktop, the email that has to go out from a particular account. Little of that appears in documentation, and any automation will have to deal with it.

Question 2: is the data usable?

Usable has four parts: the data exists, you're allowed to use it, it covers the cases you care about, and it's consistent enough to trust. Pull fifty real cases and read them (fifty is enough to see the patterns and few enough to read in an afternoon). Look for missing fields, free text where a code should be, two spellings of the same supplier, and the case where three people disagree about what "closed" means.

If you find a lot of that, clean the data first. Anything you build on top will carry the mess forward.

Question 3: can the systems be reached?

An agent that can't read from or write to the systems where the work lives is an expensive chat window. Look for an API, a database connection, a scheduled export or, at the very least, a mailbox the agent can be given access to. Then find out who can grant that access and how long the request takes.

Getting security to approve a service account can take longer than building the prototype, so ask early.

Question 4: what does a mistake cost, and who catches it?

Every automated process makes errors, so the useful question is what an error does. A wrongly tagged support ticket costs a minute. A wrongly approved payment costs the payment. A wrongly rejected applicant costs a hire you never learn you missed. Write down what a wrong output would cost and who would notice it, and add a rough guess at how often it will happen.

If the cost is high and nobody would notice, you need a human approval step before anything else. A rule fails the same way every time. A model can be wrong differently on each run and still sound sure, so put a person in front of anything costly.

Question 5: who runs it after launch?

A system that works in week four still needs an owner in month six. Someone has to read the exceptions, spot when the inputs change, and decide whether a new edge case needs a new rule, a better prompt or more training data. If you can't name that person and give them time for it, wait.

Running the owner interviews

The interview is where most of the information comes from, so it's worth a little structure. Book an hour with the person who does the work, not their manager, and ask for three recent cases they can open on screen. Then go through each case in order and ask the same short list of things.

What came in, and from where? What did you do first? Where did you have to look something up, and where? What did you check twice because you didn't trust it? What would have made this case go wrong, and how often does that happen? Who else touched it, and what did they change? And last: if a machine did the first half of this, which part would you want to see before it went on?

That last question tends to produce the most honest answer about question 4, because people know exactly which parts of their job they'd never hand over unsupervised. Write the answers on a single page per process, in their words, and keep the three cases. When you score later, the page is your evidence.

Scoring it without pretending to be precise

Give each question a 0, 1 or 2: zero if it isn't in place, one if it's partly there, two if it's ready. Add them up and you have a score out of ten for that process. Two other things carry more information than the total.

A zero on question 3 or question 5 is a blocker whatever the total says; no access to the systems and no owner both end projects. And the pattern of scores tells you what to do next, which a single number can't.

The scores below are invented, for three processes in a mid sized business. On question 4, a high score means mistakes are cheap or reliably caught.

The best total isn't always the most exciting process, and the lowest scoring one can be the one an executive was keenest on. With the numbers on paper, that conversation gets easier to have.

A worked example: how invoice matching earned its eight

It helps to see the reasoning behind one row. (The company is invented, but the pattern is common.)

Described scored two. The accounts payable lead can walk through the last three invoices without hesitating: receive, key into the finance system, match to the purchase order, route for approval, pay. They can also name the step where things go wrong, which is invoices that arrive without a purchase order number.

Data scored two. Fifty recent invoices turn out to be mostly PDFs from about thirty suppliers, and the purchase order data is clean. A handful have totals that differ by a few cents because of rounding, and the team already has a rule for that.

Systems scored one. The finance system has an API, but the supplier portal that feeds it exports a nightly file, and the security team hasn't yet approved a service account. That earns a one at best, and it is one of two reasons the row stops at eight.

Cost of error also scored one. Paying the wrong amount is recoverable but annoying, and large invoices would get an approval step anyway. Nobody would notice a small mismatch for a month.

Owner came out at two. The accounts payable lead wants this and has two hours a week to give it.

Each of those judgments came from an hour with the person who does the job and a look at fifty invoices, plus a call to IT.

What a low score tells you to do

A low score on question 1 means you map the process before anything else. Following one real case from start to close and writing down every handoff is the first step of business process automation, and it can turn up waste before any AI is involved.

Low on question 2: clean the data, or choose an approach that tolerates messy documents. A retrieval system can sit on top of imperfect content, but it will return whatever is wrong in that content, so someone still has to own the source material.

Low on question 3: integration work comes first, and it is rarely glamorous. If two systems can't talk to each other, an agent has nothing to read or write, and AI workflow automation is what connects them.

A poor score on question 4 sends you to design work: which decisions the agent may make alone, which need approval, and which are blocked. It's cheaper to settle that on paper (our agentic workflow design page shows how we do it) than after something has gone wrong.

If question 5 scores zero, don't start. Find the owner.

What changes for generative AI

If the process involves a language model writing or reading text, add three questions about content, evaluation and error rate. Is the source content any good, given that a model will quote what it finds? Do you have a way to judge an answer, such as fifty to a hundred real questions with known good answers, before you build anything? And how many wrong answers can the process live with?

A support team might accept one wrong draft in twenty if every draft is reviewed by a person. A compliance team might accept none. Decide the number before you see results, because once results exist everyone's tolerance drifts toward whatever the system achieved.

Different kinds of AI ask different things

The five questions stay the same, but where the typical zero shows up depends on what you're planning.

A retrieval system depends almost entirely on its source content. For a RAG system the data question becomes whether the documents are current, owned and free of three conflicting versions, and the systems question narrows to whether document permissions can be read and respected.

An agent that acts inside your systems leans hardest on questions 3 and 4: can it reach the tools, and what happens when it's wrong? Here the written boundaries decide how much damage a wrong action can do.

A vision project asks something different again. The data is footage, and the usual blocker is whether the cameras you already have can see what the model needs, in terms of angle, light and resolution. Computer vision solutions start from a footage review for that reason.

A fine tuning project adds a stricter precondition: a set of consistent examples of the task done well. Without them, the readiness answer for LLM fine tuning is "not yet", and prompting or retrieval is the better first step.

Mistakes that make the scores useless

Four habits ruin the exercise.

Scoring alone, at a desk. A score written without an interview reflects what the documentation says about the process, and the documentation is rarely right.

Giving credit for intentions. "We're planning to clean that up" is a zero today. Score what exists, and put the plan in the notes.

Letting the favorite win before it's scored. If a sponsor has already picked a process, score it first and score it honestly. A low score still helps, because it's cheaper to learn that on a spreadsheet than in month three of a build.

Comparing totals without reading them. An eight with a zero on question 5 is worse than a six with no zeros, because the zero stops the project and the total hides it.

Doing it yourself or bringing someone in

You can run all of this internally. The cost is mostly time: ten owner interviews, an afternoon of comparing scores, and the sample of cases each owner pulls for you. Online questionnaires will give you a score in ten minutes, but they can't read your processes, so they can't tell you which one to start with.

Approaches differ in how consultants assess AI readiness in businesses, but the useful ones start from a sample of real cases and the people who handle them. An outside assessment earns its fee when your team lacks the time, or when you want a ranking that nobody inside has a stake in. Many AI readiness assessments end in a single score that can't say what to build first, so the ranked list is worth more. When you compare AI readiness assessment services, ask for four things in writing: a list of what to leave alone, a sequence with costs, a readiness check on your data and systems, and a roadmap that any capable team could build from. Ours is an AI readiness assessment that produces an opportunity map, a ranked shortlist, a readiness check on data, systems and governance, a sequencing plan and a phased roadmap that stays yours whoever builds it.

What to do with the result

Take the top of the ranking and turn it into a pilot with an end date. Write the baseline before anything is built (hours per case, elapsed time, error rate), pick a stop condition (if mistakes exceed what you decided in question 4, you pause), and decide who reviews the outputs and how often.

Keep the rest of the ranking too. The processes that scored low haven't been rejected; they're waiting on something specific, such as data, access or an owner. Put each one on a list with the missing piece next to it, and score them again in a quarter. A blocker like an API approval or a messy knowledge base often gets fixed as a side effect of the first project, and a process that scored a four last quarter can score a seven now.

A one week plan

Over the week: list ten candidate processes and name an owner for each; interview the owners (an hour each) and walk through their last three cases; pull fifty real cases for the processes that survive and read them; score; then rank them and write a paragraph on each saying why it landed where it did.

Then pick the best scoring process with a low cost of error and run it as a pilot for four weeks, with a person approving every output. If you'd like a second pair of eyes on the ranking, get in touch and bring the spreadsheet.