A system goes live, the training sessions run, the logins are issued, and three months later the work is still being done in a spreadsheet, a text message thread, and a paper packet in the truck. The usual explanation is that people resist change. That explanation is comfortable, it is almost always wrong, and it is the reason the problem persists. Once non-adoption is attributed to the user's disposition, nobody looks at the software again.
Non-adoption is a rational response
Start from the assumption that the person avoiding the system is behaving sensibly. They are optimizing for something real and immediate: finishing the job, getting to the next call, going home. If the system helped them do that, they would use it without being asked. When someone maintains a private spreadsheet alongside a system that cost six figures, they are not making a statement about change. They are telling you, in the only way that costs them nothing, that the spreadsheet is faster.
This changes what you investigate. "Change resistance" points you at communication, training, and mandates. Rational avoidance points you at the software and the workflow around it, which is where the cause almost always is. The useful question is not why won't they use it. It is what does using it cost them, and what does skipping it save them.
It was specified by people who do not do the work
Requirements are usually gathered from managers, analysts, and system owners. Those people are knowledgeable and well-intentioned, and they describe the process as it is documented rather than as it is performed. The documented process is a clean sequence. The performed process is full of parallelism, partial information, interruptions, and small local judgments nobody wrote down because nobody considered them decisions.
The result models the org chart's view of the work. It is coherent, it demos well, and it is unusable at the point of contact, because the person doing the job is asked to work in a sequence that does not match reality. That is not a training problem. Training can teach someone where a button is; it cannot make a workflow match a job it was not modeled on.
The tell is in who was in the room. If nobody who performs the work spent time in specification (not a review meeting at the end, but the work of defining what the screens do), a workflow mismatch is likely, and it will surface as an adoption problem months later.
It is slower than the workaround for the most frequent task
This is the most common cause and the one most worth checking first, because it is measurable and nobody has to be persuaded of anything. Identify the task a user performs most often. Time it in the new system. Time the same task the way they did it before, or the way they still do it. If the new system loses, adoption is not going to happen, and no amount of executive sponsorship will change that arithmetic.
The gaps are usually mundane. Four screens where there was one. A required field that needs a lookup from another system. A page that takes eleven seconds to load on the network available in a basement or a parking lot. Two extra taps, forty times a day, on a device held in one hand. Individually these look like nitpicks in a requirements review. Multiplied by frequency they are the entire decision.
Frequency is the weight that gets left out. A task performed once a month can afford to be clumsy; a task performed thirty times a day cannot afford five extra seconds. Order adoption fixes by time cost times frequency, not by how loudly each was raised.
It asks for what the user does not have, in an order the job does not follow
A form that requires a purchase order number at dispatch, when the purchase order is issued after the site visit, forces one of three behaviors: the user stops and hunts, enters a placeholder, or does not use the form. Two of those destroy your data quality and the third destroys adoption. All three are usually reported as user error.
The same failure appears as sequence mismatch. Real work is rarely linear. A technician starts a job, gets interrupted, diagnoses before confirming the customer, discovers the actual problem is different from the dispatched one, and closes out from a truck with no signal. A system that requires steps in a fixed order, refuses to hold an incomplete record, or cannot operate offline is not modeling that job. It is modeling a tidier one that does not exist.
- Required fields that depend on information generated later in the process.
- Validation that blocks saving rather than flagging an incomplete record for later.
- Linear wizards imposed on work that is interrupted, revisited, and done out of order.
- Data entry that assumes connectivity, a desk, two hands, or a full-size screen.
- Duplicate entry of anything the user already typed into another system that day.
Nothing flows back, and nothing happens if you skip it
Two incentive failures compound the ones above. The first is that data flows in and nothing useful flows back. The user enters detailed job notes, parts used, and time on site, and receives nothing in return: no better dispatch, no faster pay, no fewer phone calls, no history that saves them a diagnosis on the next visit. From where they stand the system is a reporting instrument for somebody else, funded out of their working day. That is an accurate read, and it is worth fixing at the design level rather than arguing with.
The second is that skipping the system carries no consequence and using it carries no benefit. Invoicing still goes out when the paper packet arrives. Payroll still runs on the text message. The alternative path remains fully functional, so the system is optional in practice regardless of what the announcement said.
Per-user licensing and poor mobile usability kept critical users out of the system entirely. After the replacement rollout, field data capture reached 95 percent or better and job completion moved to same-day invoicing.
That came from removing the reasons not to use the system: access for every technician without a seat-count tradeoff, a mobile experience matched to how field work is actually performed, and an invoice produced by closing the job in the system, so the fastest path to getting paid runs through the software rather than around it.
How to diagnose it honestly
Surveys will not find this. People answer diplomatically, under-report their own workarounds, and cannot always articulate why something is slow. Go and watch instead: sit with four or five users through a normal shift, say nothing, and record what they actually do, including everything they do outside the system.
- 1
Shadow real work for a full cycle. Note every switch to paper, phone, spreadsheet, or another application, and what triggered it.
- 2
Time the top three tasks in the system and against the current workaround. Write both numbers down and multiply by daily frequency.
- 3
Inventory the shadow spreadsheets. Every one is a specification for a capability the system is missing or making too expensive.
- 4
Read the data, not the dashboard. Look for placeholder values, records completed in bulk at end of day, and fields that are always the same.
- 5
Ask one question, phrased without blame: what would have to be true for this to be the faster way to do your job?
| Observed behavior | What it usually means | What to change |
|---|---|---|
| A parallel spreadsheet is maintained alongside the system | The system cannot do something the job requires, or cannot do it fast enough | Treat the spreadsheet's columns and views as a requirements document and build what is missing |
| Records are entered in a batch at the end of the day | Entry is too slow or impractical at the moment the work happens | Make in-the-moment capture faster than deferring it: fewer fields, offline capable, one hand |
| The same placeholder value appears in a required field | The field asks for information the user does not have at that point | Make it optional at that step and collect it where the information actually exists |
| Users call or message a coordinator to get information that is on screen | The information is present but not findable in the flow of the work | Surface it where the decision is made rather than in a separate module or report |
| Only supervisors and back office log in regularly | The system takes from frontline users and gives back nothing they can use | Build a return path: job history, prefilled data, fewer callbacks, faster pay |
| Adoption spikes at go-live and decays within weeks | Compliance was driven by attention, not by the system being better | Fix the time cost of the highest-frequency task before reintroducing any mandate |
What actually fixes it
Fix the frequency-weighted time cost first. If the most common task is slower than the workaround, nothing else will hold. The work is unglamorous (collapsing screens, removing fields, prefilling from context, caching for offline, cutting page load), and it has the highest return available on a struggling rollout.
Then build the return path. Give frontline users something only the system can provide: the history of the site they are standing in, the parts that fixed it last time, a schedule that reflects reality, an invoice that goes out the day the job closes. Adoption sustains itself when the system is the fastest route to the user's own outcome.
There is an uncomfortable step that eventually has to happen. While the old path still works, part of the organization will keep using it and you will reconcile between two systems forever. At some point the paper packet stops being accepted and the spreadsheet stops feeding the invoice. That step is legitimate, but only after the system is genuinely faster for the people being asked to use it. Earlier than that, it does not produce adoption; it produces worse data, quietly entered, by people with no other option.
Finally, change who specifies the next release. Put the people who do the work into the definition of the change rather than the review of it, and ship in increments small enough for them to react to. A rollout corrected every two weeks by its users will outperform one that was perfectly planned and then defended.
Common questions
- Isn't some resistance to change genuine?
- Occasionally, and it is real when someone's role or authority is being reduced by the new system. But it is diagnosed far more often than it occurs, and it is usually the first explanation offered rather than the last one standing. Rule out the measurable causes first (task time, missing information, sequence mismatch, incentives) because those account for the large majority of cases and they are fixable.
- How long should we wait before deciding a rollout has failed?
- Look at the trend rather than the level. A healthy rollout starts imperfect and climbs as fixes land. If usage spikes at go-live and decays over the following four to six weeks, that is not a slow start. It is people returning to a faster path once the attention moves on. Investigate at the first sign of decay rather than waiting for a quarterly review.
- Would more training fix this?
- Training fixes one specific problem: people do not know how to do something they would otherwise want to do. It does not fix a workflow that is slower than the alternative, a form that asks for information the user does not have, or an incentive that rewards skipping the system. If a second round of training was already tried and adoption did not move, the cause is in the software or the process.
- Can we just mandate it?
- You can, and it produces compliance rather than adoption. People will enter the minimum required to clear the screen, which gives you a system that appears used and data that cannot be trusted. That is worse than visible non-adoption, because the problem is now hidden inside reports that people act on. Mandates work only after the system is the faster path.
- What if the users say the system is fine but still don't use it?
- That is common and it is why observation beats surveys. People are reluctant to criticize something the company spent money on, and they often cannot name what is slow about it. Shadow a full shift and time the top tasks; the gap will show up in behavior even when it does not show up in interviews.
- Is it cheaper to fix adoption or to replace the system?
- Almost always cheaper to fix adoption, and you should establish that before considering a replacement. Most adoption failures trace to a handful of high-frequency interactions and one or two missing capabilities, which is weeks of work rather than a new program. Replacement is warranted when the underlying model of the work is wrong throughout, not when the top three tasks are simply too slow.