Your Team Has AI Access and Still Uses It as a Chatbot

We keep meeting leaders who bought AI licences for the whole team, watched the login numbers climb, and then noticed nothing about how the work actually gets done has changed. People open the tool, ask it something, copy the answer into an email, and close it again. Nobody would call that a failed rollout. Nobody would call it a success either.

The confusion comes from measuring the wrong thing. A licence proves someone can reach the tool. It says nothing about whether any workflow behind that login is different from the one that ran before the tool arrived. Access is not adoption: adoption is a workflow that used to require a person doing it manually and now doesn't, done the same way every time it recurs. Everything else is a chatbot with a subscription attached.

Why does using AI as a chatbot feel like adoption?

Because it produces visible activity. Someone types a question, gets an answer, and moves on. Multiply that by forty people and a leadership team sees usage graphs going up and reasonably assumes the investment is paying off. What the graph can't show is whether any of those sessions touched the company's own data, whether any of them ran the same way twice, or whether any task was actually handed over rather than merely assisted once.

The uses that change a workflow look different from occasional Q&A. They read from a live system rather than from what the person typed in. They follow a written procedure rather than a fresh explanation each time. They produce an output that goes somewhere (a CRM record, a draft that gets sent, a report that gets filed) rather than a paragraph that gets read and discarded. And critically, they get delegated: a task moves from "I do this and sometimes ask the tool for help" to "the tool does this and I check the result." Most teams with AI access have never crossed that line. They've added a faster way to search, not a different way to work.

What's the tell that adoption has stalled?

Watch for someone typing the same correction into the same tool, week after week. A standing instruction to exclude a particular client from a summary. A reminder that the company always quotes ex-VAT. A note that a certain supplier's invoices need a different format. If a person is retyping that correction every time rather than saving it as a standing instruction the tool will apply automatically, the work hasn't moved past occasional Q&A, whatever the licence dashboard says.

The sharper version of this problem shows up when that person is away. A colleague covers the task, doesn't know the correction exists because it only ever lived in one person's head and one week's chat history, and the output goes out wrong. This is not a personality quirk or a minor inefficiency. Working knowledge that exists only in one person's private conversation with a tool is a fragility in the business, in the same way an undocumented spreadsheet macro or a password only one person knows is a fragility. It doesn't show up as a cost until the day the one person who holds it isn't there, and then it shows up as an error that ships to a customer.

Does one champion per team beat a training rollout?

We've watched both approaches play out across enough client rollouts to have a clear view. Handing out licences and a training video gets everyone to the same starting line and then leaves each person to work out the rest alone, at whatever pace their curiosity and spare time allow. Most people, reasonably, treat that as low priority next to their actual job, and the tool settles into occasional use.

The approach that actually shifts a team's workflows is different: one person per team spends real time building working patterns for the tasks that team repeats most, then packages those patterns (standing instructions, connected data, the step-by-step procedure) so the rest of the team can pick them up rather than reinvent them. That person becomes the one who knows why an instruction exists and what happens if you remove it. Structured training gets that person there faster and gives everyone else a shared vocabulary once the patterns are ready to hand over, which is the approach we set out in how to get a team properly fluent in Claude and in what we mean by a team being genuinely competent with AI rather than merely having accounts. A licence drop skips the champion step and asks forty people to each discover the same handful of useful patterns alone. Most won't.

Should everyone configure AI their own way?

Once a team has a champion and some working patterns, the next decision is whether those patterns are shared or personal. Forty people each building their own instructions, their own connected data, their own version of "the way we do this" produces forty slightly different answers to the same question, none of which anyone else can audit, debug or improve. When something goes wrong, nobody can say which configuration produced it, because there isn't one configuration, there are forty.

A team working from one agreed baseline is the opposite: everyone runs the same standing instructions, the same connections, the same procedure for the same recurring task. That baseline can be reviewed, fixed when it's wrong and improved when someone finds a better way, and the improvement reaches everyone at once rather than living in one person's setup until they happen to mention it. This is a governance decision as much as a technical one, and it only works if someone owns the baseline and updates it deliberately rather than letting each person's private drift stand in for a policy.

