How to Measure Tool Adoption: Why the Active User Count Lies
Adoption reports almost always open with the active user count. It climbs nicely in month one, levels off in month two, and becomes the main argument in any conversation about whether the rollout worked. What it never answers is the question the rollout was meant to answer in the first place.
Logging in is not the same as working in a system. A person can open the interface every day, glance at the task list, and keep doing the actual work by email. On the report, that person is an active user. In the process, they're absent.
Adoption is measured by the share of scenarios that run all the way through the tool, not by the number of people who log into it. The difference is not cosmetic: the first metric drops when people find a workaround and rises only on real migration, while the second grows from curiosity and almost never drops. Self-reported use measures a different quantity and correlates weakly with actual use.
Why the Usual Adoption Metrics Overstate the Picture
Every popular adoption metric has its own way of inflating the numbers, and all of them point the same direction.
Active users. Grows from curiosity and from administrative mandate. It doesn't distinguish someone who spent a full workday in the system from someone who logged in to check whether anything new had shown up.
Records created. Grows through duplication: an employee creates a record for the sake of reporting and keeps working the old way. That record exists, but it doesn't reflect a single decision.
Satisfaction surveys. Measure attitude, not behavior. People answer politely, especially when the survey isn't anonymous, and they answer about intent rather than fact.
Support ticket volume. Falls both when a rollout succeeds and when people abandon the tool. Without a second metric there's no way to tell the two apart.
| Metric | How it inflates | Replace it with |
|---|---|---|
| Active users | Counts logging in as work | Completed scenario rate |
| Records created | Counts duplication as use | Share of records with required fields filled in |
| Satisfaction | Measures attitude instead of behavior | Workaround rate |
| Support tickets | Falls on both success and abandonment | Same workaround rate |
The third column is the whole set you need. Three metrics instead of four, and all three drop when people find a workaround — something none of the familiar ones do.
Why You Can't Just Ask People If They Use the System
The temptation to replace measurement with a survey is strong: a survey is cheaper than logs and doesn't need an integration. Methodologically, this question was settled a long time ago.
Self-reported system use and objectively logged use are two distinct constructs that correlate weakly with each other. Relying on subjective self-reports to assess system adoption is methodologically unreliable.
Some honesty is owed here: the full paper sits behind a paywall, and what I read was the metadata page with the abstract, not the paper itself. That's why I'm not quoting exact correlation coefficients. The conclusion I'm keeping is qualitative, and practice confirms it: the number a person gives you in a survey and the number the system shows you are different things, and conflating them is a mistake.
What Counts as a Completed Scenario
The idea of a completed scenario is borrowed from usability testing practice, where it's formalized as the core metric.
The success rate — the share of target tasks completed successfully — is set as the key, top-line metric of product interaction: if a user couldn't get a task to completion, every other number is secondary.
This is a methods guide for lab testing on samples of four or five people, not a large-scale adoption measurement in production use; carrying the concept over to production data is an analogy I'm making on purpose, and I want to say so outright. The value is in the definition: a scenario is either completed or it isn't, with no state in between. It's exactly that binary quality that makes the metric resistant to interpretation.
What Unused Software Actually Costs
The economic side of this question is measured separately, and the numbers keep climbing.
The share of wasted spend on cloud subscriptions rose by 10 percentage points year over year, and 59% of surveyed specialists said that waste grew specifically on AI tools.
The report is sponsored by an IT asset management tool vendor, so there's a commercial incentive to make the problem look acute, and the full calculation method sits behind a form; the exact share of unused licences isn't disclosed on the open pages, only the spend trend is. I'm using it as a directional indicator: formal license coverage is growing faster than actual use, and the gap keeps widening.
How to Build an Adoption Measurement System
Before we look at the third metric, it's worth saying something about the first: how you define it is a management decision, not a technical setting. The "process the request" scenario can count as completed the moment the request is closed in the system — or it can count as completed once the customer has received a response and that's been logged. The first definition produces a nice-looking number; the second produces a useful one. The choice between them gets made once, and it determines what people argue about at every planning meeting for the next year.
The second metric — the share of records with required fields filled in — exists as insurance against gaming the first. Without it, you can easily get a high completed scenario rate simply because records get created pro forma: the status changes, but the content stays empty. Together, the two metrics resist that kind of gaming, because closing a scenario on paper is easy, while filling required fields with meaningful values is noticeably harder.
The third metric — the workaround rate — is the most inconvenient and the most valuable of the three. It isn't counted inside the tool itself but from the traces of the workaround: how many documents got created outside the system, how many decisions were made over email, how many tasks turned up somewhere else. An exact figure is hard to get, but the trend is available, and the trend is enough.
You should define the first metric before launch, together with the definition of what counts as a completed scenario. After the fact, that definition always bends to fit whatever data came in — I wrote separately about process observability and taking a baseline "before" measurement.
Four Steps to an Honest Adoption Report
Define the completed scenario before launch
One sentence, a binary flag. Once you launch, the definition will bend to fit the data.
Take active users out of the report
Don't add to it — replace it. As long as the metric stays in the report, it's what people will argue about.
Find the traces of the workaround
Documents, emails, tasks outside the system. The trend is enough; you don't need an exact number.
Don't ask people how often they use it
Self-reported use and system logs measure different things. Ask what's getting in the way instead — that's a question a survey answers honestly.
An adoption metric that can never drop measures nothing. Check yours: what behavior from your employees would make it fall?
Frequently Asked Questions About Measuring Adoption
How do you measure adoption of an enterprise system?
By the share of scenarios that run all the way through the system, not by the number of active users. A scenario counts as completed when every step of it leaves a trace in the system: creation, status change, decision, outcome. Two more metrics round out the picture — the share of records with required fields filled in, and the workaround rate, the share of work that bypassed the tool.
Why is the active user count a bad metric?
Because it doesn't distinguish logging into a system from working in it, and it almost never drops: it grows from curiosity, from administrative mandate, and from the interface simply sitting open in a background tab. A metric that can't decrease when people stop using a tool isn't measuring adoption — it's measuring access.
Can you assess adoption with a survey?
Not frequency of use — self-reported use and objective system logs have long been shown to measure different quantities and correlate weakly. A survey works well for a different question: what's getting in the way of using the tool. There, answers are specific and verifiable, and the result turns straight into a fix list, while a self-rated frequency gives you neither.
How do you calculate the workaround rate?
From traces in other channels: documents created outside the system, decisions made over email, tasks opened somewhere else. An exact figure is hard to get and isn't necessary — the trend over a few months is enough. If this rate grows while usage numbers look formally strong, it means the tool has been adopted as a reporting exercise, not as a working one.
The set of three adoption metrics and the method for finding workaround traces is my own generalization from CRM rollouts at three companies (a digital agency, a seasonal corporate-gifts manufacturer, an online booking platform) and from collecting manager-level usage statistics in Alego.Digital's own products. No quantitative measurement of the workaround rate was taken during those rollouts, so this article contains no internal numeric metrics. Every figure here comes from an external source with the method stated.
- Straub D., Limayem M., Karahanna-Evaristo E. Measuring System Usage: Implications for IS Theory Testing. Management Science, 41(8), 1995. ideas.repec.org
- Nielsen J., Budiu R. Success Rate: The Simplest Usability Metric. Nielsen Norman Group, 2001, rev. 2021. nngroup.com
- Flexera. 2026 State of ITAM Report, June 2026 (survey of 512 specialists). flexera.com