Nobody Is Using the Software You Paid For — 7 Reasons and the Fix
You had the software built. You paid for it, ran the training, announced it in a meeting. Three months on: the field team still takes jobs over WhatsApp, the supervisor still writes in a notebook, and accounts still keeps its own spreadsheet. In the system itself there are a handful of records somebody typed in to show willing.
Most owners looking at that reach the same sentence: “Our people just won’t use it.”
I’ve spent years inside these projects, and what I’m about to say is uncomfortable but almost always true: software that isn’t used is a design problem, not a discipline problem. And “design” here doesn’t mean whether the screens look nice. It means whether the flow of the software matches the flow of the work.
The financial version of it is blunt: software that isn’t used is software that wasn’t built. What you paid for isn’t code, it’s usage.
1 · It was designed for the owner, not the user
Symptom: Handsome reports in the system, no data coming in from the field.
Root cause: The people in the scoping meeting were the owner and the manager. The person who’d be on the screen all day wasn’t there. The result carries information upwards and gives nothing back downwards. Look through the field user’s eyes: they enter data and get no easier day for it. “Why am I typing this?” isn’t laziness; it’s a correct judgement.
The fix: Give every user role something concrete in return. The engineer closes a job and the end-of-day report writes itself, instead of them writing it twice. The driver photographs a fuel receipt and never fills in an expense form. The technician sees the customer’s history on their phone and stops ringing the office. Rule: the person entering the data should be the first person to benefit from it.
2 · You never closed the old channel
Symptom: The system is in use. So is the WhatsApp group. So is paper. All three.
Root cause: When two channels are open, people take the easier one. That’s universal, not something peculiar to your team.
The fix: Set a closing date and actually close the old channel on it. But don’t invert the order: the new channel has to genuinely do the job first, and then the old one closes. Forcing people onto a system that doesn’t work yet discredits it permanently — once something is branded “that thing doesn’t work”, a second chance is very expensive.
3 · The cost of entry is too high
Symptom: “It takes too long”, “no time”, “I’ll enter it later”, and later never comes.
Root cause: The entry screen has twelve fields, four of them mandatory and three of them free text. The person in the field is trying to do that standing up, in gloves, one-handed.
The fix: Cut fields ruthlessly. The test: can the job be done without this field? If yes, it isn’t mandatory. Then make what’s left easier — pick lists instead of free text, camera or barcode instead of typing, smart defaults instead of blanks (last customer used, today’s date, that vehicle’s last odometer reading). Target: one record in under 30 seconds.
4 · The reality of the field was ignored
Symptom: “It doesn’t work in the warehouse”, “you can’t see the screen outside”, “my phone can’t handle it”.
Root cause: The app was tested in an office, on a new handset, on good wifi. It gets used in a concrete warehouse, on a site in full sun, on five-year-old phones.
The fix: It has to work offline and sync when the connection returns. For anything used in the field that isn’t a feature, it’s a precondition. Contrast and text size need to be readable in sunlight, and the app has to open on old devices. If none of that went into the acceptance criteria, nobody tested it.
5 · Training happened once and stopped
Symptom: Usage in launch week, zero by month two.
Root cause: A two-hour group session and a PDF manual. Nobody opens the PDF, and what’s learned in two hours is gone in a week.
The fix: Three things together: - Ten minutes a day for the first fortnight: at shift start, in front of the screen, on real work. - A super-user on every shift. People ask the person next to them, not a trainer somewhere else. Give that person time and make them visible. - A one-page card. The three most common tasks, step by step, big enough to pin to a wall. Not a manual — a card.
6 · Nobody looks at what comes out
Symptom: Data goes in, then tails off, then stops within a few months.
Root cause: Nothing from the system is ever opened in a meeting. People don’t keep feeding a place nobody looks at, and they’re right not to.
The fix: Run the weekly meeting from the system. Put it on the screen and read the list from there. Then set one rule and never bend it: work that isn’t in the system doesn’t get discussed. Bend it once — “fine, just tell me verbally” — and the system dies that day. Adoption is carried by this rule, not by training.
7 · Problem reports go nowhere
Symptom: “We told them. Nothing happened.” Then silence.
Root cause: A user hits a bug, tells the supervisor, who tells the manager, and there it disappears. Three rounds of that and the user stops reporting, and a user who stops reporting soon stops using.
The fix: One channel, a visible list, a regular release. Reports land in one place (an in-app button is best), the resulting list sits somewhere everyone can see, and every two weeks something improves, however small. Small doesn’t matter; visible does. A user who sees their report acted on once will report again.
How to measure adoption
Don’t answer “is it being used?” from instinct. Two measures are enough:
| Measure | How to read it | What good looks like |
|---|---|---|
| Weekly active ratio | People who actually used it that week ÷ people who should have | Registered user count means nothing; the ratio means everything |
| Where the work lives | Pick 10 real jobs at random — how many are fully recorded in the system? | Anything short of 10/10 means a parallel system is alive |
The second one takes five minutes and tells you what no report will.
A 30-day recovery plan
If the software exists but isn’t used, try this before commissioning anything new:
- Week 1 — watch. Sit next to three users and watch them work. Don’t survey them, don’t ask them: watch. Note where they hesitate. Most of the reasons surface this week.
- Week 2 — cut the friction. Reduce mandatory fields, fill in defaults, move the most common task to the home screen. Add no features; remove them.
- Week 3 — build the ritual. Run the weekly meeting from the system, announce the “not in the system, not discussed” rule, name a super-user per shift.
- Week 4 — close the old channel. If the new one works, give a date and close it. Then measure: weekly active ratio and the ten-job sample.
If it still isn’t used after those four weeks, the problem really is the product, and the conversation to have then is about scope, not training.
Sometimes the software isn’t the guilty party
One caveat: no software holds together a process that was never written down. If who does what, in what order, on whose decision is undefined, software doesn’t resolve that ambiguity. It just makes it visible. The complaint “the system is slowing us down” is sometimes accurate. What it’s telling you is that the system is the first thing ever to force a definition of a process that lived only in people’s heads.
In that case the work isn’t to change the software. It’s to write the process on one page, and then fit the software to that page.
The decision that comes before all of this — buy or build — is in off-the-shelf software or a custom build. Its “pilot scope” point is exactly this article’s insurance policy: a system never tried in one department collapses across the whole company at once.
To set up the asset and record structure the system will carry: the business asset inventory. To put it inside a periodic review: the August business review.
Adoption isn’t a persuasion job, it’s a design and management job. Make life easier for whoever enters the data, close the old channel, and look at the output in the meeting. Do all three and “our people just won’t use it” tends to disappear on its own.
Fuat Çakır — industrial engineer and management consultant. He works on digital product design and software project structure in manufacturing and service businesses, and builds and ships his own mobile apps.
Most adoption problems start with “done” never having been defined at delivery; the form to sign: software project acceptance criteria.
Frequently Asked Questions
What should I do if employees won’t use new software? Measure the reason before trying to persuade anyone. Sit with three users and watch them work — most of the causes are visible there. Then do three things together: give whoever enters data something concrete in return, cut the number of mandatory fields, and close the old channel (WhatsApp, paper) on an announced date. Training alone does not produce adoption.
How do you measure software adoption? With two figures: the ratio of people who actually used it in a week to the people who should have, and how many of ten randomly chosen real jobs are fully recorded in the system. Registered user counts mislead; the ratio and the sample show the truth.
When should I switch off the old way of working? Once the new channel can genuinely do the job, on an announced date. While two channels stay open, people use the easier one. But forcing the switch onto a system that doesn’t work yet costs more: once something is branded as not working, a second chance is hard to come by.