AI Strategy Consulting for SMEs: Build a 90-Day Roadmap That Produces Evidence

Most AI strategy documents are too wide to operate. They list promising departments, fashionable tools and distant ambitions, but they do not tell a process owner what to test on Monday morning.

For a small or medium-sized business, a better strategy is a controlled sequence of decisions. It begins with a real constraint, exposes the data and risk, tests one workflow against a baseline, and makes expansion conditional on evidence.

This 90-day AI strategy consulting framework is designed to do exactly that. Its finish line is not “adopt AI”. It is a decision pack your team can inspect:

• one tested workflow with a named owner;
• evidence comparing it with the current process;
• documented data, human-review and failure boundaries;
• a decision to scale, revise or stop;
• a shortlist of what deserves attention next.

Why 90 days is a useful boundary

Ninety days is long enough to observe real cases after the demonstration effect wears off, yet short enough to prevent “discovery” becoming an indefinite consultancy project.

It also matches what current UK evidence suggests businesses need. The Department for Science, Innovation and Technology’s 2026 AI Adoption Research found that limited skills and the absence of an identified need were common adoption barriers. Among adopters, text generation was far more common than agentic AI, and most reported at least some human checking.

The latest Office for National Statistics analysis, Artificial intelligence in UK businesses: 2023 to 2026, describes adoption as relatively shallow among businesses with ten or more employees. A separate 2026 UK Business Data Survey reports higher usage among businesses handling digitised data, while noting that definitions and survey populations produce different adoption estimates.

Do not turn either percentage into a sales slogan. The useful conclusion is simpler: trying a tool is not the same as embedding a dependable operating capability.

What must be true before day one

You do not need a perfect data platform or a company-wide AI policy to begin discovery. You do need five decisions.

1. A business sponsor

The sponsor can approve access, remove blockers and decide whether a result matters. “The innovation team is interested” is not sponsorship.

2. A process owner

This person understands the work, supplies real examples, judges exceptions and owns the process after the pilot. A consultant cannot permanently substitute for them.

3. A narrow problem statement

Use this structure:

When [trigger] happens, [person] spends [measured effort] producing [output] from [evidence]. The main failure is [specific error or delay]. We want to improve [one measure] without worsening [important constraint].

“Use AI in customer service” is a theme. “Prepare a cited first draft from the approved knowledge base for a human agent to review” is a testable workflow.

4. Permission to inspect the current process

Strategy fails when it models the process people say they follow rather than the one they actually use. Observe several cases, including an awkward one.

5. Authority to stop

Write stop conditions before the team becomes attached to a prototype. A pilot is an experiment, not a promise that something will launch.

Days 1–30: discover, score and baseline

The first month is not a tool comparison. It is the work required to make a tool comparison meaningful.

Map the current workflow

Record:

1. trigger and desired output;
2. source information and where it lives;
3. decisions and exceptions;
4. roles, approvals and hand-offs;
5. systems touched;
6. failure and rework routes;
7. total elapsed and active handling time.

Do not automate a process whose output nobody can define. Simplifying a form or removing a duplicate approval may create more value than adding a model.

Build a candidate-use-case scorecard

Score each candidate from one to five.

Factor	A strong first-pilot signal	A warning signal
Frequency	Repeats often enough to generate evidence	Rare or seasonal task
Rule clarity	Good and bad outputs can be distinguished	Decisions depend on tacit judgement
Data readiness	Approved, representative examples exist	Data is missing, sensitive or inconsistent
Reversibility	Output remains a draft or recommendation	Action is difficult to undo
Human capacity	A reviewer is available and accountable	“Human in the loop” has no named human
Learning value	Test informs several future decisions	One-off novelty with no reusable learning

A high-value but irreversible workflow is not automatically the best first pilot. The first pilot should generate trustworthy evidence at manageable risk.

Establish the baseline

Measure at least ten representative historical or live cases before changing the process. Record:

• active handling time and waiting time;
• completion and exception rates;
• rework and escalation;
• common error categories;
• service or quality outcome;
• current software and external cost.

Avoid a single average. A workflow that takes five minutes nine times and three hours once needs an exception analysis, not a six-minute target.

Define the data boundary

List what the pilot may and may not use, the approved account or environment, who has access, retention expectations and whether outputs become records. Use public, fictional, de-identified or otherwise approved data until this is settled.

The ICO’s AI guidance and practical resources are a useful starting point for data-protection questions. They do not replace advice appropriate to your organisation and use case.

Deliverable at day 30

The decision pack should now contain:

• a current-state process map;
• candidate scorecard and chosen workflow;
• baseline and representative test set;
• data and access boundary;
• owner, sponsor and reviewers;
• acceptance and stop criteria;
• pilot cost and dependency assumptions.

If these do not exist, the project is still in discovery even if a prototype has been built.

Days 31–60: run a bounded pilot

The second month produces controlled operational evidence.

Start in the least autonomous mode

Use a progression:

private test → draft-only assistance → supervised live cases → approved limited use

Do not begin by allowing a system to send, publish, delete, purchase or change a record. First prove that it can prepare a useful output and that a human can identify failures.

Freeze the question, not the software

Tools may change during the pilot, but the acceptance question should remain stable. For example:

Can the workflow prepare a correct, source-linked response draft for at least 18 of 20 representative enquiries, with no prohibited claims, while reducing median total handling time and keeping human approval before sending?

