Most "we should use AI" conversations stall because they start at the technology and work backwards to a problem. Readiness runs the other way. This AI readiness checklist is the order we actually assess opportunities in: each item is a question you can answer this week, with what good looks like and the trap that catches most teams. None of it requires a data science team or a year of preparation.
1. A real business problem, not "we should use AI"
What good looks like: you can finish the sentence "we lose time/money/customers because ___" with something specific and recurring. A bid team that re-answers the same 200 RFP questions every month. A support queue where 40% of tickets are variations of the same ten questions. A finance team keying invoice data by hand. The problem has a shape, a frequency, and a cost — even a rough one.
The common trap: starting with the tool. "We want a chatbot" or "can we use a copilot" is a solution looking for a problem, and it almost always lands on the wrong process. Generative AI is good at specific things — drafting, summarising, classifying, extracting, answering from your own documents — and indifferent or dangerous at others. Lead with the pain, and the right technique tends to pick itself.
2. Data you can actually reach
What good looks like: the information the system needs already exists somewhere a person could get to it — a SharePoint library, a CRM, a ticketing system, a shared drive, a database. It doesn't have to be tidy. It has to be reachable, and you have to be allowed to use it for this purpose.
The common trap: assuming you need a "data strategy" or a warehouse before you can start. You usually don't. The more common blocker is the opposite — data that's reachable in theory but locked behind a permission nobody will grant, or scattered across systems that don't talk to each other, or contains personal data with no agreed basis for using it. We work inside your existing systems, identity and permissions rather than around them, so the honest question isn't "is our data clean?" — it's "can the right people, and only the right people, reach it?" Sort that question early and the build gets dramatically simpler.
3. A process worth automating — repetitive, rule-ish, high-volume
What good looks like: the work happens often, follows a recognisable pattern, and a knowledgeable human could explain how they do it. High volume multiplies the payback; repetition makes the behaviour learnable; a describable rule-of-thumb means you can check whether the AI got it right.
The common trap: aiming the first project at the hardest, most judgement-heavy decision in the business — the one a senior person agonises over. That's where AI is least reliable and the cost of a wrong answer is highest. Start where volume is high and the stakes per item are survivable, prove the pattern, then move up. A good first build is boring on purpose. If you want a quick sense of which process pays back fastest, our AI ROI calculator lets you put rough numbers against hours saved before you commit to anything.
4. A named owner who wants the outcome
What good looks like: one person inside the business owns the result — not the technology, the result. They feel the problem today, they'll use what gets built, and they have enough authority to change how their team works once it ships. When that person is in the room, decisions get made in minutes instead of weeks.
The common trap: "IT will own it" or, worse, nobody owns it and the project belongs to a committee. AI that changes how people work needs someone who wants the change badly enough to defend it. Projects without that person don't fail loudly — they quietly never get adopted, and the model sits unused behind a login.
5. A way to measure whether it worked
What good looks like: before anything is built, you can say how you'll know it helped. Hours saved per week. Tickets deflected. Days off a bid cycle. Error rate down from x to y. The baseline — what the number is today — is written down, so the "after" means something.
The common trap: measuring activity instead of value. "The model answered 5,000 queries" tells you nothing about whether anyone was better off. Pick a metric tied to the business problem from item one, capture today's baseline before you start, and you turn a vague sense of "it feels faster" into a number you can defend to a board. This is exactly what a good ROI case does — and it's the part most internal pilots skip, which is why so many can't prove their worth and get cut.
6. Appetite for evaluations and guardrails
What good looks like: you accept that an AI system needs testing the way a human needs training — and ongoing checking the way any process needs QA. Evaluations measure whether the system is right often enough to trust. Guardrails decide what it's allowed to do unsupervised and where a human signs off. You're willing to start with the AI assisting a person before you let it act alone.
The common trap: treating the launch as the finish line. A model that worked in a demo can drift, a provider can change pricing or quality, and an edge case you never saw can produce a confident wrong answer. Readiness here is a mindset more than a budget: you want evaluations and monitoring built in from the first week, not bolted on after an incident. That's the difference between a system you can lean on and a clever prototype you're nervous to depend on. It's the work that lives in managed AI operations — evals, monitoring and on-call so the system stays trustworthy in production.
Scored your six? Here's the honest next step
If you ticked all six, you're ready to build — and the next move is to define precisely what to build first, in what order, for what return. That's what the free, no-obligation AI Readiness Diagnostic does: a short, structured engagement that leaves you with a statement of work, a wireframe and a clear ROI case you keep, whether or not we ever build it together. The first paid step only comes later, as a proof of concept, once you've decided it's worth it.
If you ticked four or five, you're closer than you think — the missing items are usually a reachable-data question or a named owner, and both are fixable in days. Either way, a 30-minute call will tell you honestly where you stand and what a sensible first step looks like. No pitch, no obligation.
Common questions
How do I know if my business is ready for AI?
You're ready when you can answer six questions honestly: you can name a specific, recurring, costly problem; you can reach the data that problem touches; you have a repetitive, high-volume process worth automating; one named person owns the outcome and wants it; you've agreed how you'll measure whether it worked; and you accept the system needs evaluations and guardrails after launch. If you can tick all six, you're ready to build. If you can tick four or five, you're close — the missing items are usually a data-access question or a named owner, and both are fixable in days rather than months. A free AI Readiness Diagnostic turns the gaps into a concrete plan.
Do I need clean or perfect data before starting an AI project?
No. The more useful test is whether the data is reachable and you're allowed to use it for the purpose — not whether it's tidy. Most AI projects start with messy data spread across a CRM, a ticketing system, SharePoint or a shared drive, and that's normal. The real blockers are usually permissions (data nobody will grant access to), fragmentation (systems that don't talk to each other), or personal data with no agreed basis for use. Sorting the access and permissions question early matters far more than a data-cleaning exercise, and it makes the eventual build much simpler. Working inside your existing systems and identity, rather than around them, keeps access tied to controls you already trust.
Why do internal AI pilots so often fail to prove their value?
The most common reason is that nobody agreed how to measure value before building, so the pilot ends up reporting activity — queries answered, documents processed — instead of business outcomes. Without a baseline captured up front (hours spent today, current error rate, days per cycle), there's no honest before-and-after, and a project that genuinely helped can't defend itself when budgets tighten. The fix is to pick one metric tied to a real business problem, write down today's number before you start, and target a specific improvement. That single discipline is what separates pilots that earn a second phase from the ones that quietly get cut.
See it in practice: Planning evidence search — a project scoped around the data before a line of code →