In this guide 6 sections
Readiness depends less on data volume than on three questions: can you state the problem, does a named person review the output, and can you afford the oversight. Modest data is often enough. A business with imperfect records and a clear owner is often more ready than one with a huge dataset and no review plan.
Writing the problem down before looking at tools
“Use AI somewhere” is not a start. Readiness begins with one specific sentence naming the task, who handles it today, how long it takes, and what an acceptable error looks like. If that sentence cannot be finished, no tool evaluation will help, because there is nothing to measure any candidate product against once the demos begin.
Consider a hypothetical chain of automobile service centres deciding whether AI should draft replies to customer enquiries that arrive as phone transcripts and emails. “Improve customer service” is useless as a problem statement, whereas “draft a first-pass reply to routine status and pricing questions, for a human to check” can be tested. The AI never commits to repair dates. That line defines acceptable error.
The condition of the data, not its size
The instinct is to assume a large, clean dataset must exist before AI is viable, but for document extraction, question answering and template drafting that is rarely true. Three tests matter instead. Is the data accessible, in a format a system can read; current, not three years stale; and permitted for this purpose, including any customer consent?
For the service centre chain, the relevant data is not a vast archive but whether service manuals, pricing sheets and warranty terms are up to date. They must also sit somewhere searchable, not scattered across branch managers’ personal folders, old email attachments and a shared drive nobody has tidied since the last reorganisation. Tidy sources come first.
Who owns the process and who reviews the output
AI pilots stall or misfire most often not because the model was wrong but because nobody was clearly responsible for checking what it produced. Before starting, name the owner of the process the AI touches and the colleague who reviews a sample of its output every week. They may be the same person.
“The team will review it” fails. It usually means nobody does once the first excitement fades, whereas a named owner with review time blocked in their calendar keeps quality visible. One pilot catches its own mistakes early, while the other drifts quietly until a customer or an auditor finds the damage first. Review continues after launch.
Budgeting the ongoing work, not just the setup
The setup cost of an AI pilot is usually visible on a quote, while the ongoing cost hides inside somebody’s normal week. Someone must check output quality periodically, update source documents when policies change, and handle the cases the AI declines to answer or answers badly. None of it is large. It still needs to exist as a named task rather than an assumption that the system just works once it is live.
At the service centres, someone re-reads a sample of AI-drafted replies every week and someone updates the pricing sheet whenever prices change. Stale prices are costly. Without that update the assistant will confidently quote last quarter’s numbers to a customer who then holds the branch to them in writing.
Turning gaps into a pilot plan
None of this must be perfect. Identify the weak spots in problem definition, data condition, ownership and ongoing capacity, then mark which gaps a small pilot can tolerate. Fix the rest first.
For most small businesses that means the narrowest useful slice: one task, one team and a defined review window of a few weeks. Readiness is partly built through the pilot itself, so it is not a bar you must clear completely before anyone writes a line of configuration. Start narrow and review.
AI readiness checklist
A one-page checklist across four sections: problem definition, data condition, process ownership and ongoing capacity, each with three or four yes or no questions and a note field. Mostly yes on ownership and problem definition marks the business ready for a narrow pilot, even when the data has gaps that a reviewer can catch. Ownership gaps get fixed first.
Open a blank worksheet to printQuestions owners ask
Do we need a large dataset?
Not for most small business cases. Document extraction, internal question answering and drafting from templates typically work with whatever documents and records the business already holds, provided they are accessible, current and permitted. Quantity matters much less.
Can we start with imperfect data?
Yes, if the pilot tolerates it. For instance, route anything the AI is uncertain about to a person instead of letting it guess, and log every case it declined. Imperfect data is a reason to start narrow with review built in, not a reason to wait for a perfect archive that will never exist.
Who should own an AI pilot?
Pick someone close to the work. The owner should be the manager of the process the AI touches, with review time set aside weekly and authority to pause the pilot.