Updated 22 September 2026
Training helps employees understand a new tool. Whether they continue to use it depends on how well it fits their work, what happens when they face a problem and whether the old manual steps have actually gone away.
Test the real working conditions
Illustrative example: A new purchase approval process works on a desktop computer, but a manager needs to approve requests from a phone. If the mobile route is not practical, employees may start using email again.
Simply forbidding the old channel will not solve a poor process. First make the new route usable, define what to do in exceptional situations and agree how those situations will be recorded.
Include different types of users
A pilot should test the software and the proposed way of working. Include people with different roles, levels of experience and working conditions. Test representative cases and provide a clear way to report problems.
Success with one enthusiastic team does not prove that the same rollout will work throughout the company.
Make ownership and transition explicit
Who owns the result? Which old steps can stop? Who resolves exceptions? When is it safe to turn off the former process? What happens if the new system is unavailable?
Measure work, not attendance
Track actual cases completed, workarounds, processing time, output quality and support needs. Review the findings at a pace appropriate for the process and its risks.
A successful rollout may require changes to the interface, the rules or the division of work. Ongoing support needs an owner.
Related: Workshops · How We Work · Discuss practical team adoption