Business

Why new software goes unused

When a new tool isn't adopted, the cause is rarely laziness: it is that the new way costs more than the old one in time, effort or risk. Adoption is designed — choosing who goes first, removing friction, measuring real usage and switching off the old route only when the new one genuinely pays.

30 Dec 2025 · 8 min read · updated on 27 Aug 2026

The scene repeats with suspicious regularity. The tool was chosen carefully, the migration went well, the training happened. Three months later a third of people use it, a third use it halfway and a third have found a way to carry on as before.

The convenient explanation is "people resist change". It is nearly always false, and dangerous because it closes the conversation. People happily adopt tools that make their day easier. When they don't, it is usually because the new way costs more than the old one — in time, effort or risk.

The four costs that block adoption

Learning cost. Every action requires thought until it becomes automatic. In the first weeks whoever uses the new tool is slower, and if they have a deadline they go back to the old one: not sabotage, priority.
Path cost. If an action that took two steps now takes five, adoption will never happen, however much training you provide. Those steps must be counted before choosing.
Risk cost. "What if I get it wrong?" If a mistake is visible to everyone or hard to undo, people avoid the tool in the important cases — precisely where it was needed.
Social cost. If the boss keeps asking for the old summary by email, the message is that the new system is optional. No training can counter that signal.

Training teaches how to use the tool. Adoption is about why anyone would want to: two different problems.The distinction that changes projects

Why training alone isn't enough

Classic training — half a day in a room, two weeks before go-live, on an empty test environment — is optimised for the convenience of the trainer, not for how people learn. By the time it is used for real, too much time has passed, the data is different and the real cases weren't in the course.

What works is less elegant: someone beside them during the first days of real work. Not to explain features, but to answer the blocking question — "and in this case?" — at the moment it arises. Two weeks of hands-on support beat ten courses.

The six weeks that decide

Start with whoever gains most. Not the largest department, but the one the tool relieves of a genuine nuisance. The first group must succeed: they will convince the others.
Remove the initial friction. Pre-fill what can be pre-filled, import historical data, drop mandatory fields nobody will use. Day one must be easy, even at the cost of being incomplete.
Make the benefit visible. If the system saves twenty minutes a day, say it with a number, not an adjective.
Collect friction weekly. A short list of the things that make people swear, and fix two of them. It is the strongest signal that the tool is theirs and not imposed.
Switch off the old route, but later. While both exist, many will stay on the old one. But switching it off before the new one works well turns an adoption problem into an operational one.

How to actually measure it

"They seem to be using it" is not a measurement. The three that matter come from data the system already produces:

How many people open it each week, out of those who should.
What percentage of operations goes through the system rather than email, phone or spreadsheets. The most honest measure of all.
Where they stop. If everyone abandons at the same point, it is not a people problem: it is a problem with that point.

If after six weeks the second measure isn't rising, don't push more training: there is a hidden cost nobody told you about. Ask the people not using it, without a reproachful tone — they will tell you, and they are usually right.

The case where they are right

It has to be said, because it happens: sometimes people don't adopt the tool because the tool is worse. The process had been refined over the years with undocumented workarounds, and the new system — designed by looking at the org chart instead of the work — deleted all of them.

In that case the only sensible move is to go back and look at the process, not to push adoption. Insisting means getting people to pretend to use it while the real work happens elsewhere: the worst outcome, because it costs and stays invisible.

If you have a paid-for tool that is barely used, the question is not "how do we convince them?" but "what does using it cost them?". The answer comes from an afternoon spent beside the people working, and it almost always points to a small change.

How long before a tool is adopted?

For a daily action, six to eight weeks to become automatic. For rare actions — once a month — it takes months, and there it pays to invest in on-the-spot instructions rather than training.

Should we make it mandatory?

Mandating works only if the tool is already good: it speeds up an adoption that would have happened anyway. If it is more awkward than the old way, mandating produces badly entered data, which is worse than no data.

What if the problem is one person?

Look at what they do differently: often whoever resists is the one with the edge case the system doesn't cover. Solving that case is worth more than any conversation about cooperation.

Who should lead adoption?

Someone internal who does that job and has credibility with colleagues — not the supplier and not management alone. The supplier can assist; trust, though, is only lent between people who know each other.