The implementation finished on time. Training happened, and people attended. The licences renew every month.
Four months on, two people use it properly, three use it when reminded, and the rest of the team is still working from the spreadsheet they used before, which has quietly acquired three new columns.
Nobody is being difficult. Something specific is happening, and it is worth finding out what before spending anything else.
The arithmetic nobody runs
Worth doing once, because it reframes the whole conversation from a behaviour problem into a cost one.
Take the system's annual cost, licences plus whatever share of the implementation you would amortise. Then take your honest adoption estimate. If half the team is using it properly, you are paying full price for half the value, and the other half of that spend is buying nothing.
Now add the second cost, which is larger and never counted. The parallel process still exists. People are maintaining a spreadsheet alongside the system, which means the work is being done twice, and somewhere a reconciliation is happening because the two disagree. That duplicated effort is real staff time every week.
Then the third cost. Because the data in the system is incomplete, nobody trusts the reports from it, so decisions still get made from the spreadsheet, which means the reporting benefit that justified the purchase has not arrived either.
Put those three together and low adoption is usually costing more than the licence fee by a comfortable margin. That number is what justifies spending a few days properly diagnosing it, and it is the argument to make internally when somebody suggests simply living with it.
It also reframes the decision for the person who chose the system. The conversation stops being about whether the purchase was a mistake, which nobody can discuss calmly, and becomes about recovering value from an asset the business already owns. That framing gets considerably more cooperation.
Four causes, only one of them technical
It is slower than what people did before. A task that took four clicks in a spreadsheet now takes twelve screens and a mandatory field nobody has the answer to. From management the system looks better because it captures more. From the person doing that task forty times a day it is straightforwardly worse, and they are correct about their own experience.
It does not fit how the work actually happens. The system encodes a process that differs from the real one, usually because it was built from how the work is supposed to run rather than how it does.
Nobody is accountable for using it. Updating it is nobody's named responsibility, and nothing happens when it is not updated.
The old way still works. As long as both routes exist, people use whichever is easier today, which is the familiar one.
Only the first is really about the software. The other three are about process, management and decisions, which is why buying more software features rarely helps.
Training is the wrong first purchase
It is the most common response because it is the easiest thing to buy and it feels like action.
Training addresses people not knowing how. That is rarely the problem. If somebody knows how to use the system and still does not, more instruction changes nothing at all.
There is a fifteen-minute test. Ask three people to do a common task in front of you, without helping.
If they can do it competently and simply choose not to in normal work, training is not your issue and buying it will waste the money and the goodwill. If they get stuck at a specific step, you have found something concrete and narrow, which is a far better position than a general sense that adoption is poor.
Watch, do not survey
The single highest-value thing in this article costs nothing: sit with three people while they do the task, and count the steps.
Not a description in a meeting. The actual work, at their desk, without helping or commenting.
People describe their process as they believe it should be and perform it as it actually is. The gap between those two is exactly where the problem lives, and no survey will surface it because the person answering does not perceive their workaround as a workaround. It is simply how they get the job done.
You will see the second spreadsheet open on the other monitor. You will see the field they fill with a full stop because they do not have the real answer and cannot save without it. You will see them wait eleven seconds for a screen to load, forty times a day.
Count what the mandatory fields cost
Mandatory fields get added by whoever wants a report. Each one is trivial to add and adds seconds to every single use.
Twenty seconds, forty times a day, across six people, is several hours a week that nobody assigned to the person who requested the field. Nobody was being unreasonable. The cost simply landed somewhere it was never counted.
So take the most frequent task and count the clicks and fields it requires. Then ask, for each field, who reads it and what decision it informs. A surprising number turn out to be for a report nobody looks at, or for a person who left.
Removing steps from the most frequent path is the cheapest adoption improvement available, and it is almost always possible without changing systems.
Exceptions are what decide fit
If the system handles the clean case and forces people out of it for everything else, you have a fit problem rather than a training one.
This matters more than it sounds, because of what happens next. If the system cannot handle the twenty per cent of cases that are unusual, people keep a parallel process for those. And once a parallel process exists, it absorbs the easy cases too, because maintaining two is harder than maintaining one.
That is precisely how a spreadsheet returns months after everybody agreed to stop using it. It never came back for the ordinary work. It came back for the exceptions and then expanded.
The underlying cause is usually that the process was documented from how it is supposed to run. The exceptions live in people's heads and never made it into the specification, so the system was built without them. The people who could have supplied them were not asked, or were asked in a workshop where nobody thinks to mention the thing they do every Thursday.
Accountability is not a software feature
If updating the system is nobody's job and nothing happens when it is not updated, people will do it when convenient, which is not consistently.
No feature fixes this. It requires a named person, a stated expectation, and a visible consequence.
The consequence does not have to be punitive, and the lightest version usually works best: produce the weekly report from the system. Anything not entered does not exist, its absence is noticed by somebody who cares, and the correction happens without anybody being told off. Visibility does more work here than enforcement.
This is the cause most often misdiagnosed as a software problem, and our guide on whether it is actually a software problem covers the general pattern, of which this is a specific and very common case.
Close the old route, at the right time
Running old and new in parallel indefinitely feels safe and guarantees low adoption.
At some point the old route has to close, and that is a management decision rather than a technical one. Two conditions before you make it: the new system genuinely handles the common cases including the frequent exceptions, and people have had a stated notice period.
Not before that, because forcing people onto something that cannot do their job produces workarounds you will never discover. And not indefinitely later, because an open parallel route will be used.
Which raises the question of mandating use generally. Mandating a system that genuinely does not fit produces compliance theatre: people enter the minimum required to satisfy the rule and keep the real record elsewhere. You end up with two sources of truth, one of which is wrong, which is worse than where you started.
You can spot compliance theatre in the data. Records created in batches at the end of the week rather than as work happens. Notes fields empty or containing a single character. Dates clustering suspiciously. Those patterns mean people are satisfying a requirement rather than using a tool.
Fix the fit first. Then require it.
Ask properly, and be sceptical of "resistance"
Talk to the people doing the work, individually rather than in a group, and ask what is harder now than it was before. Ask for specifics rather than opinions.
In a group, people give the socially acceptable answer, and the person who thinks the system is a waste of time will usually say nothing.
When somebody explains low adoption as people resisting change, treat that with suspicion. It is the most convenient explanation available to whoever chose the system, and it forecloses the investigation. It is occasionally true and far more often a label applied to a legitimate objection nobody examined.
The test: ask what specifically is worse. If the answer is concrete and several people independently give the same one, that is a finding rather than resistance.
Measure completion, not logins
Somebody logging in every day and completing nothing is not adoption, and a login count will never tell you that.
UK government service guidance mandates take-up and completion rate among its performance indicators for public services [1]. Those are exactly the two measures most businesses never apply to their own internal systems, and they are the two that answer the question.
So measure whether the core task is completed in the system, and where people stop when it is not.
On targets, the useful comparison is internal rather than to any benchmark. Where the system is the process, near-total use is the only acceptable outcome, and anything less means a parallel process exists somewhere. Where it supports optional work, partial use may be entirely fine. Decide which you have before setting a number, because the two need different responses.
Watch direction as much as level. Usage climbing slowly is healthy. Usage flat or falling after the initial push means something structural rather than something that needs more time.
Somebody has to own it after go-live
Implementation projects have a project manager until go-live and then nobody.
The weeks immediately after launch are when adoption is actually decided, and they are typically the weeks when everyone involved has moved on to the next thing. That gap is not a minor scheduling issue. It is the single most common reason implementations that went well produce systems nobody uses.
Name somebody, give them time, and have them spend the first month watching how it is actually used, collecting friction points, and fixing the top few quickly.
Early visible fixes do more for adoption than any amount of communication, because they demonstrate that raising a problem produces a change. Once people believe that, they tell you about problems instead of silently routing around the system.
Before concluding it was the wrong system
It is both the most expensive conclusion and the most emotionally convenient one for anybody who opposed the choice originally.
Configuration, removing unnecessary mandatory fields, simplifying the most frequent path, and integrating with something people already use will resolve a large share of adoption problems at a fraction of the cost of replacement.
Integration is worth particular attention, because the largest barrier is often simply that the system is somewhere else. If people have to leave the tool they live in to enter something, they will do it later and then not at all.
If the fit problems really are fundamental rather than configurable, that is a genuine finding. Our guide on rebuilding versus fixing covers how to assess a replace-it recommendation without simply repeating the original decision using the same information that produced it.
And note that none of this changes if you built the system yourself. Custom builds carry one extra trap: because the business specified it, low adoption gets read as a people problem rather than a design one. A custom system built from a documented process rather than an observed one has exactly the same fit failure as an off-the-shelf product, for exactly the same reason.
What to do, and what not to
Do not buy more training before diagnosing. Do not mandate use of something that does not fit. Do not start a replacement project until you know why the current one failed. All three feel decisive and all three reliably spend money on the wrong problem.
Instead: sit with three people while they do the task, and count the steps. Fifteen minutes each, no meeting, no survey, no supplier. You will see the workaround rather than hear a description of the process, and that is the difference between diagnosing this and discussing it.
If you want an outside view, a review covering how the system is actually being used, where the friction sits, whether the cause is fit, speed, accountability or a surviving alternative, and what to change first starts from around AED 2,500 with us. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- GOV.UK Service Standard, define what success looks like and publish performance data
- GOV.UK Service Manual, measuring success
- SKIMBOX, is this actually a software problem
- SKIMBOX, rebuild it or fix it
- SKIMBOX, your app is built and nobody is using it
- SKIMBOX, ERP implementation in the UAE
- SKIMBOX, CRM implementation in the UAE
UK government service guidance addresses public sector digital services and mandates published performance data. It is cited here for the two measures it requires, which adapt directly to internal business systems, rather than as a requirement applying to businesses in the UAE.
