You've bought the AI tool, so why are only eleven people using it? Because adoption isn't the problem. Your data, workflows and processes are.
You've bought the AI tool. The licence is signed, the vendor's done their onboarding session, and someone in IT has made sure it integrates with your SSO. So why, three months later, are only eleven people using it - and eight of them are in the team that selected it?
I keep seeing this. A firm invests serious money in an AI capability - document automation, client communication triage, knowledge management, whatever - and then frames the entire post-purchase challenge as "adoption." As if the problem is that people just need to start logging in more. We've given them the tool. Now we just need people to use it.
That framing misses the actual problem. The tool isn't the hard part. The hard part is everything around it: the data it depends on, the workflows it needs to slot into, the processes that were designed fifteen years ago for a completely different way of working. I've seen firms spend £150k on an AI platform and then discover that the data feeding it is scattered across four systems, two of which haven't been properly maintained since someone left in 2021. That's not an adoption problem. That's a foundations problem.
I'll say it plainly: AI adoption depends more on your existing tools, processes, and data infrastructure than on the AI technology itself. Firms that skip the operational groundwork waste their investment. Every time.
It's a bit like buying a sports car and then discovering your driveway is a dirt track. The car's fine. The car was always fine. The problem is everything between the car and where you actually need to go.
Here's what tends to happen. A senior partner or CTO identifies an AI use case - let's say automated first-draft generation for proposals. The business case is solid: your consultants spend twelve hours a week on proposals, AI could cut that by 60%, everyone wins. The vendor demo looks brilliant. Green light.
Then reality hits.
The proposal templates live in three different SharePoint sites. Half of them are Word documents with tracked changes from 2019 that nobody cleaned up. The CRM has client data, but the fields are inconsistently populated because nobody enforced data hygiene when it was rolled out four years ago. The AI tool needs structured inputs - clean data, consistent formatting, clear taxonomy - and what it gets instead is a decade of accumulated organisational mess.
I was working with a professional services firm last year - management consultants, about 300 people, good reputation in their sector - that had invested in an AI-powered knowledge management system. Genuinely good technology. But when we looked at the content it was supposed to index and surface, roughly 40% of it was duplicated, outdated, or filed under categories that no longer matched how the firm actually described its services. I remember pulling up the analysis in a meeting with their CTO and watching his face. He'd been the one who'd championed the investment internally. He didn't say anything for a moment. Then: "So we've built a very expensive way to find the wrong answer faster."
The AI was faithfully indexing rubbish. Garbage in, garbage out - except now the garbage was being served up with a nice interface and a confidence score.
Before you spend a penny on AI tooling, three foundations need to be genuinely solid. Not "we're working on it" solid. Actually solid.
Data quality. Not "we have data" but "our data is clean, consistent, current, and accessible." Poor data quality costs organisations an average of $15m annually, according to Gartner - and that's before you add AI into the mix. AI amplifies the problem, because it makes decisions based on whatever you feed it. If your CRM is full of stale contacts and your document management system has three versions of every template, the AI will dutifully work with all of it and produce something that looks polished but is fundamentally unreliable.
Workflow integration. The AI tool has to fit into how people actually work, not how the process diagram says they work. There's usually a gap. A significant one. If your consultants currently draft proposals in Word, email them to a partner for review, get comments back in a different Word doc, and then manually update the CRM - your AI tool needs to meet them somewhere in that flow, not require them to learn an entirely new process on top of everything else. The firms that get this right map the actual workflow first, warts and all, and then figure out where AI adds value within it. The ones that get it wrong hand people a new login and a training video and wonder why nothing changes.
Decision rights. This one gets overlooked constantly, and it drives me mad. When the AI produces an output - a draft proposal, a risk assessment, a client communication - who's responsible for it? Who reviews it? Who approves it? Who's accountable if it's wrong? If you haven't answered these questions before launch, you'll find that people either ignore the AI output entirely (because they don't trust it and nobody told them they should) or they rubber-stamp everything it produces (because they assume someone else is checking). In regulated environments - financial services, legal - this isn't just an operational question. It's a compliance one.
I had a conversation recently with a COO at a mid-market consulting firm who told me - somewhat sheepishly - that his firm was running fourteen different SaaS tools across the business, and nobody had a complete list. Fourteen. Some overlapping, some barely used, a couple purchased by people who'd since left. He said it like he was confessing something. I told him I'd heard worse, which was true, but fourteen is still a lot.
The reason it matters is that AI doesn't operate in isolation. It needs to connect to your existing tools - your CRM, your document management system, your project management platform, your communication tools. If those systems are fragmented, poorly integrated, or running on legacy architectures that don't support modern APIs, your AI tool is going to struggle regardless of how sophisticated it is.
A few questions worth asking honestly:
Can your current CRM actually expose the data the AI needs, in the format it needs it? Or will you need someone to manually export CSVs every week? (I've seen this. It's depressing. Someone's entire job becomes "the person who does the CSV export on Tuesdays.")
Does your document management system have a consistent taxonomy, or has everyone been filing things their own way for years? Because AI needs structure. It cannot infer meaning from a folder called "Misc - Dave's stuff 2022."
Are your communication tools - email, Teams, Slack, whatever you use - set up in a way that allows the AI to access relevant conversation history? Or is everything locked in individual inboxes, which is to say, effectively inaccessible?
The honest answer, for most mid-market firms, is that the existing tool landscape is a bit of a mess. Not catastrophically broken - things work, more or less - but held together with workarounds and institutional knowledge. That's fine for human operators who know the shortcuts. It's not fine for AI, which needs clean inputs and structured pathways.
This is where assessment work matters. Before you bolt an AI capability onto a fragmented stack, you need to understand what you've actually got. We've built an AI readiness checklist for mid-market service firms that covers exactly this ground - it's worth working through before you commit to a platform.
Right, here's where I get a bit preachy. Sorry in advance.
The single biggest mistake I see firms make with AI implementation is treating adoption as a phase that comes after the technology goes live. As if you build the thing, launch it, send round an email, maybe do a couple of lunch-and-learn sessions, and then wait for the usage numbers to climb.
That doesn't work. It has never worked. It didn't work when firms rolled out CRM systems ten years ago, and it won't work with AI now.
Adoption has to be designed into the implementation from day one. Which means a few things.
Change management from the start - not as an afterthought, not as a line item in the project plan that says "change management - TBC." Actual, structured change management that identifies who's affected, what's changing for them, what their concerns are likely to be, and how you're going to address those concerns before they harden into resistance. I've seen firms where the first time end users heard about the AI tool was the week it launched. Unsurprisingly, they were not thrilled. Nobody asked us. That's a direct quote, from a senior associate at a law firm, said to me in a corridor about an AI tool their IT team had spent eight months building. Eight months. Nobody asked.
Training that's ongoing, not one-off. A single training session is basically useless. People forget 70% of what they learn within 24 hours - that's Ebbinghaus's forgetting curve, and it's been replicated enough times that we should probably stop pretending a two-hour workshop is sufficient. What works is structured, repeated exposure: short sessions, spaced over weeks, with real examples drawn from the team's actual work. And the training needs to evolve as the tool evolves and as people's confidence grows.
Then there's the feedback loop question, which is where most implementations quietly fall apart. If someone uses the AI tool and finds that it produces unreliable output, or that it takes longer than the manual process, or that it doesn't integrate properly with their workflow - that feedback needs to go somewhere. And something needs to happen as a result.
I worked with a firm where the AI tool's output quality was genuinely poor for the first month - not because the technology was bad, but because the training data hadn't been properly curated. The users flagged it repeatedly. The project team's initial response, if I'm being honest, was a bit defensive - there was a conversation where the project lead suggested the users "weren't using it correctly." That went down about as well as you'd expect. Eventually, they accepted the feedback, fixed the training data, and re-ran the outputs. Within two weeks the quality was dramatically better. But the thing that actually turned adoption around wasn't the quality improvement. It was that they went back to the users who'd flagged the problems and said: "You were right, here's what we changed, here's the result." That single act did more for adoption than any training session. People will tolerate a tool that has problems. They won't tolerate feeling ignored.
We've got 200 licences and 180 people have logged in. Adoption is at 90%.
No. Logging in is not adoption. Logging in is the bare minimum evidence that someone remembers the tool exists.
Real adoption measurement needs to answer a different question: is the tool improving outcomes? And that means you need to know what the outcomes were before the tool was introduced - which means you need a baseline - which means you need to have thought about this before you launched.
Process efficiency is the obvious one. Has the time to complete the target task actually decreased? Not in theory - in practice. If proposals were taking twelve hours and you expected AI to cut that to five, are they actually taking five? Or are they taking ten because people are spending five hours on the AI tool and then five hours reworking the output? I've seen the latter more than I'd like.
Output quality matters too, and it requires qualitative assessment, not just metrics. Get partners or senior staff to blind-review AI-assisted proposals against manually produced ones. If the quality isn't there, you've got a training data problem or a workflow design problem, not an adoption problem. Don't let anyone tell you otherwise.
User behaviour beyond login tells you things surveys never will. How frequently are people using the tool? Are they using it for the intended use case or something else entirely? Are certain teams adopting faster than others, and if so, why? One firm I worked with found that their finance team had essentially repurposed an AI writing tool into a data summarisation tool - not what it was designed for, but genuinely useful to them. That's worth knowing. It might even be worth building on.
And then there's the board question: has the AI investment actually moved a number that matters? More proposals out the door. Faster turnaround. Higher win rates. Fewer errors in client communications. Whatever the original business case said the AI would improve - is it improving it? If you can't answer that, you're not measuring adoption. You're measuring logins.
Look, I realise this piece might feel like a cold shower if you're midway through an AI rollout. That's not the intent. The technology is genuinely powerful - we're seeing firms achieve remarkable things when the foundations are right. A 60% reduction in proposal turnaround time. Twelve hours of senior consultant time saved per week. These aren't theoretical numbers.
But every one of those successes had something in common: the firm invested as much energy in the operational foundations as they did in the technology selection. They cleaned up their data. They mapped their workflows. They designed adoption into the implementation. They measured outcomes, not logins.
If you're planning an AI initiative - or trying to rescue one that's underperforming - start with the foundations rather than the features. There's a companion piece on measuring cultural attitudes toward AI that covers the people side of this equation, because tools and processes are only half the story. Culture is the other half, and honestly, it might be the harder half.
And if you're assessing whether your organisation is ready for AI, the checklist I mentioned earlier covers all the foundations - from data quality to governance to workflow integration. It's a more useful starting point than any vendor demo. Because the worst possible outcome isn't that AI fails. It's that AI succeeds in a demo and then quietly dies in production, and everyone concludes that "AI doesn't work for a firm like ours." It does. It just needs something to land on.
