Help a pilot become part of everyday work

By the end of this lesson

• Measure use by task and locate the point where work stalls.
• Distinguish a justified rejection from an adoption barrier and choose an evidence-based change.
• Plan support that people can reach, with a pause procedure and a feedback response.

Before you begin

• Bring the permitted tasks, exclusions, success criteria and stop conditions from lesson 8. Without them, use a paper exercise rather than expose real work.
• Read the Beichen case and this lesson’s two-week task scenario. The twenty introductory records and the 340 task opportunities are different materials, not one impact sample.

Read the Beichen case and introductory data

Look for a change in the work, not just a login

Lesson 8 established which tasks may enter a trial. Now ask what happens when those tasks arise: can people use the system to finish the work? Adoption means a new way of working actually takes place. An activated account, a login or a generated answer is only evidence of contact with the system.

Beichen’s initial assistant offers checking suggestions and drafts parts requests. It cannot stop equipment, submit a request or issue an incident conclusion. Seeing a suggestion is therefore different from resolving a fault. Follow the human decision, business record and outcome check to learn which part was helped.

Frequent logins with little change may reflect an inconvenient entry point, uncertain document versions, approval delays or a manager’s instruction to open the tool daily. Investigate tasks before judging motivation. GOV.UK’s completion-rate guidance uses defined start and end points; this course adapts that idea and also counts eligible tasks that never enter the tool.

Build a funnel from the same set of tasks

The teaching scenario contains 340 eligible task opportunities over two weeks: the system was opened for 96, produced suggestions for 88, had suggestions accepted for 41, supported completion through the new workflow for 33 and had outcomes confirmed effective for 31. These fictional scenario figures are separate from the twenty JSON records and do not describe a real customer’s results.

First specify how a task is identified, how repeated opens are deduplicated, how later completions are linked and how outcomes are checked. Next divide each stage by 340 for overall coverage, and by the preceding stage to locate drop-off. Then inspect tasks at those gaps. A difference between counts identifies where to investigate, not why people stopped.

The table rounds percentages. Effective outcomes are 31/340, or 9.1% of eligible tasks, and 31/96, or 32.3% of opened tasks. Both are useful if labeled. The separate dashboard lists 120 accounts and 116 monthly active users, but does not define its account population. Do not turn those figures into coverage of the 48 engineers or six specialists.

Investigate a specific instance of non-use

Choose an eligible task where the system was not opened. Ask the person to walk through receiving the task, the information available, the first action, the choice of the old tool and eventual completion. Compare it with an abandoned attempt and a completed one. The same person choosing differently across tasks is more informative than labeling experienced staff resistant.

Logs may show denied access, timeouts or clicks, but rarely establish why someone chose another workflow. Interviews explain concerns but can contain recall errors. Compare both with the business record and retain disagreements. For self-study, write competing explanations and the records you would need. Do not invent customer interviews.

Training is not the default remedy. Someone who understands the controls but cannot open the manual needs an access review. A specialist without review capacity needs a staffing or scope decision. The comparison below helps choose the next investigation; it is not a personality classification, and several barriers can affect one task.

Make correction and justified rejection usable

Adoption does not mean accepting every suggestion. If an engineer spots a manual for the wrong equipment and rejects the advice before escalating, the control is working. Record acceptance, edits, justified rejection, unsupported workarounds and human takeover separately. Raising acceptance without task-level reasons can remove useful human judgment.

People need visible sources, a way to explain edits, access to the old workflow and someone able to handle an escalation. Microsoft’s human-AI guidelines support dismissal, correction and narrowing a service when uncertain. Here those principles apply to checking suggestions and request drafts. A rejection button that leaves the task stranded is an incomplete control.

If edits and rejections suddenly disappear, sample accepted suggestions and ask whether managers have discouraged changes. Do not infer blind trust from the metric alone, or declare the system flawless. Turn the signal into a check. Agree any performance-assessment use of feedback in advance; do not quietly convert pilot feedback into employee rankings.

Put support where the work happens

Before the pilot, people should know eligible tasks, how to pause on an unknown state, whom to contact, response hours and the fallback when no one can take over. Put that information at the work entry point and on exception screens. The operations owner should confirm response targets against actual staffing rather than copy a case number.

Estimate routine questions, source problems, access incidents and urgent pauses separately, and check coverage by shift. For illustration, thirty requests a day at eight minutes each require 240 minutes of handling time. That excludes simultaneous arrivals, investigation and breaks. It does not establish that one four-hour shift can provide the service.

GOV.UK’s support guidance connects demand, handling time and feedback to service improvement. Use it to examine capacity, not promise a universal service level. Assign someone to receive, assess, act on and respond to each pilot issue. Explain a decision not to change something too. When formal tickets decline, check whether people have moved to private chat groups.

Choose one change and define how to judge it

When resources permit only one change, choose one tied to an observed barrier, testable within the approved scope and unlikely to introduce unevaluated risk. State whose difficulty it addresses, what changes, which tasks you will observe, when you will review and what finding would challenge the explanation. Targets and deadlines must be explicit exercise assumptions or agreements with real owners.

Suppose experienced engineers fear penalties for rejecting suggestions. Examine what happened after an actual rejection. If that supports the explanation, recommend that the business owner clarify rejection and escalation rules. In the next observation period, check documented justified rejections, completion of eligible tasks and rework. If people still cannot open manuals, return to the access problem instead of repeating training.

Keep the before-and-after versions, task scope and concurrent changes. A small pilot may be better reviewed task by task than forced into a significance claim. An interpretable improvement informs the next decision. It does not establish long-term value or authorize overnight operation or another region.

Avoid mistaking attractive numbers for success

A common mistake is combining accounts, generations and training attendance into an adoption success claim. Those measures may help assess reach or plan support, but do not show how eligible work was completed. Another is interviewing only cooperative users. People who left the pilot and downstream reviewers often explain costs absent from the dashboard.

Do not replace one simplification with another by claiming that training never helps. Some people need realistic practice; some tasks should not use the system at all. Write a scoped conclusion such as “These three records support an access barrier; other shifts remain unexamined,” rather than “Users do not understand AI.”

Practice the method

Check your understanding

Write your answer before opening the explanation, then check what you might have missed.

Your record and next step

A task-based adoption funnel, workload changes by role and a support plan.

Take the task counts and support gaps to lesson 10. When the business owner pushes for expansion or the pilot fails again, explain the facts, protect people and turn disagreement into a clear choice.