THE SHORT ANSWER
Low use of an AI tool does not automatically indicate low motivation. The tool may not fit the task, may add review effort or may be hard to reach when needed. Useful adoption work investigates friction in the actual workflow. You then decide whether better support, a process change or deliberate non-use makes sense. Usage becomes a signal about workable processes rather than an end in itself.
To connect individual AI applications with reliable marketing operations, read the pillar guide AI transformation in B2B marketing: from individual prompts to reliable operations.
Observe the work moment instead of assuming attitudes
Choose a concrete task and ask users to demonstrate their normal process. When would AI assistance be useful, what information is missing then and where must the result go afterwards? Watch system switches and extra copying. A person can appreciate a tool in principle while avoiding it at the critical moment. Record observed obstacles separately from opinions about AI. A broad enthusiasm survey rarely explains why a useful feature is not used during actual work or which practical change would make that feature more accessible. Explore this further in the guide Running content reviews that produce decisions instead of preferences.
Divide friction into investigable causes
Distinguish access, task fit, source quality, interaction, output review and organisational uncertainty. These categories require different responses. Missing access is not fixed by a better prompt example. An unclear approval route needs ownership rather than more feature training. Ask about the last real attempt and its follow-up work. Record where the user stopped or switched to the manual route. The description should be specific enough to test one change, rather than grouping every difficulty under a broad question about acceptance that offers little guidance for action.
Compare total effort including review
Compare the existing task with the assisted process using similar cases. Include preparation, corrections, clarification and handoff rather than only time to first draft. A quick response can increase total effort when every statement then requires difficult verification. Also ask whether the user receives a more usable result. The appropriate comparison depends on purpose: a research brief needs evidence and coverage, while an internal draft may benefit more from clear structure and workable follow-up than from sheer text volume. Measure the actual task rather than the most convenient tool statistic.
Build trust through visible boundaries
Explain when the tool is useful and when another route is needed. Show sources, open questions and ownership of corrections. A person should be able to reject an uncertain proposal without being treated as an obstructive user. Microsoft’s adoption material combines rollout with practical support and collecting feedback. For your process, the essential consequence is to accept problems reliably and report their handling status back. A reported error repeatedly left unanswered can undermine trust more than a clearly acknowledged limitation on where the tool can currently help.
Follow a hypothetical content team
Imagine editors barely using a briefing agent. Their manager plans another introductory training session. A shared work sample reveals that the output does not fit the established brief template and that sources must be transferred individually. You change the output format and test the same task again. Training would have been necessary only if interaction knowledge were the problem. This example shows why investigation should begin with the work product. The appropriate intervention follows observed friction rather than a premature diagnosis that people are unwilling to adopt AI or lack sufficient enthusiasm.
Test one bounded improvement with users
Select an obstacle, state the expected effect and try the change on representative cases. Include colleagues who have rarely used the tool. Check whether the revised process remains understandable without facilitation. If it works only during the moderated session, everyday usability is still unresolved. Record unwanted effects such as new clarification work or a less visible need for review. An improvement should genuinely make the task easier, rather than briefly increasing a usage measure while shifting effort into another part of the process or onto another member of the team.
Decide on continuation without usage pressure
After testing, identify cases that work better and those that should remain manual. Different tasks may need different answers. Low usage can be appropriate when suitable occasions are rare. Provide support where recurring friction is solvable and the benefit is visible. If the task shows no advantage, allow the tool to leave that workflow. Document the reason and the lesson. Adoption work then helps the team establish a sustainable way of working, rather than merely demonstrate activity against a predetermined rollout target that says little about usefulness or the quality of completed work. Explore this further in the guide AI office hours: learn together through real cases.
INTERACTIVE / FROM READING TO ACTION
Three checkpoints for your implementation
Choose a checkpoint and track your reading progress. Checks are neither saved nor sent and do not score your business.
CHECKPOINT 01
Compare total effort including review
Compare the existing task with the assisted process using similar cases.
Explore in the article ↗CHECKPOINT 02
Build trust through visible boundaries
Explain when the tool is useful and when another route is needed.
Explore in the article ↗CHECKPOINT 03
Follow a hypothetical content team
Imagine editors barely using a briefing agent.
Explore in the article ↗Frequently asked questions
Is low usage a failure?
Not automatically. What matters is whether suitable tasks are handled better. Rare use cases can reasonably produce low usage.
When is training the right response?
When an observed knowledge or interaction gap obstructs work. Source defects and missing ownership require other interventions.
How can trust be assessed?
Through concrete cases: do users understand sources, boundaries and correction routes, and are reported problems handled transparently?
How can I put “Observe the work moment instead of assuming attitudes” into practice?
Choose a concrete task and ask users to demonstrate their normal process. When would AI assistance be useful, what information is missing then and where must the result go afterwards? Watch system switches and extra copying.
What matters when working on “Divide friction into investigable causes”?
Distinguish access, task fit, source quality, interaction, output review and organisational uncertainty. These categories require different responses. Missing access is not fixed by a better prompt example.
