How to Drive Digital Adoption
You drive digital adoption by making the new way easier than the old way for the person doing the work, then removing the old way, then measuring whether the process is running in the system.
TL;DR
- Non-adoption is usually rational. Find out which of six causes is operating before pushing anything, because the fix is different for each.
- Process fit is the strongest lever and it is set before go-live. A workflow built around the software's defaults gets worked around.
- Data the team trusts is the second. Trust takes weeks to build and one visibly wrong report to destroy.
- Close the old path deliberately, on a date, after the new one handles every case the old one did.
- Training is the fifth lever, not the first. No session holds against a system that is slower to use than the spreadsheet it replaced.
- Measure the process, not the logins. Records at the right stage, approvals in the workflow, reports without reconciliation.
Everything else is support for those three. Training helps. Communication helps. Executive sponsorship helps. None of them holds against a system that is slower to use than the spreadsheet it replaced.
Start by finding out why they are not using it
Non-adoption is usually rational. Before anything is pushed, establish which of these is happening, because the fix is different for each.
A task that took four clicks now takes eleven, and the extra seven produce data somebody else needs. The person doing the work absorbs a cost and receives no benefit. The most common cause, and the most fixable.
They opened the system, found three duplicate records and an outdated address, and concluded it cannot be trusted. That judgment forms in the first week and is expensive to reverse.
A required field blocks a legitimate case nobody described during discovery. An approval stage exists for a scenario that occurs twice a year and now blocks the other three hundred.
No one is responsible for the system, so questions go unanswered, and an unanswered question sends a person back to the method that does not require asking.
They attended a general session covering every module, most of which was irrelevant, and never received a procedure for their own work.
The old path is still open and nobody has said it is closing.
The six levers, in order of strength
1. Process fit
The largest lever, and the one that is set before go-live. A workflow designed around how the work actually runs gets used. A workflow designed around the software’s defaults gets worked around.
This is why the design stage takes the process decisions before the technology decisions, and why discovery is done by interview rather than questionnaire. The workaround a person has built for themselves is the requirement, and a design that ignores it is designing against the user.
Where a system is already live and not being used, the correction is the same work done late: watch the task being performed, find the point where the person leaves the system, and fix that point.
2. Data the team trusts
People do not use a system whose records they know are wrong. Clean, deduplicated, validated data at go-live is not a data-quality nicety. It is an adoption mechanism.
Where migration quality is uncertain, it is better to migrate less and validate it than to migrate everything and hope.
3. Closing the old path
While the spreadsheet still exists and still works, a portion of the team will keep using it, and the two records will diverge until neither is reliable.
Closing the old path is a management decision rather than a technical one, and it should be scheduled and announced rather than allowed to happen by attrition. It also has a precondition: the new path has to actually work for every case the old one handled. Closing it early, before the exceptions are covered, produces workarounds in a new hiding place.
4. Ownership
Someone owns the system. Someone owns each process running in it. Someone answers questions.
An unanswered question is an adoption event. The person waiting for it either stops and asks, which costs them time, or proceeds the old way, which costs the rollout. Naming an owner and publishing where questions go removes a daily reason to revert.
Ownership also needs authority over the process, not only over the technology. An owner who cannot decide whether a field should be required is not an owner.
5. Role-based enablement
Train a person on the work they do. Train administrators separately, because administering a system is a different job from using it.
A written procedure per process, in the language the team uses, matters more than the session. Sessions decay. A procedure someone can open in month four does not. The test of an SOP is whether a new hire could run the process from it without asking.
6. Measurement
You cannot correct what you are not watching, and login counts are not the measure.
Watch these instead:
- Records created at the correct stage, rather than back-filled at the end of a week
- Approvals happening inside the workflow rather than by message and then recorded later
- Reports produced without a person reconciling sources first
- The parallel spreadsheet no longer being updated
- Exceptions being handled in the system rather than routed around it
Each of these is a specific behaviour with a specific failure attached to it. A drop in any one points at a part of the design to correct.
Why training ranks fifth
Training is the lever most projects lead with and the fifth strongest of six. It transfers instructions. It does not make a slow process fast, wrong data right, or an unanswered question answerable.
The first ninety days
Adoption is decided in the period immediately after go-live, and it is the period most engagements are not scoped for.
Weeks one and two. Watch the work being done. Not a survey, not a check-in call. Sit with the people running the process. Every point where somebody leaves the system is a defect in the design, and finding them now is cheap.
Weeks three to six. Correct the workflow against what was observed. This is expected work, not a sign the build was wrong. A required field blocking a real case, an approval stage nobody needs, a missing exception path. Fix them fast enough that people see the system responding.
Weeks six to twelve. Close the old path, once the exceptions are covered. Move to measuring the behaviours above rather than watching directly. Start the enhancement backlog and hand it to the internal owner.
After that. The client owns it. The backlog is theirs, the measures are theirs, and the administrator has been trained to make changes without calling anyone.
Common mistakes
- Announcing adoption as a mandate. A memo requires use without changing the reason for non-use. Better: find the point where people leave the system, and fix that point. Mandates produce compliance theatre, which looks like adoption in a usage report and is not.
- Running a survey instead of watching. People describe the process they are supposed to follow. Better: observe the task. The gap between the two is the finding.
- Closing the old path too early. The spreadsheet is deleted before the system handles every case. Better: cover the exceptions first, then close it on an announced date.
- Treating corrections as failures. Change requests in month two get resisted as scope creep. Better: budget for them. Some of the design will be wrong, and the speed of the correction is what the team is judging.
- One owner for everything. A single administrator owns every process across every department and becomes a queue. Better: one system owner, plus a process owner per process, each with authority over their own rules.
- Measuring logins. Better: measure the behaviours listed above.
- Ending the engagement at go-live. Better: scope and pay for the stabilization period in the original agreement, because a correction that has nowhere to go becomes a workaround.
Frequently asked questions
How do you get people to use a system they did not ask for?
Involve them in the design stage, so it is not a system they did not ask for. Where that has already been missed, watch the work, find where they leave the system, and fix it. Adoption follows the path of least resistance, and the fastest way to drive it is to make the intended path the easiest one.
How long does it take for adoption to stick?
The behaviours are visible within ninety days. Where the parallel spreadsheet has stopped being updated and reports come out without reconciliation, it has held.
What if leadership does not use it?
It will not hold. Where the executive asks for a number by email rather than opening the dashboard, everyone below learns the dashboard is optional. Sponsorship is not a communication exercise; it is whether the sponsor uses the system.
Should we run a pilot?
Often, and with one condition: pick a team whose process is representative rather than one that is enthusiastic. A pilot on a friendly team confirms the design works for friendly teams.
How do we handle the person who refuses?
Establish first whether the refusal is rational. Someone who has been running a process for eleven years usually knows a case the design does not cover. Where it is a genuine gap, fix it. Where it is not, it becomes a management question rather than a systems question.
Is a digital adoption platform worth it?
It addresses one failure mode, which is a user not knowing which button to press. Where the problem is process fit, data trust or a closed feedback loop, in-app guidance does not reach it. Fix the ranked causes first and evaluate the tooling afterwards.
What do we measure in the first month?
Records created at the correct stage, approvals running inside the workflow, and whether the old spreadsheet is still being updated. Those three answer most of the question.
Key takeaways
- Non-adoption is rational. Diagnose which of the six causes is operating before you push anything.
- Process fit is the strongest lever and it is set before go-live, not after.
- People do not use a system whose data they know is wrong, and they decide that in the first week.
- The old path has to be closed on a date, and only after the new one handles every case the old one did.
- An unanswered question is an adoption event. Name an owner and publish where questions go.
- Training is the fifth lever. It is necessary and it is not the mechanism.
- Measure whether the process runs in the system. Logins measure attendance.
Where to go next
What is digital adoption sets out the definition and the scope. How digital adoption works covers the six stages, of which the two after go-live are the subject of this article. The Digital Adoption engagement is scoped through Enable and Stabilize for the reasons above.