Four of the twenty questions a client sent us could not be answered by anyone. Not because the join, matching records in one system to records in another, was hard, but because nobody in the business had ever recorded the answer, not in the CRM, not in the ad platform, not in the invoicing system. This is a checklist that finds that out in about ten minutes, using nothing but the systems you already have open, before you pay anyone anything.
What does an AI readiness assessment actually measure?
“AI readiness” gets used like it’s a question about which model you pick, or which subscription tier you’re on, or how modern your tech stack looks from the outside. It isn’t any of those. It’s a narrower and far more answerable question: for something specific you want to know, does the raw material for an answer exist anywhere in your systems, and can it be reached without someone manually joining two spreadsheets by hand every time you ask?
That’s the whole definition. Not “is your business ready for AI” in some general sense. Not “do you have enough data.” Just: for the question you actually have, does the material exist, and is it in a shape something other than a person can reach?
If every question you’d want to ask already lives inside one tool, and the tool ships its own plain-English access through an MCP server (a connector that lets an assistant read the tool’s data), several of the tools we mapped in MCP servers for business tools: what AI can actually reach already ship one, quite possibly on the plan you are already on. If that describes you, the first two checks below will confirm it. Read them, then keep going anyway: the last three checks fail inside one tool just as easily.
The most expensive answer is not the one that is hard to build. It is the one that needs six months of somebody typing before it exists.
What are the five checks you can run in the next ten minutes?
Run these against your own systems, in order. Each one takes a couple of minutes if you already have the tools open.
-
Single-system check. Does every question you’d want to ask live inside one tool? A pass looks like this: the ad spend, the completed job, and the invoice all sit in the same system, and that system’s own plain-English access already reaches all three. If that’s genuinely true, stop reading here, use the vendor’s connector, and treat a paid build for that one question as money spent on nothing. A fail looks different in a specific way: you already know, without checking anything else, that answering the question means opening a second tab. Marketing spend lives in an ad platform, the job that spend produced lives somewhere else, and no vendor connector crosses that boundary, because it was never built to look outside its own tool. Fail this one and the next check tells you exactly what kind of failure you’re dealing with.
-
Join check. Does answering the question require combining two systems that were never introduced to each other? A pass here doesn’t mean the systems talk automatically. It means somebody already built the join, however manually, and the number that comes out the other end is trustworthy. Ad spend and completed jobs is the pairing that shows up constantly, and a CRM sitting next to an invoicing system that has never been reconciled is the other common one. A fail looks like this: getting the answer means pulling numbers from two places and adding a human step to line them up every single time somebody asks, which means the answer is only as fresh as whoever last did that by hand. If you fail here, the fix isn’t a smarter assistant, it’s building the join once, as real infrastructure, so the assistant has something to query afterward. That’s a different kind of work than turning on a connector, and it’s the real difference between check one and check two: check one is free, check two usually isn’t.
-
Capture check. Is the field that would actually answer this question being filled in today, by anyone? Pull ten recent records and look. Don’t assume. A pass means the field is populated on most or all of those ten, even if the formatting is inconsistent. A fail means it’s blank across the board, and a blank field is a specific, disqualifying kind of fail: it means the business has never captured this information, not that the information is merely hard to reach. That distinction matters, because the fix is completely different depending on which one you find. A formatting problem is something a process or a script can clean up after the fact. A field nobody has ever filled in requires someone to start entering it going forward, and nothing retroactive, no AI, no query, no report, can produce data that was never recorded in the first place. Fail this check and the honest next step is a process change on your side, not a purchase.
-
Definition check. If you asked two people in the business to define the metric you care about (revenue, a completed job, a qualified lead), would they give you the same definition? A pass sounds almost too simple: you ask two people separately, without letting them compare notes first, and they land on the same answer. A fail sounds almost harmless in the moment, two people giving two different definitions with total confidence in each, and it’s actually one of the more expensive failures on this list, because it doesn’t announce itself. Nothing breaks. No error appears. Two dashboards just quietly disagree, and both people trust their own number because nobody ever told them a second definition exists in the building. Fail this check and the fix is a conversation before it’s anything technical: someone with the authority to pick a definition has to pick one, write it down, and make sure both systems, and both people, are working from that same line.
-
Coverage check. Of the total volume that could produce this answer, all calls, all leads, all jobs, roughly what share can currently be traced end to end? Estimate it: you don’t need precision here. A pass doesn’t mean 100 percent. It means the traceable share is high enough, and known well enough, that a number built on it can be handed around without a caveat attached. A fail looks like a number that sounds complete but isn’t: someone asks how many leads converted last month, gets a confident answer, and has no idea that answer only reflects the fraction of leads the system happened to trace. If it’s under half, treat any number built on top of it as partial. Don’t hand it around as complete, and don’t let it get repeated in three meetings until everyone’s forgotten it was ever partial to begin with.
The five checks at a glance:
| Check | What a pass looks like | What a fail means for cost |
|---|---|---|
| Single-system | One tool already answers it | No added cost when it’s true |
| Join | The join already exists and is trusted | Someone has to build the join once, as real work |
| Capture | The field is populated on most records pulled | The business has to start recording it before anything else can happen |
| Definition | Two people, asked separately, give the same answer | A decision has to get made and written down before any build |
| Coverage | The traceable share is high and known | Every number downstream inherits the gap until coverage improves |
That’s the whole checklist. It’s short on purpose: each item is a real yes or no you can check today, not a framework that needs a workshop.
What can’t this checklist tell you?
This ten-minute pass surfaces categories of problem. It doesn’t do the work of solving them. It won’t tell you the exact join required to connect ad spend to a completed job, the precise percentage of records that are actually traceable, or which of your fields quietly return nothing instead of an honest empty value. Those things need someone checking your actual data against your actual questions, one at a time, and that’s a different amount of work than a self-check you run before your coffee gets cold. It’s also not about whether an assistant is grounded in your own data instead of guessing at an answer. That’s a related but separate question, and we’ve written about it on its own: AI that answers from your own data, explained.
It also won’t tell you whether a join that exists will be cheap or expensive to build. Two systems can both store a shared customer or job ID, and the join comes together in an afternoon. Or neither system stores anything the other can match on, and the same join needs someone to add a new field to both systems before the join exists at all. Nothing you can see from the outside distinguishes the two ahead of time. What settles it is someone opening both schemas and checking, field by field, whether a real match key already exists or has to be built from scratch, and that check is exactly the kind of work an Answer Audit does before quoting anything.
None of that makes this checklist less useful. It tells you which category of problem you’re in. It just doesn’t do the next step for you.
What did this look like on a real account?
We ran this against a real account in August 2026: a home-services company running three brands sent us twenty numbered questions about how their marketing spend connected to actual completed work, plus a standing instruction its owner wanted answered every morning, twenty-one items in all. Checked against what genuinely existed in their systems, eight were answerable once we built a single join between ad spend and completed jobs. Six needed one specific named addition each: one needed an ad-spend breakdown the platform already published but nobody was pulling into anything, another needed invoices, because roughly a third of their jobs weren’t being invoiced at the moment they closed, which understated revenue everywhere downstream of that number.
Four questions couldn’t be answered by anyone, and not because the join was hard. The field meant to record who handled a call was empty on all 2,432 calls we examined in that month. The field-service system didn’t have a concept of an assigned technician on a job at all. It wasn’t an empty value sitting there unused; the field simply didn’t exist in what the system sent out. Job titles were entered as free text: 10,085 distinct values across 10,544 jobs, which meant service lines couldn’t be told apart by any mechanical process, no matter how the question was phrased.
The remaining three weren’t really questions at all. Two of them, buried among the twenty numbered questions, were forecasts and recommendations dressed in question grammar, “what should we spend next quarter,” that kind of thing. The third was the standing instruction itself, a recurring request restated as a question every morning rather than a one-time answer. No amount of data readiness fixes that category, because it was never a data problem to begin with.
That’s the shape of a real check: some fraction answerable now, some fixable with one named addition, some that nothing can answer until someone starts recording it, and a handful that were never questions about existing data in the first place.
What does each kind of failure cost, and what can’t an assistant fix?
The real account we ran this against sorted into four categories, and what separates them is effort, not severity. Answerable now is cheapest of the four, but not free: this is the build, joining data that already exists and was already correctly captured. One named addition costs more but stays bounded: name the missing piece, then build it. Nobody records it is the most expensive category, because a field that was never filled in can’t be backfilled: someone has to decide the field matters, build a place for it, get people to start filling it in, and then wait for enough new records to accumulate before the question becomes answerable again. That’s calendar time, not build time, and it’s the category that gets underestimated most often, because on paper it looks like the other three. Not a question costs nothing to fix, because no data work touches it at all; the fix is reframing the ask.
Two of the five checks, capture and definition, share something else: connecting an assistant doesn’t fix either one. If a field has never been filled in, hooking an assistant up to it produces one of two things: a blank, or a confident-sounding guess built from whatever adjacent data happens to be sitting nearby. A guess dressed up as an answer is worse than an honest “we don’t know,” because nobody downstream can tell the difference just from reading it. If two people in your business define a metric two different ways, connecting an assistant doesn’t resolve that disagreement either. It just picks whichever definition happened to get coded into the system it’s pointed at, and states the result with total confidence, no flag, no asterisk, nothing to suggest a second answer exists somewhere else. Both of these need a human decision made first, before anything technical happens. If you take one sentence from this article before spending money on the wrong thing, take that one.
Sorted this way, the four categories aren’t a severity ranking. They’re an effort ranking, and effort, not urgency, is the thing worth knowing before you commit to fixing any of them.
What should you do with your results?
If everything checked out (single system, connector already covers it), you’re done. Use what your vendor ships and move on. If you still want a second opinion before you commit to that, bring nothing more than confirmation of which plan tier you’re on, since that’s the only variable that decides what the connector can actually reach.
If the checklist surfaced joins, blank fields, or a definition fight between two people who each think they’re right, that’s exactly the situation an Answer Audit exists for. We take the real questions you actually have and check each one against what your systems can genuinely answer, sorted into answerable now, needs one named addition, can’t be answered by anyone yet, or a forecast wearing the grammar of a question. It runs one week, from $1,900, and you keep the document either way, whether or not any build follows it. Bring the actual numbered list of questions you tried to answer, not a summary of them, plus whichever join, blank field, or conflicting definition tripped you up, because naming the specific trip point up front means the first call spends its time on your data instead of re-deriving the checklist you already ran.
If you want to see what that fuller check looks like before booking one, we walk through the process step by step here, including a longer version of the account referenced above.