Eighteen Months of "We Should Use AI"

A Birmingham engineering consultancy decided in January that it should "do something with AI." The founding partners had read about it. Clients were asking about it. Competitors were mentioning it on their websites (though, on closer inspection, the competitors' AI initiatives appeared to consist primarily of having mentioned AI on their websites).

By March, they'd formed a working group. Four people: one partner, one senior engineer, the IT manager, and an operations lead. The working group met fortnightly. They discussed: what AI could do for the firm, which departments would benefit most, what the risks were, whether the data was ready, and whether they needed a consultant to help them decide whether they needed a consultant.

By June, they had a vendor shortlist. Three companies. Two had presented 40-plus slide decks. One had used the word "transformation" 14 times in a 45-minute presentation (I counted, because counting the number of times a vendor uses "transformation" in a pitch is a more reliable evaluation method than reading their case studies, which invariably describe a company that was already doing well and continued to do well after the vendor's involvement, which is, when you think about it, not evidence of anything in particular).

By September, they had a proposal from the preferred vendor. £35,000 for a "discovery and roadmap phase." Three months. The deliverable: a document recommending what to build.

By November, nobody had signed the proposal. The working group was still meeting fortnightly. The agenda had evolved from "what should we do with AI?" to "should we sign this proposal?" to "maybe we should get another quote." Eleven months. Four people. Twenty-two meetings. Zero agents. Zero automation. Zero processes improved.

Meanwhile, the queue outside Graham's office continued. Every Monday morning. Six questions answered from 34 years of experience. Each answer unrecorded. Each answer repeated the following week.

The firm didn't have an AI problem. It had a decision problem. And the decision problem was caused by the same AI industry that was supposed to solve it.

Three structural reasons. None involve the SMB being slow, cautious, or technologically backward. All involve the AI industry making the first step unnecessarily large.

The scope is wrong. "We should use AI" is not a project brief. It's a sentiment. The working group's mandate was "explore how AI could benefit the firm." This is the sort of brief that produces exploration, not results. The exploration expands to fill the time allocated to it. Every meeting surfaces another potential use case. Every vendor presentation adds another possibility. The scope gets broader. The decision gets harder. The gap stays open.

The firms that actually built something didn't start with "explore AI." They started with: "Graham spends 12 hours a week answering questions. Can a system answer them instead?" One process. One bottleneck. One question with a measurable answer.

The evaluation is too complex. Three vendors. Three proposals. Each with different pricing structures (fixed fee, monthly retainer, outcome-based, a creative combination involving a deposit and a success fee and a monthly hosting charge that turns out, on closer reading, to be the majority of the cost). Each with different scope definitions. Each using different terminology for the same things.

The working group builds a comparison spreadsheet. Twelve columns. Three rows. The spreadsheet is never completed because nobody can agree on the column weightings, and two of the three vendors have scoped fundamentally different things, making the comparison structurally invalid regardless of what weights you assign.

The evaluation framework designed to reduce risk actually increases paralysis. The SMB ends up with more information and less clarity. Which is precisely what happens when you apply enterprise procurement methodology to a £200-per-month agent.

The first step is too big. "Build a proof of concept" sounds like a modest starting point. It isn't. A proof of concept in the vendor's proposal is a three-month project with workshops, stakeholder interviews, data readiness assessments, architecture planning, and a deliverable that is, functionally, a document describing what could be built. Not the thing itself. A description of the thing.

The Birmingham firm's actual first step (when it finally happened) was a 30-minute conversation between Graham and an AI agent about how he handles soil bearing capacity assessments on variable ground sites. The conversation was captured, structured, and searchable by the following afternoon. No workshops. No stakeholder interviews. No data readiness assessment. A conversation, a knowledge article, and a junior engineer who got Graham's answer from a Teams bot the next morning instead of waiting in the queue.

Total elapsed time from "let's try this" to "a junior engineer used it for a real question": four days.

The eleven months of committee meetings produced zero value. The four days produced a working system that answered a real question. The gap between those two approaches is the gap the AI industry profits from keeping open.

The £35,000 discovery phase exists because the vendor's business model requires it. Building a £200-per-month agent for one process is not commercially viable for an agency that employs 15 people and has office space in Shoreditch. The minimum viable project size for a consulting-model AI vendor is £25,000-£50,000. Below that threshold, the project doesn't cover their overhead.

This creates a structural misalignment. The SMB's actual need (fix one specific bottleneck, spend £200 per month) doesn't match the vendor's minimum viable engagement (three-month discovery, £35,000 starting investment). The vendor's solution: make the scope bigger. "You don't just need to fix the knowledge capture problem. You need a comprehensive AI strategy. A data governance framework. A change management plan. A roadmap."

The roadmap is where SMB AI projects go to die. Not because roadmaps are inherently useless. Because a roadmap is a document about what could happen, and what happens after a roadmap is usually: the roadmap gets filed, the working group reconvenes to discuss implementation, implementation requires a second proposal, the second proposal triggers a second evaluation, and the cycle begins again.

The firms in this Blueprint series that actually automated something didn't produce a roadmap first. They identified a specific process, designed an agent, tested it, and expanded from results. The roadmap, if one existed, was written retroactively to describe what had already worked. Which is the correct order: evidence first, strategy document second.

Across 46 Blueprints published in this series, the pattern is consistent. The businesses that crossed the gap share four characteristics.

They picked one process. Not "AI strategy." One process. Revenue recognition. Onboarding milestones. Client health scoring. Support sentiment. Knowledge capture. One bottleneck. One fix. The scope small enough to describe in one sentence.

They measured before building. How many hours does this take? What does it cost? How often does it fail? The numbers provided the business case and the success criteria simultaneously. "James spends 1.5 days per month-end" is both the justification and the benchmark. If the agent reduces it to 2 hours, it worked. If it doesn't, it didn't. No ambiguity.

They built something that works before expanding scope. The first agent ran alongside the existing process for 2-4 weeks. Nobody dismantled anything. Nobody committed to transformation. The agent either worked (most did) or it didn't (two of 40-plus didn't, and the businesses paid nothing). Evidence first. Expansion second.

They spent £140-£280 per month, not £35,000 upfront. The agent running costs across the series: Karen's engagement letters at £160. James's revenue recognition at £220. Sophie's churn warning at £280. Alison's sentiment tracker at roughly £50. Graham's knowledge capture at roughly £50-£130. Monthly running costs that are recoverable in the first month from the time they save. The financial risk is a rounding error. The committee spent more on the meeting room coffee over eleven months than the agent costs to run for a year.

The AdAI 3-Touch Test was designed for exactly this moment. Not as a sales qualification tool. As a decision filter that cuts through the evaluation paralysis.

Touch 1: Which single workflow loses you money or time every week? If you can name it in one sentence, you've passed. If you can't, the scope is too broad. Narrow until you can.

Touch 2: Which tool already in your stack can do 70% of fixing it? Graham's firm already had Teams, SharePoint, and Deltek. The agent connected them. Tom already had the WMS, TMS, Sage, and Salesforce. The agent aggregated them. You almost certainly have the tools. You lack the connection between them.

Touch 3: Who on your team owns the after? Someone needs to review the flagged items, act on the alerts, and maintain the system. If that person exists (and they usually do, because they're currently doing the manual version of the work), the adoption risk is low.

Three touches. Three answers. If all three are clear, the next step is building, not evaluating. Not committee-forming. Not vendor-shortlisting. Building.

The gap between "we should use AI" and "we have an agent in production" is not 18 months. It's the time between answering the three questions and starting the first build. For most of the businesses in this series, that was two to four weeks. The eleven months before that was the committee. The committee was the gap.

Every Blueprint at adai.news is designed to close the gap. The architecture, the build guide, the cost breakdown, the failure modes. Free to read. Free to build from. No vendor deck. No committee required.

Subscribe to AdAI News. New blueprint every Thursday.

by SP, CEO - Connect on LinkedIn
for the AdAI Ed. Team