Low adoption is a symptom, not a diagnosis
A low active-user number does not explain why a rollout is struggling. People may not need the tool often, may be blocked by access, may complete the task elsewhere or may start and abandon a confusing workflow. More communication and training can add noise when the real problem is process, data, integration or policy.
Diagnose the intended task from trigger to outcome. Compare expected and actual behaviour for each role and location. Look at successful completion, failed attempts, workarounds, duplicate entry, support demand and what happens after the user submits. Adoption becomes meaningful when it is tied to useful work.
Do not make employee compliance the default objective. The organisation may have designed the wrong journey or bought unnecessary capability. The right response can be to simplify, integrate, change policy, narrow scope or retire the feature, not to push everyone toward a usage target.
| Signal | Possible cause | First evidence to inspect |
|---|---|---|
| Few first uses | Access, relevance or awareness | Eligibility, provisioning and task demand |
| Many starts, few completions | Journey or data friction | Step-level errors and observed sessions |
| High use, high support | Forced use with poor operability | Ticket causes and administrator work |
| Uneven use by role | Workflow or permission mismatch | Role journeys and access design |
| Use falls after launch | Weak value or unresolved friction | Repeat tasks, outcomes and local workarounds |
Confirm that the metric represents useful work
Define the task, eligible population, expected frequency and successful outcome. A monthly active-user rate is misleading when some roles act quarterly or share a service through an approved team process. Use denominators that reflect who should perform the task during the measured period.
Separate access, activation, first success, repeated success and outcome. A login proves access to an interface. It does not prove that the person completed the task or that the process produced a useful result. Track the narrowest signal that can still inform an operating decision.
Check instrumentation and privacy limits. Missing events, blocked telemetry, shared accounts or changed definitions can create a false decline. Document the collection method, exclusions and date of any measurement change before asking teams to respond to the trend.
Look for access and permission friction
Audit provisioning, licence assignment, identity, multifactor authentication, device requirements and role permissions. Sample new starters, movers, contractors and occasional users. A rollout can appear adopted among the project team while ordinary access requests wait days or send people through an unknown approval path.
Observe the first-use journey. Invitations may expire, account names may not match, mobile access may be unavailable or the person may reach an empty workspace with no clear task. Record time to first successful action and the support needed, not only whether an account exists.
Treat accessibility as an operating requirement. Test priority journeys with keyboard navigation, screen readers, zoom and the devices used by real teams. If one group cannot complete the task independently, an overall adoption average must not hide the exclusion.
Inspect workflow fit and duplicate work
Map where the task starts and ends. If people receive a request in email, collect context in chat, enter the same data in the new tool and copy the result into a legacy system, low adoption may be a rational response to duplicated work. Count handoffs and re-entry before blaming preference.
Check whether policy and system design agree. A tool may encourage self-service while managers still require an informal approval. It may offer automation that the control owner has disabled. Resolve the operating conflict or make the limitation clear so training does not promise a route people are not allowed to use.
Use the site’s enterprise application pathway to examine interfaces and ownership. Adoption problems often sit between applications rather than inside the interface receiving the usage report.
Check data quality and confidence
People abandon systems that make them verify, correct or recreate data every time. Sample the records needed for priority tasks and trace their source, owner, update frequency and error handling. Measure the work required to repair a transaction, not only the number of invalid fields.
Look for local shadow files and unofficial reference lists. They often reveal missing fields, slow updates or reports the formal system cannot produce. Do not simply prohibit the workaround. Understand the decision it supports and either meet that need or record why the local process must change.
Explain visible data limits to users. If a dashboard updates daily or excludes a location, state it near the decision. Trust improves when people know the boundary and declines when a precise interface repeatedly conflicts with what they observe.
Make learning and support task-specific
Replace the generic product tour with short guidance for real moments: first access, common task, exception, approval, correction and where to get help. Put instructions near the trigger and keep screenshots aligned with the current configuration. Measure whether people complete the task after using the guidance.
The Microsoft 365 Adoption Guide separates business scenarios, early adopters, feedback, usage and ongoing value. It is publisher-owned guidance, but its phase model is useful for diagnosing a launch that treated communication as the finish line rather than the start of operation.
Analyse support by cause and role. A falling ticket count can mean improvement, but it can also mean people gave up. Compare tickets with abandoned tasks, workarounds and local help. Feed recurring causes into product configuration, process, data and guidance backlogs rather than closing them as isolated user errors.
Test local leadership, incentives and consequences
Ask managers what behaviour they expect and what they do themselves. A leadership message cannot overcome a weekly meeting that still requests the legacy report. Identify which process, measure or approval rewards the old route and decide whether that dependency should change.
Avoid surveillance-style comparisons between teams. Differences may reflect task demand, staffing, accessibility, customer mix or rollout timing. Use cohort analysis to find a hypothesis, then speak with people and observe work before assigning a cause.
The GOV.UK beta guidance emphasises learning from real users, measuring success and ensuring support can cope as use expands. A rollout should retain the same ability to learn and change after its launch date.
Run a four-week diagnosis and intervention cycle
In week one, define priority tasks and validate access and measurement. In week two, observe representative users and review support, workarounds and data. In week three, choose one high-confidence friction and make the smallest safe change. In week four, compare task completion and outcome with the baseline.
Use a bounded software pilot pattern for material changes. Keep a control group or staggered introduction when practical, but do not delay an accessibility, security or data-integrity fix merely to protect an experiment. Record concurrent changes that could influence the result.
Stop interventions that increase support, errors or exclusion without improving the intended outcome. Scale only after the team can explain why the change worked and what conditions must remain true. A successful local fix may still need adaptation for another role or location.
- Week 1: task, population, baseline and instrumentation.
- Week 2: observation, access, workflow, data and support evidence.
- Week 3: one bounded intervention with an owner and stop rule.
- Week 4: measured outcome, limitations and scale decision.
Decide whether to improve, narrow or retire
Improvement is justified when the task matters and a fixable friction prevents success. Narrow scope when the workflow fits only certain roles or locations. Retire a feature when it duplicates a better route, lacks a meaningful outcome or costs more to govern than the value it can support.
Connect the decision to the workplace technology ROI framework where value is disputed, and to the service desk pathway where recurring support demand exposes operating problems. Adoption, value and support are different views of the same service.
A mature adoption review does not ask how to make the dashboard greener. It asks whether people can complete useful work through a service the organisation can support and govern. When the answer is no, the next action should change the system or decision, not simply increase the volume of reminders.
