Getting Staff to Use a New System: Adoption and Training That Work
Staff adopt a new system when it makes their own job easier and when they can use it confidently from the first day. So involve them before launch, in mapping the process and testing the system. Train them on their real daily tasks, in their language, close to go-live. Name a champion in every team, set a firm date after which the old spreadsheet becomes read-only, support people closely in the first weeks, and watch whether the work is really happening in the system.
Adoption is not a training session at the end. It is a set of decisions made from the start of the project.
The short answer
- Design for the people entering the data, not just the managers reading the reports.
- Involve users early: in process mapping and in acceptance testing.
- Train by role and task, hands-on, with realistic data, shortly before launch.
- Champions in every team, with time set aside and a direct line to the supplier.
- Retire the old tools on a set date, so the new system is the only way.
- Measure real use, and treat shadow spreadsheets as feedback, not defiance.
“A system nobody uses is the most expensive one you own. Adoption isn’t a training session at the end; it’s a decision you make at the start about whose job gets easier.” — Abdulqader Wahiba, founder and CEO of ZAWAT
Why staff work around new systems
Most adoption failures have ordinary causes:
- The work moves, but the benefit doesn’t. Staff enter more data so that managers get better reports, and nothing gets easier for them.
- Training came too early or was too general. A demonstration of every screen two months before launch is forgotten by go-live.
- The old way is still available. If the spreadsheet still works, people will use it under pressure.
- Nobody nearby can help. One unanswered question can send someone back to the old method for good.
- Leaders don’t use it. If the general manager still asks for “the Excel”, the team hears the real instruction.
- The language is wrong. An Arabic interface that reads like a machine translation tells Arabic-speaking staff the system was not built for them.
Make it useful to the people doing the work
A well-known study by Fred Davis, published in MIS Quarterly in 1989, examined why people accept or reject new information systems. It found that how useful people perceived a system to be correlated more strongly with their actual use than how easy they found it, and that ease of use may matter partly because it makes a system seem more useful.
For an owner, the lesson is practical: show people how the system helps them, not only where to click. Better still, design it so that the person entering data gets something back: no more phone calls to check stock, a delivery note that prints itself, a commission figure they can see without asking. Mapping the process before you buy software is where those benefits are found.
Involve users before launch
People support what they helped shape. Invite the staff who do the work into the process-mapping sessions and the user acceptance testing. They will catch problems no manager would, and they become the natural champions when the system goes live.
Training that sticks
- By role, so each person learns only the screens and tasks they will use.
- By task, following their real daily work: “receive a delivery”, “approve a request”, “close the day”.
- Hands-on, in a test copy of the system with realistic data, not watching a presenter click.
- Close to go-live, within days rather than months.
- Short sessions, repeated, rather than one long day.
- Quick-reference guides of a page or two per task, in Arabic and English, with screenshots. Many teams in Oman include staff whose first language is neither, so clear visual guides help everyone.
- Train the trainers: champions learn first and help teach their teams.
Champions in every team
Choose one person per team who is respected, curious and patient, not necessarily the most senior. Give them time to help colleagues, early access to the system, and a direct channel to the supplier for questions and problems. Champions turn a hundred small questions into a few useful reports, and they make help available where the work happens.
Retire the old way on a set date
Agree a cut-over date, announce it early, and keep it. After that date, the old spreadsheet becomes read-only and the old WhatsApp group for orders is archived. Keep the old records accessible for reference, but make sure new work can only happen in the new system. Running both in parallel for long means double work and two versions of the truth.
Support closely in the first weeks
The first weeks after launch decide the habits. Plan for:
- someone available on the floor, or on call, to answer questions immediately;
- a short daily check-in with champions to collect problems;
- fast fixes for the small irritations that cost people time;
- visible responses, so staff see their feedback change the system.
This early support should be part of the plan and the support agreement, not an improvised favour.
Measure real use
| Signal | What it tells you | What to do |
|---|---|---|
| Users who rarely log in | They are working elsewhere | Ask why; check whether they were trained for their real tasks |
| Work recorded outside the system | Shadow spreadsheets are back | Find the gap the spreadsheet fills, and close it |
| Slow completion of key tasks | The design or the training is wrong | Watch someone do the task; fix the bottleneck |
| Repeated questions on one topic | A training or design gap | Update the guide; simplify the screen |
| Managers asking for exports | Reports in the system are not trusted | Fix the reports, then insist on using them |
Lead by example
The fastest adoption signal in any company is what its leaders ask for. If managers review figures in the system, approve requests in the system and refuse to accept “the Excel version”, the team follows. If they don’t, no amount of training will compensate. Abdulqader Wahiba’s advice to owners is simple: stop accepting “the Excel version” on the day the system goes live. For family-owned companies, digital transformation in a Gulf family business covers how to bring the senior generation along.
Frequently asked questions
How much training do staff need? Enough to complete their own daily tasks confidently in the new system, and no more at first. Short, role-based, hands-on sessions close to launch, followed by support on the floor, work better than long general courses.
What if some staff refuse to use the new system? Find out why. Resistance usually points to a real problem: extra work with no benefit, a missing case, a confusing screen. Fix that, involve them, and make the new system the only way to do the work after the cut-over date.
Should we keep the old system running as a backup? Keep the old records available for reference, but stop new work in the old tool after cut-over. A parallel system that stays live becomes the place people go when they are busy.
When should training happen? As close to go-live as possible, ideally within days, so that what people learn is still fresh when they need it. Champions should be trained earlier, during testing.
How do we know the system has been adopted? When the work happens in it: regular logins, transactions recorded in the system rather than outside it, reports trusted without exports, and falling numbers of basic questions.
Launching a new system and want your team to actually use it? ZAWAT builds bilingual business systems designed around the people who do the work, with training and support for launch. Book a call.