Blog · · 4 min read
Adopting AI in the abstract vs. knowing exactly what it's for
Does your business actually know what you'd use AI for?
Not "we're looking into AI." Not "we should probably do something with AI." A specific answer: this task, done this way, by this team, with this AI tool.
If the honest answer is "not really, we just know we should be doing something," you're not alone. You're also not ready to get much out of it yet.
What it is
An identified AI use case is a specific job inside your business where AI could genuinely help: drafting the first pass of a proposal, summarising long customer emails before replying, checking invoices against purchase orders, answering the same five product questions your support team gets every week.
It's the opposite of "adopting AI" as a general ambition. A use case has an input, an output, and a way to tell if it worked. "We're exploring AI" isn't one of those things. "We want to cut proposal drafting time in half" is.
This matters because AI without a target job to do doesn't actually go anywhere. Someone gets a ChatGPT licence, plays with it for a fortnight, and momentum fades. Not because the tool was wrong, but because nobody pointed it at anything specific.
What happens when it's skipped
The UK government's 2025 AI Adoption Research found that most UK firms hadn't identified a concrete AI use case, even as leadership enthusiasm for AI kept climbing. That gap, board-level ambition running ahead of any actual plan, is exactly how AI adoption stalls. Budget gets approved, a tool gets bought, and six months later nobody can point to what changed.
Inside a business, it usually plays out like this: leadership decides AI is important, someone is told to "look into it," a licence or two gets purchased, and then everyone waits to see what happens. Nothing does. There was never a job the tool was meant to do, so there's nothing to measure and nothing to build on. The initiative quietly dies, and the next time someone suggests AI, they get met with "we tried that already."
The blocker that's easy to miss
Here's the part that often gets skipped: staff don't fear AI itself, they fear what it means for their job. That fear is reasonable. AI has made a lot of things feel unpredictable, and if leadership never says otherwise, staff will quietly assume the worst.
This is exactly why so many use cases never get off the ground. Someone in the team half-notices AI creeping into their role, decides it's safer to slow-walk it or say nothing, and the initiative stalls without anyone ever raising the real objection out loud.
Before you name a single use case, staff need to hear plainly that the business isn't rolling out AI to cut headcount. Say it directly, don't leave it implied. Then go a step further and show people how their own skills carry across. Someone who's good at writing proposals is good at directing and checking an AI draft. Someone who knows the product inside out is the person best placed to judge whether an AI-written answer is actually right. The skill isn't replaced, it moves. Naming that clearly, and showing staff where they'd actually use AI in their own role, is what turns quiet resistance into people willing to try the pilot.
What good looks like
A business with clear use cases can name the two or three jobs AI is actually meant to help with this quarter, who owns each one, and what "working" looks like. The scope is deliberately small. One team, one task, one measurable outcome. Once that's proven, it expands. That's how the wins compound instead of evaporating into a vague sense that "we use AI now."
How not to do it
- Buying the tool before naming the job. A Copilot or ChatGPT Enterprise licence rollout with no brief attached almost always underperforms a much smaller rollout aimed at one specific task.
- Picking a use case because it's impressive, not useful. A flashy AI demo for the board is not the same as a task your team actually does every week. Chase the boring, repetitive job. That's where the time savings are.
- Trying to solve everything at once. "AI across the whole business" isn't a use case, it's a slogan. Pick one process, prove it works, then move to the next.
- No way to tell if it worked. If nobody defined what success looks like before starting, nobody can tell six months later whether the AI use case actually helped or just added another tool to the pile.
- Never addressing job security. Rolling out a use case without ever saying why, and without reassuring staff it's not about reducing the team, leaves people to fill in the blank themselves. They usually fill it with the worst version.
Where to start
Before you name a single use case, tell staff plainly why the business is doing this, and that it's not about cutting people. Then ask each team one question: what's the task you do every week that's repetitive, time consuming, and doesn't need much judgement? That's your shortlist. Pick the one with the clearest before-and-after, give it an owner, and give it a deadline to show results. That's a use case. Everything else is still just an idea.