Why your team isn't using the AI you bought

You paid for licences for an AI tool. There was a demo, an announcement email and a few weeks of curiosity. Today two people use it, and one of them is you. The decision in front of you is not whether to buy a different tool or write off the investment: it is deciding whether the problem lies in the product or in how it landed in the team. It is almost always the latter, and the latter can be fixed.

The comfortable explanation and the uncomfortable one

When a tool goes unused, two explanations are on offer. The comfortable one comes in two flavours: "the tool isn't as good as they claimed" or "my team resists change". Both point outwards, and both let you close the matter without learning anything.

The uncomfortable one is that the tool arrived without an answer to the only question each person on the team actually cares about: does this help with my Tuesday task, specifically? A demo shows what the tool does in general. But nobody works "in general": people answer specific complaints, reconcile specific orders, draft specific quotes. Someone has to walk the distance between the demo and Tuesday morning, and in most companies nobody has.

What actually holds a team back

Underneath "they just don't use it" there are usually three brakes that almost never get said out loud.

Fear. Of getting it wrong in front of colleagues, with a technology nobody has mastered. Of using it being seen as cheating. And the serious one: that if the machine does part of my job, someone will conclude I'm surplus. That last fear does not dissolve with an enthusiastic demo; it dissolves by being talked about. As long as nobody names it, it works quietly on its own.

No cases of their own. The examples in the presentation — "draft an email", "summarise this text" — look nothing like the tasks of the house. Between "draft an email" and "reply to this customer demanding a credit note, in our tone and under our returns policy" there is translation work that no employee will do alone with a full inbox.

No explicit permission. Nobody has put in writing what the tool may be used for and what it may not. Silence gets interpreted conservatively: better not to touch it, just in case. Individual prudence, multiplied across the whole team, looks like resistance to change. It isn't: it is sensible people protecting themselves from a rule that doesn't exist.

What doesn't work

Some standard responses to low adoption fail to move the needle:

• The leadership email announcing that "from now on we use AI". A mandate without cases, without detailed permission and without time is a sentence, not a plan.
• The generic prompt-writing course with not a single task from your own company in it. The team leaves knowing how to do things it doesn't need to do.
• Measuring adoption by logins. You get people opening the tool, not using it for anything.
• Turning it into blame. A team that feels examined stops telling you what isn't working — which is exactly the information you need.

What does work

What changes adoption is not more enthusiasm; it is more specificity:

• The team's own cases. A working session per area where each person brings a real task and leaves with it either solved with the tool or ruled out with a reason. Ruling out is a result too: it clears the ground and lends credibility to the rest.
• Explicit, short permission. One page: what it may be used for, what it may not, what information must never leave the company, and who to ask when in doubt. Short, so it gets read; written, so nobody has to guess.
• Time. Learning to delegate to a tool is work. If it is expected to happen "on top of everything else", it will lose to the urgent every single week.
• A nearby reference person. Not the boss, not the official enthusiast: someone credible from the team itself who is one step ahead and can be asked questions without anyone feeling assessed.
• Honesty about limits. Say which tasks don't work well yet. One broken promise costs more adoption than ten demos earn.

If this sounds like training, that's because it is — but training that starts from the team's tasks, not from the tool. That is the difference between a course and a change of habit, and it is how we approach AI training.

Five questions before declaring the tool a failure

1. Has anyone translated the tool into the concrete tasks of each role, or was there only a general demo?
2. Is there written permission covering what it may and may not be used for, or does everyone have to guess?
3. Has the team had protected time to try it, or is it competing with the usual urgency?
4. Is there someone nearby people can ask without feeling examined?
5. Has the fear — including the fear of being surplus — been talked about, or is it assumed not to exist?

If several answers are "no", the tool hasn't failed: it hasn't had its chance yet. Giving it that chance is cheaper than buying the next one — and it works on the next one too.