Every demo works. That is what demos are for. The vendor picks a clean example, feeds it clean data, and the output looks like magic. Six weeks later the tool is sitting unused in a browser tab because nobody could get it to work on a real Tuesday with real messy inputs.
The uncomfortable truth is that most AI projects fail on the buyer's side of the table, not the vendor's. Readiness is about your data, your processes, your people, and your ability to make a decision and stick with it. The seven questions below are a diagnostic, not a sales filter. A "no" is not a verdict against AI — it is a work order.
1. What specific decision or task would this replace?
"We want to use AI" is not a use case. "We want to cut the time between a quote request and a sent quote" is. Write the task down in one sentence that a new hire could understand, and name the person who does it today.
If you cannot name the task or the person, you are shopping for a category, not solving a problem. That is the single most reliable predictor of a tool that gets abandoned. Start with the workflow that annoys someone every single day — annoyance is a better signal than ambition.
2. Can you describe the process without the tool?
Say the current steps out loud. Where does the work start? What triggers it? What does the person look at, and in what order? Where do they stop and wait for someone else?
If the process only exists in one employee's head, an AI tool will not extract it — it will just automate whatever fragment you happen to describe on the day you configure it. Documenting the process first is unglamorous and it is the highest-leverage hour you will spend. Our guide to running a process audit covers how to do this without a consultant in the room.
3. Where does the data live, and who trusts it?
AI tools are downstream of your records. If your customer list lives in three places with different spellings, an assistant that drafts customer emails will confidently draft the wrong ones.
Ask two questions about every data source the tool will touch. First: is it complete enough that a human uses it today without double-checking somewhere else? Second: who is responsible for keeping it current? If the answer to the second question is "nobody, really," fix that before you buy anything. Data ownership is a staffing decision, not a software decision.
4. What does "good" look like, and can you measure it today?
You cannot prove an improvement without a baseline. Before the pilot starts, capture the current numbers by hand if you have to: how long the task takes, how many get done per week, how often something has to be redone.
Three or four weeks of scrappy manual measurement beats a dashboard you build after the fact. It also protects you from the most common outcome in AI adoption, which is that everyone feels faster and nobody can say whether anything changed.
5. Who owns the output when it is wrong?
AI systems produce confident output regardless of whether they are correct. That is not a bug you can configure away, so you design around it. Decide in advance who reviews what, and at which step the human signature goes on.
The practical version of this is a review rule: drafts go out only after the account owner reads them; internal summaries can go unreviewed; anything touching money, contracts, or a customer commitment gets a named approver. Write the rule down before launch, because after launch nobody will want to be the one who slows things down.
6. What is the cost of a bad answer?
Sort your candidate use cases into risk tiers. A low-stakes task is one where a wrong output wastes a few minutes and someone catches it immediately — meeting notes, first-draft copy, internal search. A high-stakes task is one where a wrong output reaches a customer, a regulator, or your books before anyone notices.
Start in the low tier. It is not timidity; it is how a team builds the judgment to handle the high tier later. Teams that begin with billing or compliance almost always retreat, and the retreat poisons the next attempt.
7. Who will actually use it on a Tuesday?
Adoption lives or dies with one or two people who find the tool genuinely useful and tell others. Identify them by name before you buy. Ask whether they have the time, whether they are curious, and whether they have any authority to change how the work is done.
If your candidate user is already at capacity, the tool will lose to the urgent work every week. Building that internal capability is a separate project with its own effort — worth planning through structured training rather than hoping enthusiasm appears on its own.
Score your readiness
Give yourself one point for each item you can answer clearly and honestly today:
- The task is written in one sentence and has a named owner.
- The current process is documented well enough for someone else to follow it.
- The data the tool needs lives in one place and someone maintains it.
- You have a baseline measurement, even a rough one.
- You have a written review rule for AI output.
- Your first use case sits in the low-risk tier.
- You can name the person who will use it weekly.
6–7 points: Run a scoped pilot with a fixed end date and clear kill criteria. 4–5 points: Close the gaps first; most are a week of work, not a quarter. 0–3 points: Do not buy yet. Map one process, clean one data source, and revisit. You will spend less and get further.
If the gaps are structural rather than tactical, an outside read on sequencing can save months of false starts — that is the core of how AI consulting engagements should begin.
Frequently asked questions
Does a small team really need a readiness assessment?
Small teams need it more, not less. You have fewer people to absorb a failed rollout and less slack in the calendar to restart. Twenty minutes with these questions is proportionate to the risk.
What if the vendor offers a free trial?
Free trials remove the cost but not the risk. The expensive part of a bad AI project is attention and credibility with your team, and a trial spends both. Use the same seven questions before the trial starts.
How long should a first pilot run?
Long enough to see real variation in the work and short enough to force a decision — typically about a month for an SMB workflow. Set the end date and the kill criteria on day one.
What if we score low on data quality?
Then data cleanup is your AI project for now. It is not a detour. Every downstream automation you build later will be more reliable because of it.