Short answer
Usage figures tell you a new tool is not being used. They do not tell you why. The reason is usually specific:
- the tool is missing one thing a team needs;
- it adds a step to a job that was already busy;
- the old way still works, and nobody switched it off.
Ask the people who are not using it three things: what they do instead, what happened the last time they tried the tool, and what would make them switch. Then report what each group described, with the workaround beside it.
Why training is the default answer, and often the wrong one
When adoption is low, the usual response is more training, more communication and a reminder from leadership. Sometimes that is right. Often it is not: people understand the tool perfectly well and have decided it makes their work harder. More training then adds frustration without changing behaviour.
The UK government's lessons management guidance is about learning from what actually happened on a programme, rather than only recording it. For a tool rollout, the lesson usually sits with the people who chose not to use the tool.
What to ask
| Topic | What it reveals | Example question |
|---|---|---|
| What they do instead | The workaround, and why it survives | “When you need to log a job, what do you use now?” |
| The last attempt | Where the tool failed them | “Tell me about the last time you tried the new tool. What happened?” |
| What it added or removed | The effect on their workload | “What does the new tool make faster, and what does it make slower?” |
| Who else is affected | Upstream and downstream dependencies | “Who depends on what you enter, and what do they need from it?” |
| What would make them switch | Practical changes | “What would have to change for you to use it every day?” |
Ask about the work, not the person's attitude to change. "Why are you resisting the tool?" gets defensiveness; "what do you use instead?" gets the workaround.
Invite the users and the non-users
Include people who use the tool well, not only those who avoid it. The comparison is often the finding: one team uses it because their manager set it up for their workflow, while another avoids it because nobody did that for them.
Include the people downstream who depend on what is entered, such as finance, planning or reporting. Their needs may explain why the tool asks for steps users find pointless.
A fictional example: a field service app
A fictional facilities company rolled out a mobile app for engineers to log completed jobs. Six months later, a third of jobs are still logged on paper and typed in by the office.
The programme owner asks: "Why are our field engineers not using the new job app, what do they use instead, and what would make them switch?" Twelve engineers and three office coordinators answer:
- Eight of the twelve engineers say the app requires a photo of every completed job. The upload fails in basements with no signal, so they finish on paper and hand it in.
- Three say the app works well. All three cover city-centre sites with good coverage.
- Two office coordinators confirm that the paper sheets come almost entirely from basement and plant-room jobs.
- One engineer shares a screenshot of the error the app shows when an upload fails. Nobody had reported it, because "the paper works".
The finding is not "engineers resist the app". It is a specific technical requirement: completing a job offline, with the photo uploaded later. Training would not have fixed it.
Read usage data alongside the interviews
Usage data and interviews answer different questions. Usage data shows who, where and how much; interviews show why, and what people do instead. Use both: the data to find where adoption is lowest, and the interviews to understand those places. The HR digital transformation guide covers the wider rollout picture. The guide to survey fatigue is a reminder not to add yet another feedback form for a team already frustrated by a new tool.
Turn findings into changes
| Finding type | Example | Owner |
|---|---|---|
| A missing capability | Offline completion | Product team or vendor |
| An extra step with no value to the user | A mandatory field nobody downstream uses | Process owner |
| An old route still open | Paper forms still accepted | Operations manager |
| A real training gap | A feature people do not know exists | Training lead |
Then ask the same people again after the change.
Where Lontra fits
With Lontra, you write the adoption question in a sentence, approve the topics and invite the people who know, users and non-users alike. Each has a short private conversation, on any device, without an account. Lontra follows up on what they say and asks about the last time they tried the tool. People can share a screenshot of an error, or a photo of the paper form they use instead, and Lontra asks about what it shows. Findings show how many people described each reason, where groups disagree and what is still unknown, each linked to the conversations behind it.
It does not replace usage analytics. It also cannot tell you whether the vendor can build what people ask for.
Ask before you retrain
Before the next round of training or reminders, ask the people who are not using the tool what they do instead. The answer is usually specific, often fixable, and rarely "they need more training".
Frequently asked questions
- How do you find out why employees are not using a new tool?
- Ask the people who are not using it what they use instead, what happened the last time they tried the tool, and what would make them switch. Compare their answers with those of people who use it well.
- Is low software adoption a training problem?
- Sometimes. Often the tool lacks something a team needs, adds a step with no value to them, or the old way is still available. Find out which before investing in more training.
- Should usage data or interviews come first?
- Usage data first, to see where adoption is lowest; then interviews, to understand why in those places. Each answers a question the other cannot.