How to Get Employees to Actually Use New Software
Practice4 minInnovialabs editorial team
In short
People use a new system when it solves their own tasks, they were consulted early, trained on real scenarios and the old workarounds are phased out. Success is measured by how much work actually flows through the system, not by the launch date.
Why software gets launched but not used
A new CRM, inventory tool or request portal fails more often because of people than because of code. The typical story: the system is bought or built, there is one general demo, and a month later sales reps are back to spreadsheets and messengers.
An approach that works rests on four things:
- involve key users before building or choosing the system;
- train on real tasks, not on features;
- appoint champions inside teams;
- phase out old tools and measure how much work really goes through the system.
Step 1. Involve key users early
Key users are 2–5 people who will work in the system every day: a sales rep, a warehouse clerk, an operator. Not only managers.
What to do with them:
- Interview them about the current process. Where they lose time, what they do by hand, where data gets lost.
- Show a prototype or demo before launch and collect feedback.
- Let them test with their real data, not demo examples.
If someone helped choose the fields and screens, they see the system as theirs. If it was imposed from above, they will look for reasons not to use it.
Step 2. Explain what is in it for each person
"Management needs analytics" is not enough. Answer "what does this give me personally":
- a sales rep gets call reminders and fewer lost clients;
- an operator does less copying between spreadsheets;
- a team lead sees workload without daily reports.
If a role gets no benefit and only extra work, that is a signal to simplify data entry or automate it.
Step 3. Train on real scenarios
Bad training is a tour of every button. Good training covers the 3–5 scenarios a person performs every day.
- Split training by role. An accountant does not need the sales pipeline screen.
- Short guides with screenshots or 1–2 minute videos per scenario.
- Practice in a test environment where mistakes are harmless.
- A follow-up session 1–2 weeks after launch, when real questions appear.
Step 4. Champions inside teams
A champion is an employee who knows the system better than others and helps colleagues. Often it is one of the key users.
A champion:
- answers simple questions on the spot, without support tickets;
- collects feedback and passes it to the development team;
- sets an example through their own work.
Give champions time for this role and recognize it, otherwise the enthusiasm fades quickly.
Step 5. Phase out old tools gradually
As long as the old spreadsheet works, people will use it. But switching it off abruptly on day one is risky too.
| Phase | What happens |
|---|---|
| Pilot | One team works in the new system, others the old way |
| Parallel run | A short period with data in both places |
| Read-only | The old tool stays for reference, new records go only into the system |
| Archive | Old data is migrated or archived, access is closed |
Announce the dates for each phase in advance and stick to them.
Step 6. Adoption metrics
Launch is not the result. Track:
- Active users — how many of the target employees logged in this week.
- Share of the process in the system — for example, how many new deals were created in the CRM rather than elsewhere.
- Data completeness — whether required fields are filled in.
- Time per routine operation — faster or slower than before.
- Questions and requests — what people ask most often points to usability problems.
Look at metrics per team to see where extra help is needed.
Common mistakes
- Choosing the system without the people who will use it.
- Copying every field from old spreadsheets "just in case".
- Training once and considering the job done.
- Leaving old tools without a switch-off date.
- Ignoring usability complaints instead of improving the system.