In this guide 6 sections
Rejection has two causes. Either the software makes their daily workload heavier before it makes it lighter, or they caught it showing a number they know is wrong. From outside both look like resistance to change, yet they need different fixes, so telling them apart by watching real work comes first.
Two different reasons rollouts get rejected
The first reason is workload disruption: even better software slows invoice entry or goods receipt posting for weeks, because nobody has built muscle memory for it. Unless the transition is planned with reduced targets, extra hands and an honest acknowledgement that the team is doing two things at once, people route around the software. Plan for the dip.
Lost trust is the second reason, and it is harder to reverse: the system shows a stock count that contradicts the shelf or a debtor balance that is wrong. The usual causes are a migration error or a workflow gap nobody accounted for, and once an employee catches the system being wrong, a private shadow record starts. Then the source of truth is gone.
Take a haulage firm rolling out a fleet telematics app: in week one, dispatchers who assigned a delivery with a two minute phone call now need six minutes. By week three a lorry shows as last seen four hours earlier after a GPS blackout, the dispatchers spot it, and they quietly return to phoning drivers. Two problems, two fixes.
Separating usability, training and incentive problems
Employees not using the software is a symptom with at least three causes, and treating every case as a training problem is the most common mistake. A usability problem means the screen makes a routine task harder than before, through extra clicks, mandatory fields such as cost centre or tax code, or a confusing sequence. Training cannot fix a slower workflow.
A training problem means the software is fine but people were never shown their own daily tasks, and generic whole system sessions fail them. People forget what they did not need. An incentive problem is different again: the tool is well designed and well taught, but the old shortcut is quicker and nobody minds if staff skip the new screen.
Gathering real evidence instead of guessing
Watch, do not ask. Sit with two or three employees while they do a real task rather than a demo, and the problem usually surfaces within twenty minutes. You will see the field they hesitate over, the step they get wrong and the moment they reach for the phone, whereas interview answers stay vague.
Also look at what people do instead: a WhatsApp group that replaced a status field, a personal spreadsheet beside the official ledger, or a ring round to the storekeeper. Each workaround is a specific, fixable complaint about one part of the software, even though nobody wrote it down as feedback or raised it in a meeting.
Deciding what to fix first
Prioritise with the people doing the work: bring two or three representative employees into the review, show them the issue list and ask which items cost the most time. Managers often guess wrong. Staff sit closer to the friction, so their ranking differs from what a manager assumes, and the gap tells you where the real complaint sits.
Fix a small number of high friction issues completely instead of making shallow improvements everywhere, because one genuine annoyance resolved shows people that feedback gets acted on. Trust grows from visible fixes.
Measuring whether the fix worked
Adoption can be measured. Count how many people log in and complete tasks in the system versus the old method, whether the shadow spreadsheets are shrinking, and whether repeat questions fall. Weekly counts beat opinions.
Give any fix a defined window, usually two to four weeks, before judging it, because people need a little time to unlearn the workaround. If nothing moves, the diagnosis was wrong. Go back to watching real usage instead of assuming the fix only needs more time, because a correct diagnosis shows movement within the window.
Adoption barrier matrix
A grid mapping each observed symptom, such as a workaround, a skipped step or a repeated support question, to its likely cause of usability, training or incentive. Fill it in during observation.
Open a blank worksheet to printQuestions owners ask
Is resistance always a training issue?
No, and that is the common error. Many rejected rollouts fail because the interface makes a routine task harder, not because employees were never shown how to use it. Training cannot speed up a slower workflow.
How do we identify the actual cause?
Watch two or three employees do real work in the new system, noting where they hesitate, misclick or switch to a workaround. The workaround points at the cause.
Who should lead the investigation?
Someone neutral who can sit beside staff without being their manager, because people show the real shortcuts only when they do not fear being judged for using them. Promise that nothing is reported by name.