The people who choose business software and the people who use it are usually different people.
An owner or manager evaluates, decides, and signs. A counter operator, a storekeeper, a nurse or a driver then has their working method replaced — a method that, whatever its flaws, they had made work. They were not consulted, and now they are being trained.
That asymmetry explains most adoption failure. It is not resistance to change in the abstract. It is a rational response to being handed something slower than what you had, by someone who will not have to use it.
Adoption is decided before training
By the time training happens, most of the outcome is already fixed.
If the system is slower at the busiest hour than the method it replaced, no amount of training makes it stick. Staff will use it when they can and bypass it when they cannot, and the bypass becomes permanent because it was invented under pressure and never revisited.
This is why we test with the people who will actually use a system before launch, and redesign whatever is awkward while it is still cheap — the step described in how Truffaire builds software. The most common redesign is not adding a feature. It is removing a step.
The uncomfortable implication: if adoption is failing, the first question is not how to train harder. It is what the system is asking people to do that the old method did not.
Involve them before the decision, not after
The cheapest adoption intervention costs nothing and happens months before training: ask the people doing the work how it actually gets done.
This has two effects.
It produces better software. The real process contains workarounds and exceptions that never appear in a requirements meeting. Anyone who has watched an operation knows the described process and the performed process differ.
It changes the relationship to the change. Someone whose input shaped a system is being given something they helped build. Someone who first encounters it in training is being given something done to them.
The second effect is not manipulation — it is a genuine difference in what happened. And it is why the request "just tell us what you need" delivered by email is not the same thing as sitting at the counter for a day.
What training should actually cover
Most training explains the software. It should teach the job.
The path through a normal day, in the order it happens. Not a tour of modules — the actual sequence: opening, first transaction, common cases, close.
The awkward cases, explicitly. Partial returns, price overrides, split payments, corrections. These are where people improvise, and improvisation is where the record breaks. If someone has never been shown how to record a return against a discounted bill, they will invent something.
What to do when it goes wrong. Connectivity drops, a figure looks incorrect, something was entered against the wrong record. Staff who do not know the recovery path will avoid the situation, which usually means avoiding the system.
Why, briefly. Not a change-management presentation. One honest sentence about what this makes better — ideally something that benefits them rather than only management. If the only benefit is upward reporting, say that rather than pretending otherwise.
Days, not weeks
Training measured in weeks is a signal about the software, not the staff.
A system that takes weeks to learn is too complex for people who have another job to do, and the complexity will surface again as errors long after training ends. Our target is counter staff productive in days, in their own terminology — and where that is not achievable, we treat it as a design problem rather than a training problem.
The related discipline is fewer modules. Every module is something to learn, maintain and keep accurate. A narrow system that is fully used beats a comprehensive one where half the functions hold stale data.
The first two weeks decide it
Adoption is won or lost in the period immediately after go-live, and the failure mode is predictable: something goes wrong at a busy moment, nobody is available to help, the person reverts to the old method, and the revert becomes the habit.
What prevents it:
Someone available at the counter, physically, during the first busy periods. Not a support email address.
Fast fixes for small irritations. The first two weeks surface a handful of genuinely awkward interactions. Fixing them quickly demonstrates that the system is responsive; deferring them to a quarterly release teaches people it is not.
Running in parallel briefly. Keeping the old method available lowers the stakes. Removing it before the new system is proven forces people into a situation they cannot recover from, and that is where resentment forms.
An identified person in each location who knows it slightly better than everyone else. Most questions get asked of a colleague rather than escalated, and having someone who can answer is worth more than a helpdesk.
When resistance is information
Not all resistance should be overcome. Sometimes it is a correct assessment.
If experienced staff say a process is slower, it usually is. If they say a required field is frequently unknowable at the point of entry, it usually is. If they say a workflow does not match how the work happens, they are describing a design error.
Distinguishing "this is unfamiliar" from "this is worse" requires actually listening to the specifics. Unfamiliarity fades in a fortnight. A genuine design problem does not, and treating it as an attitude problem guarantees the workaround.
The practical test: ask them to show you, at the busy hour. Complaints that survive demonstration are design feedback.
Frequently asked questions
How long should training take?
Days for daily users, in their own vocabulary, focused on their actual sequence. If it needs longer, examine the system before examining the people.
Should we train everyone at once?
Usually not. Location by location, in step with a gradual rollout, means the first site's lessons improve the second's training — and it keeps support concentrated where it is needed.
What about staff who are not comfortable with technology?
Frequently a design signal rather than a training problem. Systems that assume familiarity with software conventions exclude capable people who are good at their actual job.
How do we handle staff turnover?
Assume it. If training depends on one intensive session, every new joiner arrives at a disadvantage. A short written path through a normal day, kept current, is worth more than a comprehensive manual nobody opens.
What if adoption fails anyway?
Find out where people revert, specifically. That point is almost always a place the system is slower or cannot express something real — and it is fixable once identified.
Where to start
Before go-live, sit with the person who will use the system most, at their busiest hour, and watch them do the work on the new system.
Whatever they hesitate at, work around, or ask about twice is what training will not fix. Fix it first. Everything after that is genuinely training.
If you want a read on why an existing system is not being used, get in touch.