Login counts prove the rollout happened. They do not prove the system is being used properly.
Every go-live report carries the same reassuring curve: activations climbing, logins climbing, tickets subsiding. Three months later the curve is still fine — while approvals are being agreed in email, data is being staged in spreadsheets and re-typed, and the system is quietly becoming a place where work is recorded rather than done.
Usage is presence. Adoption is behavior. The measures that matter are the ones that can tell those apart.
Adoption is not how many people log in. It is whether the process happens inside the system, first time, without a workaround.
Why logins are the wrong measure
Logins rise with mandates, reminders and single sign-on — none of which change behavior. A user who logs in daily to re-type what was already decided elsewhere scores perfectly on usage and zero on adoption. The metric is not wrong; it is answering a smaller question than the one being asked of it.
Five measures that correlate with real use
Process completion inside the system
Of the processes the system owns — a hire, an approval, a posting — what share starts and finishes there, without an offline leg in email or a spreadsheet? This is the closest thing adoption has to a headline number.
Data quality at the point of entry
Defaults left unchanged, mandatory fields gamed with filler, corrections arriving in batches from one department — entry-time data quality is a live feed of who has genuinely moved in and who is camping.
Exception and rework rates
Healthy adoption shows work flowing down the designed path. Rising manual overrides, reversals and corrections mean users are fighting the process — or were never enabled to follow it.
The self-service ratio
Of the tasks designed for managers and employees, how many are completed by them — and how many still route through HR, IT or a super-user acting as a human interface? Every proxy user is deferred adoption.
Time-to-competence for newcomers
How long before a new joiner completes standard tasks unaided? This measure outlives the go-live entirely — and catches the slow decay that sets in when enablement material ages out of date.
When to start collecting
Before go-live. Every one of these measures needs a baseline — the completion rate, exception rate and proxy-usage level of the old way of working — or the post-go-live numbers float without meaning. The measurement plan belongs in the implementation plan, not in a retrospective.
Then keep collecting. The riskiest month for adoption is not the first; it is whichever month the attention moves to the next project.
What to do when a measure dips
- A dipping completion rate points at process fit — find where the offline leg begins, and ask what the system made hard.
- Dipping data quality points at enablement or screen design — the users have found the fastest path through, and it is not the intended one.
- A stuck self-service ratio points at trust — usually one helpful intermediary making the system optional for everyone behind them.
- Any dip in one department only is not a system problem. It is a conversation.
VISCAP perspective
Adoption is a property of the process, not of the users. When a measure dips, fix what the system asks of people — before asking more of the people.
The pattern we see repeatedly: enablement is treated as a launch activity, measurement as a courtesy, and both are wound down at precisely the moment the real signals begin. The organizations that get durable adoption treat the first year after go-live as part of the implementation — staffed, measured and owned.
The question to put on the dashboard
Not “how many people used the system this month?” but “how much of the process happened anywhere else?” When the honest answer is “almost none”, the go-live is finally finished — whatever the calendar said.