Your team has access to an AI tool. The launch session went well. A few people use it regularly, but others tried it once or never started. Another reminder to “make the most of AI” is easy to send. Deciding what would actually help takes a closer look at the work.
Start with the last task the tool was meant to help someone complete. Check whether they could use it, knew what was allowed, had a useful opportunity and could produce work worth keeping. Low use can point to a fixable barrier. It can also reflect a sensible choice to use an established method.
The aim is to choose a useful change for a specific task. Here is a practical way to investigate before you schedule more training or ask everyone to use AI more often.
Ask about the last real task
“Why aren’t you using AI?” asks someone to defend a behavior. A more useful opening is: “Talk me through the last time you did the task we expected this tool to help with.”
Choose a task with a recognizable finished output: an internal handover, a meeting summary or the first draft of a routine update. Ask someone who uses the tool and someone who stopped or never started to walk through recent examples. Their accounts can reveal different problems; they do not represent the whole workforce.
Work through these questions:
- What needed to be finished? Establish who would use the output and what would make it acceptable.
- Did a suitable opportunity actually occur? Someone doing different work that week may have had no reason to open the tool.
- What happened when you considered using it? Ask about access, approved inputs, instructions, interruptions and the point where they chose another method.
- What happened after the first output? Include checking, corrections, copying information into the working system and getting approval.
- What would have made this task easier? Ask what they would keep about the current method as well as what they would change.
If it is appropriate to show the work, walk through an approved example together. Explain what you are trying to learn and record only the details needed to investigate. Use an example with sensitive details removed when the original contains information that should not be shared.
Also ask what happens when someone tells their manager that AI did not help. Make room for that answer before treating an enthusiastic demonstration as evidence of a successful rollout.
Separate the symptom from its possible cause
First, confirm that your usage report covers the approved tool and the period you are discussing; a missing event is not enough to conclude that someone did not use it. Then use the following table to turn the employee’s account into something you can check. Several explanations may apply to the same task.
| What you hear or observe | What to check next | A possible next action |
|---|---|---|
| “I can’t use the version from the training.” | Confirm the account, permission and actual error. | Have the access owner fix the specific problem, then retry the task. |
| “I don’t know whether this information is allowed.” | Identify the unanswered question about the tool, task or input. | Get a clear answer from the responsible policy or data owner before proceeding. |
| “The examples didn’t look like my work.” | Look at one attempted task and where the person needed help. | Work through an approved example together, with time to practice and someone available for follow-up. |
| “It gives me a draft, but fixing it takes too much work.” | Compare the output with the source material and the team’s acceptance standard. | Try a narrower task or better inputs; retain the existing method if it remains more useful. |
| “I have to do everything twice.” | Trace preparation, review and the final handoff into the working system. | Remove a specific unnecessary step, if possible, and check the whole task again. |
| “That kind of task hasn’t come up.” | Check the actual work in the period you measured. | Wait for a relevant opportunity or reconsider which roles need the tool. |
These checks are a starting point for investigation, not a way to classify employees.
Research provides reasons to look beyond a single “resistance to change” explanation. In the UK Department for Work and Pensions’ Copilot evaluation, interviews described a desire for short, role-specific training alongside differences in task fit, trust and information sensitivity. The evaluation concerned a particular government deployment; its qualitative findings illustrate possible barriers rather than their frequency across workplaces. DWP evaluation, January 2026.
The Department for Business and Trade’s earlier pilot also recorded tasks where inadequate output or additional work added time. That makes the work after generation worth examining. The pilot relied heavily on self-reported experience and had no measurements from before the pilot, so these observations do not establish that AI generally makes employees slower. DBT evaluation, August 2025.
An example: three people, three different next steps
Consider a fictional IT service team using an approved AI tool to draft internal shift handovers. A useful handover must accurately state the issue, completed work, unresolved questions and next action. A person checks it against the service record before another shift relies on it.
The manager notices that three team members rarely use the tool. Conversations about their last handovers reveal different explanations:
Maya could not open the approved tool. Her account still showed a permission error. The access owner agrees to fix it before Maya’s next shift, when they will check it together. Another introductory workshop would leave the immediate problem in place.
Jordan tried it, then stopped. The draft included unnecessary background and missed the next action. First, the manager checks whether the service record itself contained that action. If it was missing there, improving the prompt would not supply reliable information. In this fictional case, the action is present, but Jordan’s request only says to summarize the record. The training had shown email rewriting, with no handover example. The manager works through an approved example with the required fields. At Jordan’s next shift handover, a colleague will check the result against the service record. This may help; an adequate input and clearer instructions still cannot guarantee a useful output.
Sam’s recent handovers were already straightforward. The service record contained the required details in a short template. Moving them into the AI tool, then checking the paraphrase, added steps without solving a problem. The manager keeps the template for that work. They will revisit the choice if a more complex handover reveals a problem the template cannot handle.
The same low-use signal led to an access repair, a targeted learning exercise and no change to an effective method. It would have been a mistake to assign the same remedy to all three people.
Test one change and keep a short record
Choose a barrier supported by the example you observed. Name the person responsible for addressing it, and agree when you will revisit the task. For recurring work, use its next normal cycle. For occasional work, choose a check date without treating the absence of a suitable task as failure.
Copy this record into your team’s usual notes:
Task and acceptable output:
What we observed:
Employee’s explanation and another possible explanation:
One change to try, and its owner:
Next task or review date:
What happened—including corrections, abandoned attempts and the method used instead:
Decision: keep, adjust, try a different task or stop using AI for this task:
When you return to the example, check whether the original barrier changed and whether the task became easier to complete to the required standard. Keep the unsuccessful attempts in the record. A person opening the tool more often does not answer either question.
A small before-and-after check can help you decide what to try next. Differences in task difficulty, experience or available time may also explain the result, so use it as local learning rather than proof of a wider productivity gain.
Leave room for a reasonable “no”
Some work may not need AI. An OECD survey found that non-using small and medium-sized businesses cited unsuitable work, skills gaps and output quality among their reasons. Those were company-level responses, often from owners or managers; they cannot tell you why a particular employee is not using a tool. They do reinforce the need to investigate several explanations. OECD, Generative AI and the SME Workforce, November 2025.
If the input is not permitted, pause that use. If the output still fails the required standard, narrow the task or keep the established method. If there was no suitable work, revisit the expectation before asking for more activity.
Bring one real example to the next rollout discussion. Leave with an observed barrier, an owner and a specific next check—or a documented reason to keep doing that task the way the team already does it.