The First 90 Days: A Practical AI Adoption Roadmap for UK SMEs

Most AI advice aimed at small businesses is either too abstract to act on or written for companies with a data team sitting behind it. What follows is neither.

This is the ninety-day sequence I run with UK SMEs, typically somewhere between twenty and two hundred people, who want to move from scattered experimentation to one or two things genuinely working. No new hires. No committing to a platform before you understand the problem.

Ninety days is deliberate. It is long enough to ship something real and short enough that the people involved can hold the thread. Anything longer tends to lose its sponsor to a reorganisation, a busy quarter, or simple fatigue.

What this assumes

Two things. First, that you have no dedicated AI staff and no intention of hiring any this year. The sequence is designed to be run by an operations lead with perhaps a day a week to give it.

Second, that you would rather have one workflow working properly than five half-configured tools. If either assumption is wrong the timeline changes, but the order of operations does not.

Days 1 to 30: find the expensive, boring work

The first month produces no software. It produces a shortlist and a baseline, and skipping it is the most common reason the other sixty days get wasted.

1. Run a time audit, not a brainstorm. Ask each team to log where the week actually goes for a fortnight, in rough categories. Brainstorms surface exciting ideas. Time audits surface expensive ones. In my experience they rarely produce the same list.

2. Shortlist by cost and repeatability. You are looking for work that is high volume, rule heavy, low judgement and currently done by someone expensive. Supplier onboarding, invoice coding, first-line support triage, tender first drafts and meeting follow-ups come up again and again for a reason.

3. Write down the baseline. Hours per week, error rate, turnaround time, whatever you can measure honestly in an afternoon. Without this number you cannot prove value later, and unproven value does not survive the next budget review.

4. Check the data reality. For each candidate, ask where the information lives and who is allowed to see it. A use case that depends on data trapped in a legacy system is not a month-one project, however attractive it looks. This is also the point to check your permissions are fit for the current shape of the business rather than the shape it was two years ago.

By day thirty you should have three candidates ranked, one baseline measured, and a clear-eyed view of which of them are actually reachable with the systems you have today.

Days 31 to 60: build one thing, narrowly

Month two is about resisting scope. Pick the top candidate and build the smallest version a real person can use for real work.

Narrow means one team, one workflow, one output format. If the use case is proposal drafting, that means drafting the first two sections for one product line, not a general-purpose proposal engine.

The point of the second month is not to prove the technology works. Everyone already believes that. It is to discover the twenty unglamorous details that decide whether people actually use it: where the draft appears, how corrections get made, what happens when the source document is missing a page.

Two rules make this month go better.

Put the output where the work already happens. The CRM record, the shared drive, the ticket. Not a new tool people have to remember to open.

Instrument it from day one. Log every run, every correction and every abandonment. That log is what turns month three from an argument into an analysis.

Expect this month to feel slower than it should. The build itself is usually a week or less. The rest is discovering that the pricing sheet has three versions in circulation, or that half the team never fills in the field the model depends on. Those discoveries are the actual product of month two, and they are the reason the second project runs so much faster than the first.

Days 61 to 90: prove it, then decide

The final month is measurement and a genuine decision. Run the tool with the target team under normal conditions and compare against the baseline you captured in month one.

• Measure the same thing you measured before. Same definition, same method. Changing the measure between baseline and result is the fastest way to lose the room.

• Separate time saved from quality changed. A tool that saves four hours but produces work needing rework has not saved four hours.

• Count corrections, not just outputs. The correction rate tells you where the next iteration should go, and whether the human-in-the-loop step can safely be relaxed.

• Ask the team the blunt question. Would you be annoyed if we switched this off tomorrow? The answer is more predictive than any dashboard.

Then make one of three decisions explicitly: scale it to more teams, iterate for another thirty days on a specific known weakness, or stop. Stopping is a legitimate and badly underused outcome. A project honestly killed at day ninety costs you a quarter. One that limps along unowned costs you years.

Who should run it

The owner matters more than the tooling. The best candidate is rarely the most technical person available. It is whoever understands the process well enough to know when the output is subtly wrong.

That is usually someone who has done the work themselves, has enough standing to ask other teams for data access, and can be given a genuine day a week rather than an informal expectation on top of their existing job.

Give that person a named sponsor at leadership level and fixed review dates at day thirty, sixty and ninety. Most ninety-day plans fail quietly somewhere around week five, and a scheduled checkpoint is the cheapest insurance available against that.

What to avoid

• Buying a platform in month one. You do not yet know what you need it to do. Point solutions first, consolidation later.

• Rolling out to everyone at once. Broad rollouts generate noise rather than signal, and one bad early experience sets the internal narrative for a year.

• Leaving policy until later. Agree what data may go into which tools before people start pasting client information into whatever they found. It takes an afternoon and prevents the most expensive category of mistake.

• Assigning it to whoever is keenest. Enthusiasm is not availability. The owner needs real hours, not goodwill.

After day 90

If the first cycle worked, the second is significantly easier. You have a baseline method, an internal example people trust, and a much better sense of where your data actually lives. Most businesses find the second and third workflows take half the elapsed time of the first.

If it did not work, ninety days was still cheap, and the time audit and data map from month one remain useful regardless of what you build next. That is the quiet advantage of running adoption this way. Even the failures leave you better informed than you were.

None of this requires unusual technical ability. It requires picking one expensive, boring problem, measuring it honestly, and staying with it for three months. That is a lower bar than most AI strategy documents suggest, and a considerably higher one than most businesses actually clear.

Matt Neal is the founder of Artificia1, an AI training and strategy consultancy working with UK SMEs. If you want help running your own ninety days, get in touch.