User Adoption

Short answer: User adoption describes whether people really use a new system after launch. The technology team can install and set up a system that works correctly, while staff keep doing the same work in spreadsheets, email or the old tool. A company reaches adoption when the intended users do the intended tasks in the new system as their normal way of working. They also keep doing so after the launch period.

A company can measure adoption at three levels. The first is access: how many intended users log in during a given period. The second is task completion: what share of the relevant work actually goes through the new system. That work might be orders, approvals or sales opportunities. The third is skill: whether people use the system correctly and efficiently. Error rates, rework and time per task show this. Login counts alone can overstate adoption, because people may log in and then do the real work elsewhere. Workarounds are the most direct sign of low adoption. They include side spreadsheets, data typed in twice and approvals sent by email. User adoption is the outcome that change management works toward. Change management covers the activities, such as communication, training and leadership support. Adoption is what the company can measure afterward.

Measurement starts before launch. The project team defines who the intended users are and which tasks should move into the new system. It also agrees what level of use counts as success, and by what date. After launch, system logs show logins and the number of records each team creates. The team compares these with the total volume of that work from other sources, such as the number of orders shipped. The gap shows how much work still happens outside the system. Short surveys and conversations with users explain why the gaps exist. Typical reasons are missing fields, slow screens, unclear training or managers who still ask for the old report. The team then fixes the problems for specific teams or tasks. Once the new route works, it closes the old one.

A company introduces a new sales system for 60 salespeople. After two months, 54 of them, or 90%, log in each week. But the sales team created 500 new sales opportunities in that period, and only 210 of them, or 42%, are in the new system. The rest stayed in personal spreadsheets, because the weekly forecast meeting still used a spreadsheet. The sales director starts running the forecast meeting only from the new system. In the following month, salespeople record 172 of 200 new opportunities, or 86%, in it.

Most of the benefit of a new system depends on the work moving into it. Leaders decide which adoption measures to set before launch and who owns them after the project team leaves. They also decide when to switch off the old route. Budgets that stop at launch often leave no time or money to fix the problems that adoption measures reveal.

Forcing people to use a system without fixing its real problems can produce compliance on paper. Staff then enter incomplete or poor records just to satisfy the rule. Low adoption can be a sign that the system does not fit the work. In that case, more training will not help. Monitoring how individual employees use a system may raise data protection questions, or questions for employee representatives, in some countries.