Is Your Business Ready to Implement AI?

"We should use AI somewhere" is not a starting point — it's a feeling. Readiness begins with a specific sentence: which task, handled by whom today, taking how long, with what an acceptable error looks like. If you can't finish that sentence, no tool evaluation will help, because you won't know what you're measuring it against.

Consider a chain of automobile service centres deciding whether to let AI draft responses to customer service enquiries received by phone transcript and email. The useful version of the problem isn't "improve customer service" — it's "draft a first-pass reply to routine status and pricing questions, for a human to check before sending, and never let it commit to a repair timeline on its own." That sentence tells you what "acceptable error" means before a single tool is chosen.

The instinct is to assume you need a large, clean dataset before AI is viable. For most SMB use cases — document extraction, question-answering over existing files, drafting from a template — that's not true. What matters far more is whether the data you already have is accessible (in a format something can actually read), current (not three years out of date), and permitted (you're allowed to use it for this purpose, including any customer consent question).

For the service centre chain, the relevant "data" isn't a huge historical archive — it's whether the service manuals, pricing sheets and warranty terms it would draw answers from are up to date and stored somewhere a system can actually search, rather than scattered across branch managers' personal folders.

AI pilots stall or misfire most often not because the model was wrong, but because no one was clearly responsible for checking it. Before starting, name the person who owns the process the AI touches, and the person (possibly the same one) who reviews a sample of its output on an ongoing basis — not just during the pilot.

This matters more than it sounds. "The team will review it" usually means no one does, once the initial excitement fades. A named owner with review time actually set aside in their week is the difference between a pilot that catches its own mistakes and one that quietly drifts.

The setup cost of an AI pilot is usually visible; the ongoing cost is usually not. Someone needs to periodically check output quality, update source documents when policies change, and handle the cases the AI declines to answer. None of this is large for a narrow pilot, but it needs to exist as a real, named task — not an assumption that the system "just works" once it's live.

For the service centre example, that means someone re-reads a sample of AI-drafted replies every week, and someone updates the pricing sheet the AI draws from whenever prices change — otherwise the AI will confidently quote last quarter's numbers.

None of the above needs to be perfect before you start — it needs to be identified. List where the problem definition, data condition, ownership or ongoing capacity are weak, decide which gaps are acceptable for a small pilot and which need fixing first, and scope the pilot to the area where you're strongest.

For most SMBs that means picking the narrowest possible slice of the problem — one task, one team, a defined review window — rather than waiting until every gap is closed. Readiness is something you build a little through the pilot itself, not a bar you have to clear beforehand.