This includes quality, evidence, time and control. “The model produced something impressive” includes none of them.

Keep an error ledger

For every failed case, record:

• input type;
• expected result;
• actual result;
• error category;
• whether a reviewer detected it;
• correction effort;
• design change;
• retest result.

An error ledger is more valuable than a growing prompt full of unexplained instructions. It turns failure into reusable design knowledge.

Compare total effort

Count preparation, model time, human checking, correction, escalation and maintenance. A 30-second draft followed by twelve minutes of checking is a twelve-and-a-half-minute workflow.

Hold a day-60 gate

Choose one:

• continue unchanged because evidence is strong enough;
• revise the design and repeat defined cases;
• reduce the scope to a safer or clearer subtask;
• stop because the economics, data or risk do not work.

Stopping is not failure. Continuing without evidence is.

Days 61–90: prove the operating model

A successful prototype is not yet a sustainable business capability. The last month tests ownership and repeatability.

Remove the consultant from the happy path

The process owner should run the workflow, diagnose routine failures and explain when to stop without the consultant present. If only the builder can operate it, handover has not happened.

Create the minimum operating guide

Keep it concise and versioned:

• purpose and out-of-scope uses;
• approved inputs and prohibited data;
• step-by-step operating method;
• human approval rule;
• known limitations and exceptions;
• test cases and expected results;
• access owner and change log;
• fallback and incident route;
• review date.

Re-run the baseline

Use comparable cases and report the distribution, not only a preferred example. Separate:

• measured change;
• estimated future potential;
• cost or benefit assumptions;
• effects not yet observed.

If you monetise time, disclose the internal hourly value and whether released capacity actually becomes available for other work.

Make the day-90 decision

Scale when the workflow passes its tests, the owner can operate it, controls are proportionate, and the economics still work with maintenance included.

Revise when the use case remains useful but a specific data, quality or integration issue is solvable.

Stop when performance is unreliable, total effort does not improve, the required data is inappropriate, ownership is absent or the risk cannot be controlled economically.

The output should name the next decision date. “Roll out AI” is not a next step.

A realistic example: enquiry triage for a small service firm

Imagine a company receives 80 mixed enquiries each week. Staff copy details into a CRM, identify the service, draft a reply and assign an owner. The temptation is to automate the whole sequence.

A safer 90-day approach is narrower.

Days 1–30

The team maps five enquiry types, finds that missing information causes most delay, and establishes a baseline. It approves a test set with personal details removed. The first use case becomes: classify the enquiry and prepare a structured internal summary with missing fields highlighted.

Days 31–60

The system works on draft copies only. A coordinator checks every summary. The error ledger reveals that multi-service enquiries are misclassified, so the workflow adds a “needs human routing” outcome rather than forcing one category.

Days 61–90

Two staff members operate the workflow from the guide. The team compares complete handling time, correction and routing errors. Only if those measures improve does it consider writing the approved summary into the CRM. Customer replies remain a separate decision.

The value of the strategy is not that it predicted a perfect system. It made the next risk visible before integration multiplied it.

What AI strategy consulting should—and should not—include

Useful consulting work

• challenging vague goals;
• observing the real process;
• creating a prioritisation method;
• exposing data, risk and ownership gaps;
• designing representative tests;
• helping the team run a bounded pilot;
• documenting evidence and decisions;
• transferring operation to an internal owner.

Warning signs

• a predetermined tool before process discovery;
• a long list of use cases with no prioritisation rule;
• ROI claims with no baseline or assumptions;
• an autonomous “agent” proposed for the first high-impact workflow;
• no named owner, stop condition or fallback;
• strategy ending at a slide presentation;
• proprietary lock-in that prevents your team exporting its prompts, documentation, data or tests.

Our broader guide explains what an AI consultant actually does. Use it to compare strategy, implementation and training scopes before buying all three under one vague label.

The 2026 shift: from isolated chats to connected systems

The important current trend is not another model leaderboard. AI is increasingly embedded in office, CRM, service and development tools. The UK Business Data Survey 2026 found that only a minority of AI-using respondents reported integration with existing systems, with integration more common in larger businesses.

That creates a strategy boundary:

• isolated assistance mainly raises output-quality and data-input questions;
• connected retrieval adds permissions, source freshness and access control;
• system actions add approval, logging, rollback and incident handling;
• agentic chains add dependency and compounding-error risk.

Move right only when the evidence and controls justify it. More connection is not automatically more value.

A one-page 90-day AI strategy brief

Complete this before commissioning a large engagement:

Business constraint:
Current workflow owner:
Trigger, input and output:
Baseline volume, time and error types:
Candidate AI role:
Explicitly out of scope:
Approved and prohibited data:
Representative test cases:
Acceptance criteria:
Human approval point:
Manual fallback:
Pilot budget and internal time:
Day-30 deliverable:
Day-60 decision gate:
Day-90 scale / revise / stop rule:
Owner after handover:

If several lines are blank, that is useful. It tells you what the first consultation should resolve.

The practical next step

Choose one workflow and run the interactive score above. Then speak with the person who performs it and test whether your scores survive contact with real cases.

If the problem remains unclear, a focused diagnostic is the right purchase. If the workflow is clear but capability is missing, training may be enough. If data, integration and controlled deployment are central, scope implementation and assurance explicitly.

For help building the roadmap around a real process, see AI consulting in London. If your immediate need is to improve internal capability before choosing a build, explore AI training for business.