When Staff Won't Use the New System: A Complete Approach to Training, Champion Users, and Driving Adoption

The system took months to build, passed acceptance, and went live. A month later you walk into the office and see staff still keeping records in spreadsheets and sending orders through group chats, while the new system is only opened now and then by managers looking at reports. Staff not using a new system after launch is one of the most frustrating stages for many companies, and one of the least planned for in advance.

The problem is usually not the system itself but how it was introduced. During development everyone focuses on features and schedule, and launch is treated as the finish line. For front-line staff, though, launch is where the change begins. They have to set aside tools they know well, learn new steps, and spend extra time figuring things out in the middle of a busy workday. Without support, going back to the old way is the most natural choice.

What follows explains how to plan adoption from before launch: how to design training, how to develop champion users, how to write user guides, how to arrange a period of running old and new side by side, and how to use usage tracking and a feedback loop so the system actually gets used.

Why staff don’t use the new system

Understand the causes first, then address them directly. In practice, the common causes fall into a few groups:

• They don’t know how to use it. Training happened once, there was too much to remember, and there is nobody to ask when a problem comes up.
• It feels like more hassle. The new system adds a few steps or fields, so for the individual it is slower than the old way, while the benefits go to other departments or to managers.
• It can’t handle exceptions. The system only covers the standard process; special orders, returns, and back-orders have no matching function, so people fall back on the old way.
• They don’t trust the data. Errors turned up in the data early on, and since then people would rather keep their own copy.
• Nobody requires it. Managers still accept reports in the old format, so the old way has not actually been replaced.

Of these, only the first can be solved by training. The others need process design, system adjustments, and management support. That is why system adoption is management work and cannot be left only to IT staff or the development vendor.

Preparation that starts before launch

Adoption planning is best started late in development, at the same time as acceptance testing, rather than remembering a week before launch that training needs to be scheduled.

What to decide before launch:

1. An adoption lead: a manager with the authority to coordinate across departments, responsible for driving the rollout, tracking progress, and clearing obstacles.
2. Launch scope and sequence: whether the whole company switches at once, or one department or one process goes first. A phased launch carries less risk and lets the first department build experience.
3. When the old way retires: the date after which old forms, files, and group chats are no longer accepted.
4. Support channels: who staff go to with problems in the early days after launch, and how they report them.
5. A definition of success: what counts as adoption being complete, for example a process being done entirely in the system with no off-system records.

Point three is the most often skipped and the most important. As long as the old way is still allowed, staff have no reason to put up with the inconvenience of learning the new system.

Designing training that works

At many companies, training means gathering everyone in a meeting room while the vendor walks through every menu from first to last. Two hours later everyone returns to their desk with a vague impression. That approach has limited effect.

Principles for effective training:

• Separate classes by role. Sales, warehouse, accounting, and managers each only need to learn the parts they will use. If one course teaches everyone, everyone feels half of it is irrelevant to them.
• Organize by task. Don’t introduce features menu by menu. Teach by work situation, such as “how to create a new order when one comes in” or “how to handle a customer’s return request.”
• Hands-on practice. Everyone completes tasks themselves in a test environment rather than watching the trainer demonstrate.
• Use real cases. Use the company’s recent real orders or documents as practice material so staff can connect it to their daily work.
• Spread it out. Several shorter sessions, with real use of the system in between, are absorbed better than one long session.
• Cover exceptions. Include the most common special situations in the course; these are often what staff worry about most.

Schedule training close to launch. Train too early and people have forgotten by launch day; train too late and staff see the system for the first time on the day it goes live.

Champion users: growing the drive from inside

Champion users are the people in each department who learn it first, use it first, and can help their colleagues. They are key to whether adoption succeeds.

How to choose champion users:

• They know the department’s actual work and how exceptions are handled.
• Colleagues trust them and are willing to ask them questions.
• They are reasonably open to new tools; they don’t need to be the most computer-savvy person.
• Their manager is willing to give them time for this, rather than piling it on top of their existing job.

What champion users do:

1. Take part in acceptance testing, getting familiar with the system early and reporting problems.
2. Receive more in-depth training, including how to resolve common problems.
3. Help put together department-specific instructions and FAQs.
4. Act as the department’s first line of support in the early days after launch.
5. Collect colleagues’ feedback and report it regularly to the adoption lead.

The most common mistake is naming champion users without lightening their existing workload. During adoption, colleagues will ask them questions constantly, and if no time is set aside for this, they burn out quickly and may even become the people most eager to go back to the old way.

Writing user guides staff will actually read

