Why Your Team Isn’t Using Your New Software—and How to Help
Diagnose software adoption problems, train each role on real tasks and support the team after launch.
When a team returns to spreadsheets after a software launch, begin by observing the work. Low usage can come from a poor fit, missing permissions, unreliable data, unclear expectations or training that never covered daily tasks.
Another presentation will not resolve all of these problems. Identify the obstacle first, then decide whether to change the configuration, the process, the training or the management arrangements.
Watch one task from start to finish
Choose people from different roles and ask each to perform a common task. Observe where they stop, ask a colleague, open a spreadsheet or postpone the work. Make clear that you are checking the process, not examining the employee.
Ask what happens in an unusual case: a corrected order, a rejected request or an absent approver. A workflow can appear complete in a demonstration and still fail during an ordinary working day.
Record the specific obstacle and its owner. “Users need training” is too vague. “The warehouse role cannot record a partial delivery” gives you a problem to investigate.
Match the intervention to the cause
| What you observe | What to investigate | A possible response |
|---|---|---|
| Users cannot finish a step | Permissions or missing configuration | Correct access and retest with the user |
| People distrust the report | Data quality or unclear definitions | Reconcile a sample and agree the calculation |
| Staff know the screens but use a spreadsheet | A missing workflow or duplicate reporting requirement | Remove the gap and agree the official record |
| Everyone asks one colleague for help | Training and operating instructions | Practise tasks by role and write a short guide |
| Managers accept updates outside the system | Expectations and accountability | Agree where work is recorded and model that behaviour |
Avoid treating a permissions failure as resistance to change. Equally, once the system supports the work and users are prepared, management needs to make the expected way of working clear.
Train each role on its own work
A salesperson, an approver and a finance user need different practice. Build a short session around the tasks each role performs, using realistic examples in a safe training environment.
Demonstrate one task, let participants do it, then introduce an exception. Ask them to explain what they would do if they could not complete the step. This reveals gaps that a passive walkthrough can miss.
For an illustrative service company, the coordinator practises recording a request, the supervisor assigns it, and the technician submits completion evidence. Each person then sees how their action affects the next person's work.
Give users a guide they can use during work
Write instructions for tasks rather than documenting every screen. A useful page states when to use the task, what information is needed, the steps, the expected result and who to contact when it fails.
Keep screenshots current and assign someone to maintain the guide. A short accurate instruction is more useful than a long manual that describes an earlier version of the system.
Retire the old process deliberately
Agree when the new system becomes the official record. Confirm that essential workflows work, users have access, important data has been checked and support is available.
If parallel running is necessary, define its duration and how records will be reconciled. Leaving two official processes open indefinitely creates duplicate work and uncertainty about which record is correct. Keep a documented fallback for serious incidents without encouraging routine work outside the system.
Follow up on work completed, not logins
Look at whether requests are recorded, approvals happen in the system and reports use current data. Login counts alone cannot show that the process works.
Review recurring questions with the team. Group them into defects, configuration changes, unclear responsibilities and training needs. Assign an owner and a next action to each.
Before replacing the software, check whether improving setup and support would solve the problem. If the product truly cannot support critical work, revisit software selection with evidence from these observations.
Smart's team enablement and training starts with real tasks and follows through after training. Request a meeting with one example of work your team still does outside the system.