A digital adoption platform overlays guidance on top of an application: step-through walkthroughs, tooltips, in-context help, and analytics on what people actually click.
They are frequently bought at the point where a programme has realised its training will not be enough, and they are frequently expected to solve a problem they cannot reach.
Match the tool to the question being asked
Day one generates four distinct kinds of demand, and they are not equally tractable to guidance software.
| The question | Can a DAP answer it? |
|---|---|
| “How do I…” — navigation and sequence | Yes, very well. This is what the tool is for, and it scales infinitely |
| “Is this right?” — a confidence check on the output | No. It can confirm the steps were followed, not that the answer is correct |
| “This will not let me…” — a genuine block | No. Authorisations, missing data and design gaps need a decision, not a tooltip |
| “The system is wrong” — a defect | No, and a walkthrough insisting otherwise is actively irritating |
The first row is genuinely valuable and it is the highest-volume category, so a DAP can remove a large share of support contacts. But the categories it cannot reach are the ones that actually stop work, and they still need a person. A support model sized on the assumption that the platform covers everything will be understaffed in exactly the cases that matter.
Guidance is not the same as capability
A walkthrough produces correct execution while it is running. Whether it produces competence is a separate question, and the evidence on skill acquisition points the other way.
Capability comes from repeated attempts at a realistic task with feedback — the mechanism behind the effect William McGaghie and colleagues found for simulation with deliberate practice. Following a prompt is not an attempt in that sense; the judgement is supplied by the tool. Which is fine for a task performed twice a year, and a problem for one performed hourly, where the organisation wants fluency rather than dependence.
The useful rule: use guidance for the rare-and-procedural, and practice for the frequent-and-consequential. Using it for both produces a workforce that can operate the system only while being told how.
What it can hide
A bad process. This is the significant risk. If a task takes eleven steps because the design is poor, a DAP makes eleven steps tolerable — and removes the pressure that would have got it fixed. The complaints stop, the metric improves, and the underlying inefficiency is now permanent and invisible.
A capability gap. Completion rates rise while unaided completion does not. If the organisation measures the first and not the second, it will believe capability was built when dependence was built instead.
The real adoption question. DAP analytics are genuinely good telemetry, and that creates a familiar trap: a rich, precise, automatically generated number becomes the reported measure of adoption. Walkthrough completions are easy to count and will be optimised once reported — which is the ordinary fate of a load-bearing indicator, and the reason a measure that can be satisfied without the underlying thing being true should never carry the construct alone.
Where it earns its cost
- Large, dispersed or high-turnover populations, where repeat training delivery is the dominant cost and onboarding never stops.
- Rare procedural tasks — quarter-end, annual processes — where nobody retains the steps and a job aid is the right answer anyway.
- After the programme closes, as part of the answer to who onboards new joiners once the training function has gone.
- As a diagnostic. The analytics show where people abandon a flow, which is a good pointer to process problems — provided somebody is tasked with acting on it rather than reporting it.
Bought for those reasons, with the maintenance cost understood — every screen change breaks the walkthroughs — a DAP is a sensible operational investment.
Bought to compensate for a design nobody had time to fix, or to substitute for practice on the tasks people perform every day, it will do exactly what it is asked and quietly make the underlying problem harder to see.
More on capability and support in the Adoption Risk Hub, or read why training completion and adoption are different measurements.
