Training attendance does not prove adoption

The programme reports that 60 employees completed training. Two weeks later, managers still see work arriving through the old process. The attendance number is accurate, but it does not explain whether people had a chance to use the new workflow or what happened when they tried.

Change adoption measurement starts with a real task and a defined opportunity to perform it. Training is preparation; use, successful completion and business benefit need their own evidence.

Separate people who had an opportunity from people still waiting

Consider a fictional equipment service desk. All 60 employees attended training. During the observation window, 40 had at least one eligible equipment-handover task. For each of those 40 people, the team examines the first eligible task: 28 used the new workflow and 12 used the old route or a workaround. The other 20 had no eligible task during that window.

The unit here is a person at their first eligible task, not the total number of logged attempts. A frequent user must not count as several newly adopting employees.

Four of the 28 new-workflow attempts did not complete within the observation window. That needs investigation. It does not establish that all four people rejected the change or that training caused the other 24 to succeed.

These are illustrative numbers, not research findings or a benchmark.

Define what completion means

GOV.UK's completion-rate guidance explains why a service needs a clear transaction start and finish, including the treatment of assisted use. Its broader measuring-success guidance supports combining performance information with evidence about users' needs.

For this equipment process, “completed” could mean that the correct item and recipient are recorded, the receiving employee acknowledges the handover, and the required inventory record is updated. That proposed definition needs agreement with the actual service owner.

A saved draft would not meet it. Nor would an apparently completed screen if operations had to repair the record later. Keep the task result and any subsequent correction connected.

Investigate the old route before judging the employee

The 12 old-route cases might contain several different explanations: access was unavailable, the new process did not support a real exception, a local manager instructed staff to use the old route, or the employee did not understand the change. These are hypotheses to test, not inferred reasons.

Review representative cases with the people doing the task. Compare their account with the relevant access, process and completion evidence. A missing feature needs a product or process decision; another training session alone may not address it.

Also record assistance for successful new-route cases. A task completed with a colleague's help can be successful, while still revealing a support demand that a rollout plan must accommodate.

Use the next review to change something specific

The programme's next report should retain attendance, then show the opportunity group, workflow used, completion and unresolved causes separately. State the observation window and how repeat attempts are treated. If the cohort or task definition changes, do not compare the percentages as though the denominator stayed fixed.

An outcome baseline helps make later comparisons meaningful. Whether adoption produces the intended business benefit is a further question, covered in delivered versus beneficial.

For the service desk, the immediate decision might be to fix access for an affected team and observe its next eligible tasks. That is a more precise response than celebrating attendance or labelling every old-route user resistant.