The full answer
Find out why before pushing harder. Look at the usage data, then talk to the people not using it and watch them work. The usual reasons are that it doesn't fit their workflow, they don't trust its answers, it doesn't save them time, or they fear what it means for their jobs. Fix the specific reason, make the tool part of the normal process, enlist respected users as champions, and show results in their terms.
1. Look at the data
- Who uses it, how often, for what, and where they drop off.
- How often outputs are edited heavily or thrown away.
- Differences between teams: one team using it well is a clue to what works.
2. Talk to non-users
Ask open questions and watch real work. Typical findings:
| Reason | What it sounds like | Fix |
|---|---|---|
| Workflow friction | "It's in another tab; I have to copy everything across" | Put it inside the tool they already use; pre-fill from the case |
| Trust | "It was wrong twice, so I check everything anyway" | Show sources; fix the common errors; let it say "not sure" |
| No time saved | "Editing its draft takes as long as writing" | Narrow it to the cases where it is strong; improve quality there |
| Fear | "Is this replacing us?" | Leadership is clear about the intent; frame it as removing drudgery; involve them in improving it |
| Training | "I didn't know it could do that" | Short, task-based training; tips inside the tool |
3. Make it part of the process
- Build it into the existing system and steps, not a separate place.
- Update procedures with managers: for example, "draft with the assistant, then review".
- Make feedback one click, and visibly fix what users report.
4. Champions
Find early adopters respected by their peers. Let them shape improvements and share how they use it. Peer examples persuade better than vendor demos.
5. Show results
Report in users' terms: minutes saved per case, fewer after-hours backlogs, less copying between systems. Report to leadership in business terms against the baseline.
6. Measure again
Set an adoption target with the sponsor (for example, used on 70% of eligible cases), track weekly, and keep iterating.
What not to do
- Mandate usage without fixing the reasons; people find ways around it.
- Blame users. Low adoption is product feedback.
What interviewers want: investigating before acting, empathy for users, and treating adoption as part of the engineering job, not someone else's problem.
Last updated 16 October 2026
Sources