12 Oct 2026
Author
Gorakh Shrestha
Launch-week logins are easy to celebrate. The number that matters is steady use a month later, because that's what tells you whether the integration work, the licences and the training budget paid off. This article gives you three tests that explain why tools fade, and a three-question check you can run on your last rollout before the next one goes live.
Why we wrote this
That's rarely a training problem, and it's far easier to design in the fix before launch than to retrofit it once usage has dropped. This is for operations and technology leaders who answer for whether a rollout delivers, not just whether it goes live. If your tool is mandatory by policy, the problem is different, and we cover that too.
Week three on the usage dashboard
The launch went well. The claims team sat through the demo, asked sharp questions and logged in on day one. The new AI assistant summarised each claim file and suggested a next action, and week one looked strong.
The short answer: New tools go unused when they fail on fit, trust or ownership. A tool has to sit inside the work people already do, show why it gave each answer and be right early, and have one named owner who acts on feedback. Fix those three before you retrain anyone.
It's rarely training, and rarely attitude
When usage drops, the usual fixes are another training session or a firmer email from leadership. Both assume the problem sits with the people. In our experience it more often sits with how the tool was designed into the work, and with nobody owning it after launch.
Here's the honest part: sometimes low usage is the right result. If a tool solves a problem the team doesn't actually have, retire it rather than push harder. An ignored tool still costs licences and support time, and it makes the next launch harder to land.
Three tests every tool has to pass
Each test covers a different reason people stop. Miss one and usage decays, usually within a month, whatever the launch numbers said.
1. Fit: it sits in the workflow, not beside it
Every extra login, tab or copy-paste is a small tax on each use. People pay it for a week out of goodwill, then stop. Fit means the tool shows up at the moment the work happens, inside the system people already have open.
- What it looks like: the assistant lives in a separate browser tab. Assessors copy a claim number across, wait for a summary, then paste it back into the claims system.
- What good looks like: the summary appears on the claim screen itself, through single sign-on and an integration with the core system. Using the tool takes fewer steps than not using it.
2. Trust: it explains itself and is right early
Experienced people won't act on an answer they can't check. First impressions also set the pattern: two confident wrong answers in week one can undo a month of good ones.
- What it looks like: a recommendation with no reasoning and no sources. One early error gets shared in the team chat, and the tool becomes a running joke.
- What good looks like: every output cites the source records it drew on, such as the documents or data fields it used. Messy edge cases stay out of scope at launch, and a person reviews outputs before they matter.
3. Ownership: a named owner and a feedback loop
Tools launched by a project team often lose their owner when the project closes. Feedback then has nowhere to go, so people stop giving it. Ownership means one person in the business, not IT alone, is accountable for whether the tool is used and useful.
- What it looks like: "IT supports it" is the only answer to who owns it. Complaints go into a general helpdesk queue and nothing visibly changes.
- What good looks like: a named owner inside the team that uses it and a one-click way to flag a bad output. Flags land in a backlog the owner triages, fixes ship on a regular cycle, and users hear what changed.
When low usage isn't the real problem
Mandatory compliance tools are different. If staff must log an incident, complete a check or record consent, usage isn't optional. Low numbers there usually point to a process or enforcement gap, not an adoption one.
And if usage dropped because the work itself changed or disappeared, that's a signal to retire the tool. Rescuing it would only spend more on the wrong problem.
How the team side of adoption gets sequenced
The AI Adoption Framework makes this concrete. It's a 3x3 grid: Process, Team and Business, each moving through Set an intention, Put it in context, See it in action.
The Team row maps onto the three tests. Here it is applied to the claims assistant, as an illustrative example.
|
Stage
|
Team row step
|
The question it answers
|
Claims example (illustrative)
|
|---|---|---|---|
|
Set an intention
|
Define Capabilities
|
What should people do with it, and where?
|
Triage a new claim from the claim screen
|
|
Put it in context
|
Establish Controls
|
What may the tool do alone, and what needs a person?
|
It drafts and suggests; an assessor approves every action
|
|
See it in action
|
Create Ownership
|
Who keeps it used and improving after launch?
|
The claims team lead reviews flags fortnightly and reports back
|
The order matters. Defining capabilities first forces the fit question before anything is built. Establishing controls early gives people a reason to trust outputs, because they know where the human check sits.
Ownership comes last in the row, not last in the plan. The owner is working before the project team steps away, not appointed after usage drops.
What drives the effort
Building adoption in isn't free, and the effort depends more on your organisation than on the tool. Three things move it most:
How many teams are affected
How much the workflow changes
Training and support time
That effort tends to pay back. Prosci's research found projects with excellent change management were about seven times more likely to meet objectives than those with poor change management.
How we approach it
NEXUS Foundation
That means the Working AI Solution is tested by the people who'll use it, inside their own workflow, with controls agreed and a named owner in place. The Production Roadmap then reflects what it takes to scale use across more teams, not just what it takes to scale the build.
Does your last tool pass?
Frequently Asked Questions
Gorakh excels in leadership and web development, driving excellence. Always ready for new challenges, he fosters growth for himself and his team.
Read more Articles by this Author