AI Readiness Checklist for UK Small Businesses
Assess your workflow, data, risks and costs before investing in AI. A practical checklist for choosing a useful first pilot.
The purpose of an AI readiness assessment is to put one question to the test: can your business put in place a specific improvement that is both safe and economical? There is no call for an organisation-wide transformation plan to get started. What is required is a sensible workflow, data you can work with, an owner for the outcome and some means of gauging if the change has been of any use.
We have put together this checklist for UK small businesses as they contemplate their first foray into AI. It is something to have at hand before you part with money for another subscription or commission a bespoke app. The objective is to make a sound investment, even if it turns out that conventional automation is the wiser course.
1. Describe the task before choosing a tool
Before you pick a tool, describe what is being done. Note the trigger, the action and the end product. “Use AI in customer service” does not give you enough to go on, “have the system draft a reply to delivery questions based on our policy for a team member to sign off” is something you can test.
If there is disagreement over how things are run today, resolve it. Do not try to automate a process that is not clearly defined, as that will only obscure the uncertainty. Make sure you have a record of a typical case as well as an awkward exception.
2. Check the information the system would need
List the documents, messages and records required. Note who owns each source, how often it changes and which staff can access it. A shared folder containing several contradictory price lists is not ready to become an authoritative answer source.
Is the information accurate enough for the task?
Can obsolete versions be identified?
Are access permissions documented?
Can examples be prepared without exposing unnecessary customer information?
For document-heavy work, read the guide to AI document processing. It explains why extracting a value and trusting that value are different steps.
3. Match the review level to the consequences
There is a world of difference between an email subject line the system suggests and an instruction to pay a supplier. Determine which outputs can stand on their own and which require a human to say so. Make the approver a visible part of the workflow rather than leaving it to chance.
And have a plan for when the tool is down or stumped. Staff should not be left to contrive a workaround in the middle of a busy afternoon, a manual fallback is part of the design.
4. Put a baseline against the work
Take some measurements on a sample before you start making changes. Time the handling, note the delays and corrections. When you put a pilot up against the way things are done now, factor in the time taken to review the new output.
By way of example, 100 tasks a month at eight minutes apiece is 13 hours of work. If a pilot brings that down to five minutes all in, you have freed up five hours. That is capacity, but do not mistake it for a cash saving until someone has decided what to do with it.
5. Choose one pilot and a stopping rule
Your brief for a short pilot should cover the task, the data, the cost cap and who is responsible. Have clear success criteria and include some failure cases in the mix. Pre-emptively decide what would warrant a stop or a revision.
Also compare what you are thinking of building with what your current tools can already do. A custom-versus-off-the-shelf comparison option may save you from an unnecessary development project.
What to bring to an AI discovery conversation
Bring a process outline, a few appropriately redacted examples, an estimate of monthly volume and the names of the systems involved. You do not need to choose a model or write a technical specification.
My AI consultancy and integration service helps turn that information into a prioritised recommendation and a scoped next step. I work from Watford with businesses across Hertfordshire and the UK. Tell me which task is slowing your team down.
Written by Paul - PJE Designs
Solo Laravel developer in Watford, Hertfordshire with 20 years' experience building SaaS platforms, web applications and websites for UK businesses. More about me · Work with me
Enjoyed this article?
One useful email a month on Laravel, performance and building web apps.