The five questions every SME should ask before starting an AI build.

AI is now within reach of almost every business. But being able to build with it and being genuinely ready to build with it are two very different things.

The gap between access and real value is still wider than most people expect. McKinsey's 2025 global survey found that only 39% of organisations reported meaningful business impact from AI, despite significant investment. Gartner has flagged that a large share of generative AI projects get abandoned after the proof-of-concept stage, usually because of unclear goals, weak data foundations, or costs that grew faster than the returns.

The decisions that matter most are not made during the build. They are made before it.

For a smaller business, the right question is not "Can we build something with AI?" It is "Should we build this, in this way, right now?"

These five questions help you answer that honestly.

1. What operating problem are we actually trying to improve?

The first question is the simplest, and usually the most revealing.

If the answer is vague, the project is not ready. "We want to use AI" is not a business case. "We want to cut order-processing time by 40%" is. "We want to reduce manual triage in customer support" is. "We want to respond to inbound leads in minutes, not hours" is.

A simple check: if you cannot describe the problem clearly in one sentence without using the word AI, the use case probably needs more thought before anyone starts building.

Organisations that see real results from AI tend to define clear outcomes upfront and redesign their workflows around them. The businesses creating lasting value are the ones treating AI as a deliberate capability, not dropping it into an existing process and hoping for the best. Start with one specific friction point and one measurable improvement. Time saved. Errors reduced. Throughput increased. Cost removed. If success cannot be described in practical terms, the build is still being asked to answer a strategy question.

2. Is the workflow, and the data behind it, clean enough to be useful?

AI is a multiplier. It accelerates whatever sits underneath it.

If the workflow is unclear, the handoffs are messy, the rules live in people's heads, and the data is scattered across spreadsheets, inboxes, PDFs, and disconnected tools, AI will usually make that messier, not cleaner. The technology does not resolve underlying confusion. It amplifies it.

Research consistently links successful AI adoption to stronger data readiness and clearer processes. Businesses with fragmented foundations tend to struggle more, not because the technology fails them, but because the underlying work was never tidy enough for automation to improve.

So the question is not whether your data is perfect. It almost never is. The better question is whether it is good enough for the specific task you have in mind. Can the right information be reached reliably? Is it recent enough to be useful? Are the exceptions understood? Does the business have the right to use it in this way? If the answer to any of those is no, the first phase of the project is probably not model development. It is workflow clarification and data preparation.

3. Will this improve the way people already work, or create a new silo?

Many AI ideas sound strong in a planning session and fail quietly in everyday use.

The pattern is almost always the same. The tool sits outside the real workflow. People have to leave their normal systems, open a separate interface, copy information across, and then bring the result back into their actual work by hand. When that happens, the AI becomes an extra step rather than an improvement to the job. Adoption slips quickly, and often silently.

Workflow design is often more important than the technology choice itself. Redesigning how work happens around a new capability, rather than bolting it on top of existing processes, is one of the strongest predictors of meaningful impact. For smaller businesses, this question usually matters more than which model you choose. A build is far more likely to succeed when it lives inside the tools people already use. It is far less likely to succeed when it sits in a separate system that relies on habit and goodwill alone.

4. What level of human oversight does this use case require?

Not every AI use case carries the same level of risk, and it helps to be honest about that before you start building.

Summarising internal notes is low stakes. Recommending the next best action in a customer service conversation is a step up. Sending communications automatically, changing records, approving transactions, or handling sensitive personal data is a step up again.

A useful way to think about it before you commit: should the system read, recommend, or execute? Read means it analyses information and surfaces it for a person to act on. Recommend means it proposes an action, but a person approves it before anything happens. Execute means it acts directly, without a human in the loop.

For most smaller businesses, recommend is the right place to start. It creates speed and efficiency without removing the human judgement that keeps things accountable. Frameworks like NIST's AI Risk Management Framework emphasise the importance of being clear about who is responsible for what, where human oversight sits, and how decisions get escalated or reviewed. If your business cannot explain, in plain language, where a person stays in control and what should never happen automatically, it is too early to put the system into production.

5. Does this really need a custom build, and what must happen in the first 90 days?

This is the commercial question, and it is often the one people ask too late.

Not every good AI use case needs a custom build. Some are better handled with existing software, a lighter integration, or a structured workflow using off-the-shelf tools. Others genuinely justify custom development, because the process is unique, the data is sensitive, the systems are too fragmented for a ready-made solution, or the operational value is high enough to warrant something built specifically for the business.

Before committing to either path, set a 90-day value gate. Decide what must improve in the first 90 days for the project to count as real progress. That could be turnaround time, support capacity, lead response speed, error reduction, or any other operational metric that genuinely matters to the business. If there is no clear answer to that question, the project is at risk of becoming an open-ended experiment with no natural stopping point. Gartner links project abandonment directly to unclear goals, weak controls, and rising costs. The question is not just "Can this be built?" It is "What is the smartest path to value?"

The pattern behind all five questions.

These questions are simple on purpose.

Most disappointing AI projects do not fail because the technology was the wrong choice. They fail because the business started building before it had answered the basics: what exactly needs to improve, how the work should change, who stays accountable, and whether the economics make sense.

Real results tend to come not from the largest budgets or the most advanced models, but from stronger operating discipline. Clearer goals. Redesigned workflows. Defined oversight. Better foundations. A preference for deliberate progress over open-ended experimentation.

For a smaller business, that is genuinely encouraging. Success is not reserved for the firms with the deepest pockets. It belongs to the ones that ask better questions before the build begins.

The best AI projects tend to start before a single line of code is written. They start when a business can say clearly what needs to improve, how the work will change, where people stay in control, and what evidence would justify going further.