A thick manual organized by feature menu is rarely read from start to finish. The guide that actually gets used is the one where you can find the answer quickly when you hit a problem.

How to write a practical user guide:

• Organize by work situation. The table of contents reads “How to create a quote” and “How to handle a partial shipment,” not “Menu one, menu two.”
• One task per page. Each page covers one thing, with clearly numbered steps and a screenshot for each step.
• Flag the error-prone spots. For example, “Getting this field wrong affects the month-end report, so double-check it.”
• Include an FAQ. Collect the questions staff actually asked during training and the early days after launch, and keep adding to it.
• Put it somewhere easy to find. A help link inside the system, an internal shared folder, or pinned in the department’s group chat.
• Record short videos. Key operations recorded as screen videos a few minutes long are more intuitive than text.

Single-page user guide template:

• Task name:
• Applies to roles:
• When you’ll need it:
• Steps (with screenshots):
• Notes and common mistakes:
• Who to contact if you get stuck:
• Last updated:

Assign someone to maintain the guide. Whenever the system is adjusted or a process changes, the guide needs updating too; an outdated guide causes more mistakes than no guide at all.

Arranging a parallel-run period

Running in parallel means that after the new system launches, the old way is kept for a while as a point of comparison and a fallback.

The benefits of running in parallel: you can compare old and new results, confirm the new system’s data is correct, and have a way back if a serious problem appears.

The cost of running in parallel: staff have to do the work twice, which adds to their load, and if it goes on too long it is easy for people to assume the old way is still the main one.

Principles for arranging the parallel period:

• Define the parallel scope clearly. Decide which processes run on both tracks and which switch over directly; don’t run everything in parallel.
• Set an end condition and a date. For example, once a full month-end close has run and the comparison shows no significant differences, stop the old way.
• Treat the new system as the reference. If old and new results differ during the parallel period, track down the cause rather than assuming the old one is right.
• Make the old system read-only. After parallel running stops, keep the ability to look up historical data, but no longer allow new entries.

If the new system involves moving data from the old one, plan how to reconcile the data and when to switch over at the same time; see Data Migration When Replacing Systems.

Usage tracking and the feedback loop

After launch, keep watching: is the system actually being used? Where are people getting stuck?

Indicators you can track:

• Logins: whether staff in each department and role log in regularly.
• Volume of key processes completed: for example, whether the number of orders created in the system each day matches the actual volume of business.
• Off-system records: whether anyone is still passing data through the old spreadsheets or group chats.
• Support requests: the types and number of problems staff report, and which features they cluster around.
• Processing time: whether certain processes take much longer in the new system than expected.

The point of these indicators is not to blame people who aren’t using the system but to find where things are stuck. When one department’s usage is notably low, it usually means a process there is not well handled by the system, or training fell short.

Building a feedback loop:

1. Champion users collect their department’s feedback each week and organize it into a list.
2. The adoption lead holds a short meeting every week or two to review the indicators and the feedback.
3. Feedback is sorted into three groups: needs more training, needs a process adjustment, or needs a system change.
4. Items that need a system change are reported to the development side in a clear format; see how to report bugs to your vendor. Requests for new features go through the change process to set their priority.
5. Report back to the staff who raised each item so they know their input was taken seriously.

Step five is the easiest to neglect. When staff report a problem and hear nothing back, they won’t report the next one; they will quietly return to the old way.

Managers decide whether adoption succeeds

Finally, the example managers set matters. If managers still ask staff to submit reports in the old format or reply about order status in group chats, the new system will never be used seriously.

What managers can do:

• Use the system themselves to look up data and reports, and stop asking for separately compiled files.
• Open the system directly in meetings to discuss the numbers.
• Recognize staff who use it proactively and suggest improvements.
• Stop accepting the old format after the retirement date for the old way.

Adopting a system is like any organizational change: it takes time, support, and persistence. If you are preparing to launch a new system, or it is already live but usage is not what you hoped, talk to NETVANA. All of our software services are quoted after a consultation. Beyond development itself, we can help plan champion user training before launch, user guides, and support arrangements for the early days after go-live; see the software services overview for details.

Further reading: For how to accept a system before launch, see How Software Acceptance Works. For moving old data into a new system, read Data Migration When Replacing Systems. For what the internal team must commit when adopting an ERP, see ERP Selection for Small and Medium Businesses. For how to report errors you find after launch, see How to Report Bugs to Your Vendor. And for what to prepare early in a project, see the Client Checklist Before a Software Project Kicks Off. To get staff to actually look things up in a new system, read Building an Internal Knowledge Base System.