It is one of the most frequent conversations I have at the moment. A company has rolled out Microsoft Copilot, sometimes to several hundred people. The rollout was clean, the training sessions were well attended. Six months later a small group uses the tool regularly and everyone else does not.
The first instinct is usually to run more training. That rarely helps, because the problem sits somewhere else.
People adopt tools for situations, not for features
People adopt a tool when it noticeably helps in a recurring situation in their working day. Training that demonstrates features produces admiration. It does not produce habit. That difference decides the usage numbers.
What works is the reverse approach. Take one concrete, frequent task a team performs — preparing the weekly report, summarising customer calls, drafting the first version of a proposal section — and work through that single task together until it runs faster and better than before. Then take the second task.
Adoption does not happen when people understand a tool. It happens when people recognise their own work inside it.
The quiet blockers
Beyond the missing link to real situations, three blockers rarely get stated openly. First, uncertainty about whether use is permitted: where governance stays vague, careful people decide against it. Second, the worry that visible efficiency gains put their own role in question. Third, data quality: where permissions and file structures are messy, the assistant returns weak results and loses users' trust after a few attempts.
All three are addressable. None of them is addressed by another training session.
How I measure progress
Usage statistics alone say little. More telling is whether teams start proposing new use cases themselves, whether usage stays stable after the launch period, and whether leaders visibly use the tool themselves. The last point carries more weight than any communication campaign.
If leadership does not use a tool, the organisation reads the message accurately. The reverse is equally true.