Picture this sequence: your company rolled out a new CRM for the sales team, and it went live on schedule. You trained 96% of the sales force, and 412 of 430 licenses are active. The program dashboard is green, and the sponsor is already asking about the next project.
But look at what actually happens inside the CRM on an ordinary day, and the picture changes. Opportunities get entered all at once at the end of the week, so the weekly report doesn’t come out empty. The forecast’s source of truth is still an Excel file the regional manager asks for “just in case.” Salespeople log in, yes. They just don’t sell from there. (Further down, I’ll show you what all of this looks like in the data.)
This isn’t an implementation problem. It’s a measurement problem: we measure that the change arrived, not that it was adopted. To see the difference, you have to measure something else: what people do differently in their everyday work.
Why your KPIs don’t measure adoption
Most change dashboards measure program activity: people trained, communications sent, licenses activated, logins. They’re useful for knowing whether the project is moving, but they say nothing about whether people work differently.
At the other end are business KPIs: sales cycle, cost per transaction, NPS. Those matter, but they arrive late and depend on too many things at once. By the time the forecast improves (or doesn’t), six months have gone by and you can’t tell whether it was the CRM, the market, or the new manager.
There’s a gap between the two. Prosci names it well when it separates three human factors behind a project’s return: how quickly people start working with the change (speed of adoption), how many actually use it instead of building workarounds (ultimate utilization), and how well they do it compared with the design (proficiency)[1]. The problem is that, in practice, “utilization” ends up measured with logins. And a login isn’t a behavior: it’s the front door.
What’s missing is a layer in the middle that says, specifically, who has to do what differently, and how you’ll know they did it.
How to build an adoption KPI
You don’t pull an adoption KPI from the dashboard you already have. You build it backwards: start with the business outcome and work down to something someone does (or doesn’t do) on a given day at work. There are four steps:
- The business outcome. What justified the change. Example: a forecast with less than 10% variance.
- The future state. What work looks like once the change is adopted, in one sentence. Example: the sales team manages its pipeline inside the CRM, not alongside it.
- The few behaviors that hold it up. Only the critical ones: those where the old habit still wins. If you want the details on how to write one, see Anatomy of a Microbehavior.
- The trace. The evidence that the behavior happened, ideally without asking anyone. That trace is what becomes the KPI.
Before you add an adoption KPI to the dashboard, ask it four questions:
- Does it measure something people do? Not something the program delivered, like training sessions or emails.
- Does the data already exist? Ideally it lives in a system. If not, it has to be easy to collect, without setting up a separate project.
- Can you see it by team? An overall average hides where the problem is.
- Does it tell you what to do if it doesn’t move? If the number drops and you don’t know who to call, it’s not useful.
The chain also works upward. When the business outcome doesn’t move, you don’t have to guess: you look at which adoption KPI is low, in which team, and since when.
Where to get the data
Not all adoption KPIs come from the same source. To choose, ask yourself one question: does this leave a footprint in any system?
- Yes, it leaves a trace in the system. This is the best option: it’s continuous, it doesn’t depend on anyone’s memory, and measuring it doesn’t change the behavior. Examples: entry date versus meeting date, completed fields, approvals done in the workflow instead of by email.
- No, but it can be observed. Short, regular sampling: review 10 pipeline meetings, listen to 5 calls, check which screen is open in the team’s weekly meeting. It costs more, so you use it for a few behaviors and for a limited time.
- Only the person knows. A one- or two-question pulse, about what they did, not what they think. “The last time you updated the forecast, where did you do it?” measures better than “How useful do you find the CRM?”
Three rules so measurement doesn’t become yet another report nobody reads:
- Few KPIs. Three to five per future state. If you measure everything, you see nothing.
- By team, not on average. Adoption is almost never even. A 70% overall can hide one team at 95% and another at 30%, and that 30% is where the intervention is.
- With an expiration date. Once a behavior is a habit, its KPI comes off the dashboard. What you measure is the transition, not the work forever.
The full example
Back to the CRM. Business KPI: a forecast with less than 10% variance. Future state: the sales team manages its pipeline inside the CRM. Here are three critical behaviors and the adoption KPI for each:
| What has to happen | Instead of | Where the data comes from | Adoption KPI |
|---|---|---|---|
| The salesperson enters the opportunity within 48 hours of the first meeting | Entering it at the end of the week, in a batch | Creation date versus meeting date in the calendar | % of opportunities entered within 48 hours, by team |
| The salesperson updates the stage and amount after every customer contact | Updating everything before the review meeting | Change history of each opportunity | Average number of days between the last contact and the last update |
| The manager runs the pipeline meeting with the CRM on screen | Asking for the Excel file as backup documentation | Observation of 4 meetings a month + use of the pipeline view | % of meetings run from the CRM |
Look at the third row. The behavior that matters most isn’t the salesperson’s: it’s the manager’s. If the manager keeps asking for the Excel file, they’re telling the team which tool really counts. No login metric was going to show you that.
With this table, the conversation with the sponsor changes. It’s no longer “96% are trained.” It’s “the north team enters on time and the south team doesn’t, and in the south the manager still asks for the Excel file.” That’s no longer a report: it’s an action plan.
What gets measured is what gets adopted
A change isn’t adopted when the system is switched on, or when people have been through training. It’s adopted when, day to day, the new behavior beats the old one without anyone asking. To know whether that’s happening, you need KPIs that look at behavior, not program activity.
In Adopt or Survive Change, I lay out the full BEL: how to define the future state, how to choose the critical behaviors, and how to turn them into adoption KPIs connected to the ones your organization already tracks. It’s available in English and Spanish.
Sources
- Tim Creasey, “3 Factors of Change Which Define or Constrain Project ROI,” Prosci (updated August 7, 2026), prosci.com ↩
Did you find this article useful?
Thank you! Your answer helps me choose the next topics.
Do your KPIs measure adoption or activity?
In the book, I walk step by step from the future state to the critical behaviors, and from there to adoption KPIs your organization can actually track.