Why does adding more instructions make things worse?

The instinct once a team has a shared baseline is to keep adding to it. Someone hits an edge case, so a rule gets added. Someone else hits a different edge case, so another rule gets added. Six months later the standing instructions are three pages long, and the one rule that actually matters for most tasks is buried in the middle of a list nobody reads properly any more.

Standing instructions should stay short enough that a person can hold the whole set in mind. An instruction nobody reads is not being followed, it just hasn't failed yet. Situational detail (the format a specific client needs, an exception that applies once a quarter) belongs in an on-demand procedure pulled up when that situation actually arises, not in the always-on list. Keep the standing instructions to what applies every time, and push the rest out to something retrieved on demand.

What does judgment erosion actually cost?

One of the most expensive failure modes in AI adoption isn't a wrong answer, it's a person shipping an AI-produced answer they can't explain. Nobody notices for a while, because the output looks fine and mostly is fine. It surfaces the day someone above them asks why a figure is what it is, or a client queries a line in a proposal, and the person who sent it can't say, because they didn't actually check it, they trusted it.

That's a judgment problem, not a tooling problem, and it's exactly the gap we set out in which decisions should actually be left to AI: some decisions are fine to delegate and review only occasionally, and some need a person who can answer for the outcome, and the two get treated identically once a team has stopped thinking about the difference. A workflow that has genuinely changed still has a named person who can explain any output it produces. One that's just running faster because someone pastes answers out of a chat window usually doesn't.

How do you actually measure adoption?

Not by login counts, and not by the number of prompts sent in a week. Count workflows: how many recurring tasks now run on a standing instruction, connected to real data, checked rather than performed by a person? A team that has changed three workflows properly, with someone who can explain each one, is further ahead than a team where forty people log in daily and use the tool as a chatbot every single time.

That's the number worth reporting to leadership, and it's usually smaller and more honest than the usage dashboard suggests. It also tells you where the next investment should go: not more licences, the next workflow worth converting.

This is the gap our AI Accelerator programme is built to close: a structured, quarter-by-quarter path from licences that get occasional Q&A use to workflows that have actually changed, with a champion, a shared baseline and a way of measuring the difference.

Frequently asked questions

How many people need to actually use AI daily before we can call the rollout a success?

The headcount using the tool daily is the wrong measure. A rollout has succeeded when specific recurring workflows have moved from a person doing the task manually to a person checking an AI-produced result against a standing procedure, whether that's true for three workflows or thirty. Counting daily logins tells you about habit, not about whether any task changed hands.

We trained everyone on the same day. Why hasn't usage changed?

A single training session gets everyone to a shared starting point but doesn't build the working patterns a team needs for its own recurring tasks, and most people won't build those patterns alone once they're back at their desks with a full workload. A rollout that puts one person per team in charge of developing and packaging those patterns for a specific set of repeated tasks tends to produce far more change than a training day followed by a licence and good intentions.

Is it a problem if everyone on the team sets AI up slightly differently?

Yes, because a team working from forty personal configurations can't be audited or supported as a group. When an error appears, nobody can say which setup produced it, and a fix found by one person doesn't reach anyone else unless they happen to mention it. A shared baseline that the whole team runs, reviewed and improved deliberately, is what makes the tool's use manageable at scale.

How do we know if our standing instructions have grown too long?

If nobody on the team could recite the standing instructions from memory, they're too long, and the one rule that actually matters most of the time is at risk of being buried under exceptions. Keep the always-on instructions to what applies in nearly every case, and move situational detail into a procedure that gets pulled up only when that specific situation arises.

John Kelleher is a Claude Certified Architect (Foundations and Professional) and leads SpotDev, a Claude Registered Partner and OpenAI Select Partner.