A small business does not need a large AI strategy document to begin. It does need enough clarity to avoid a tool purchase becoming another disconnected subscription and another burden for the team.
01 / The work
Can you name one operational problem worth improving?
Start with the work, not a product name. Write down one process that consumes attention, causes delay or creates inconsistent customer follow-up. Describe who touches it, what triggers it and what a better result would look like.
If the answer is only ‘we need to use AI’, the business is not ready to buy anything. Spend time with the people doing the work until there is a concrete problem to test.
- Named outcome The team can state what should improve in plain operational language.
- Visible baseline You have examples of the current delay, rework or missed handover.
- Clear owner Someone can answer questions and decide whether the new process is helping.
02 / Information
Do you know what information the work needs?
List the documents, systems, inboxes and people the process currently relies on. Identify the approved source for each important fact. This prevents a pilot from producing a convincing answer from the wrong version of a customer record or procedure.
Consider information boundaries early. Decide what may be used for a test, what needs to be removed or anonymised and who should approve access. If personal, confidential or commercially sensitive material is involved, get appropriate advice for your circumstances before opening access to a new service.
03 / People
Are staff involved in the design and able to challenge the result?
The people closest to a process often know its hidden exceptions. Involve them when choosing the pilot, designing review points and deciding what the tool should never do. This improves the workflow and makes change feel less like something imposed from outside.
Training should use examples they recognise. The aim is not to turn everyone into an AI specialist. It is to help people know when a draft is helpful, when to correct it and when to stop and ask for support.
04 / Control
Can you keep important decisions and exceptions visible?
For an early pilot, decide where review happens, who may approve an action and how an uncertain item is escalated. A workflow that quietly completes everything may look efficient until the first unusual case is mishandled. A visible exception route is part of good service.
Also decide what happens when a connected service is unavailable or the output is wrong. Staff should be able to continue the work through a normal fallback, and the issue should be recorded so the workflow can improve.
05 / Learning
Have you chosen a short, measurable pilot?
Set a review date and one or two measures before you start. The measure might be response time, number of completed records, amount of manual retyping or the quality of follow-up. Keep it tied to the original operational problem.
At the end of the pilot, decide whether to stop, adjust, extend or integrate the change properly. Readiness includes being willing to say no when the evidence is weak. A business that learns from a contained test is in a stronger position than one that collects tools without changing the work.