Why Nobody Uses the Software You Already Paid For

Why is nobody using the software we bought?

Because for the person doing the work, the new way is slower than the old way. That is the answer most of the time, and it is not a discipline problem or a training problem. People protect their day, and a tool that costs them minutes per transaction loses to a spreadsheet that does not.

The standard response is more training. Training teaches someone to use a slower path. It does not make the path faster.

How do I check whether that is what is happening?

Watch one person do the task both ways and time it with a stopwatch. Not a survey, not a workshop. One person, one real task, twice.

If the new system takes longer, you have your answer and no amount of change management will fix it. If it is genuinely faster and still unused, then you have a different problem, and it is usually that nobody removed the old path.

Why would a purpose-built system be slower?

Usually because it was specified by people who do not do the work. The system captures what management wants to report on, which is not the same as what the task requires.

Common shapes this takes: required fields that the person does not know at the moment of entry, a workflow that assumes a linear sequence when the real work loops, and approval gates added for an edge case that now slow every ordinary transaction.

Each was a reasonable decision on its own. Together they add ninety seconds to something that used to take thirty.

Is it ever actually resistance to change?

Sometimes, and it looks different. Genuine resistance shows up as complaints about the concept, ownership of the old way, or concern about visibility into someone's performance.

Speed complaints are specific and mechanical. People say the login times out, or that they have to enter the customer twice, or that the screen does not show the one field they need. Those are design reports wearing the costume of an attitude problem.

What do I do if the tool really is slower?

Fix the three steps that cost the most time before you ask anyone to adopt anything. In most rollouts that is a short list.

Strip required fields the person cannot know yet. Default anything that is defaultable. Remove approval gates that were added for a rare case and apply them conditionally instead. Then run the stopwatch test again.

Adoption follows when the new path is genuinely the shorter one. It does not need to be enforced at that point, which is how you know it worked.

What about the old system, do I shut it off?

Only after the new path is faster, never before. Turning off the old system while the new one is slower does not create adoption. It creates workarounds, and those are harder to see and harder to remove than the spreadsheet you were trying to retire.

How does this connect to what we bought it for?

Go-live is not adoption, and adoption is not the goal either. The goal was whatever you justified the purchase with: faster quoting, cleaner data, fewer missed handoffs.

As of 2026, roughly a quarter of mid-sized businesses say they need better return on the technology they already own. Almost none of that gap is about picking the wrong product. It is about buying software and changing nothing about how the work flows through it.