AI Staff Training

Adoption failure and oversight decay, which are the two ways a working deployment stops producing value.

Adoption failure looks like this: the tool is rolled out, a webinar is offered, a third of staff attend, half of those try it, and by week six the licence count and the active user count have separated. The usual cause is not resistance to AI. It is that people were shown the product rather than taught the new version of their own job, so the first friction sent them back to the old way, which still worked.

Oversight decay is more serious and quieter. Review discipline is high in week one and lower in week ten, because the outputs are mostly right and the review starts to feel like a formality. That is exactly when a wrong output gets through. The countermeasure is not exhortation, it is teaching people what the specific failure modes look like so that review becomes pattern recognition rather than a compliance ritual.

Both problems are cheaper to prevent than to diagnose. Training is a small line next to a licence and it is frequently the difference between a deployment that renews and one that does not.

It is for organisations at or near go live, and for organisations that have already gone live and can see the adoption curve flattening. It is also for compliance functions who have an oversight standard on paper and no mechanism to make it real, which is a common position after a governance project completes.

It is not for a three clinician practice adopting an ambient scribe. That deployment needs a shared hour, a written rule about who reviews what, and a check in after two weeks. We would rather tell you that than sell a programme. The scribe use case page covers the review discipline in enough detail to do it yourself.

It is also not a general AI literacy course. There is a real place for that and it is not what this is. This is workflow specific training tied to systems you have deployed or are about to deploy, which is why it is built after the tool is chosen rather than before. If nothing has been chosen yet, the earlier engagements are the readiness audit and vendor selection.

Week one, observation. We watch the workflow being run, both before and with the agent where it is already live. Sessions built from a process document rather than from observation always miss the informal steps, and the informal steps are where the agent will surprise people. We also collect real examples of the tool getting things wrong, which become the most valuable material in the curriculum.

Week two, build. The curriculum is written per role, using your screens, your terminology and your escalation path. Each role gets a session outline, materials, a one page reference card and a short competency check. The check is deliberately practical: spot the error in this output, decide whether this one needs escalation.

Week three, delivery and handover. Sessions run by role, ninety minutes each, on site or remote. Then a train the trainer session with whoever will own it afterwards, and handover of everything in editable form. Larger organisations usually run delivery over several weeks against clinic schedules, which we plan around rather than against.

Where the deployment is phased across departments, delivery is phased with it. Training people four months before their department goes live wastes the session, and everybody has been to that meeting.

The full list is above. Three parts matter most in practice.

The failure mode catalogue. Real examples, from your environment where possible, of the agent producing something wrong, with the tell that would have caught it. This is the single most effective teaching material available, and it is why week one is spent observing rather than writing.

The one page reference card. Per role, designed for a desk rather than an intranet. What you must check, what you must never do, who to tell, and the two or three failure patterns most likely on this workflow. If a card needs a second page, the content is wrong.

The competency check. Short and practical. It exists for two reasons: so you know who has actually been trained rather than who attended, and so there is a completion record. Under the HIPAA Security Rule workforce security awareness and training is an explicit requirement, and a record showing who was trained on what is the kind of evidence that makes an audit shorter.

CARE is our four step method: Chart, Architect, Run, Evaluate. Training belongs to Run, and it is what most often decides whether Run produces a usable result.

Chart and Architect produce the workflow map, the oversight standard and the thresholds, through the readiness audit, the deployment roadmap and the governance framework. Training is built directly from those, which is why it is workflow specific rather than generic.

Run is the bounded pilot. A pilot where half the participants have not been taught the review standard does not test the agent, it tests the training gap, and that result gets misread as a product failure. Training is scheduled to land in the fortnight before go live for each group, not earlier.

Evaluate compares against the baseline. Two of the metrics that usually matter, active use rate and review compliance, are training outcomes rather than product outcomes, and separating them is what lets you fix the right thing.

You can build this yourself, and the structure below is the part worth copying. The principle is that each role learns its own failure modes and nobody sits through anyone else's.

Two rules apply across all of them. Everyone must be able to name the escalation route from memory, because a route that has to be looked up will not be used during a clinic. And everyone must be told plainly what the agent is not allowed to do, since prohibitions are remembered far better than procedures.

Clinician sessions fail in predictable ways. Five things reliably prevent it.

Do not open with the technology. Open with the workflow and what changes in it on Monday. A session that begins by explaining what a language model is has spent its goodwill on material nobody needed.

Show it failing early. Counterintuitively this builds trust rather than destroying it. A clinician who has seen the tool produce a confident wrong answer knows what they are reviewing for. A clinician who has only seen the demo will assume review is a formality, and will be right until the day they are not.

Use your own cases. Vendor demo material is chosen for clarity and does not include the mumbled history, the interrupted consultation or the patient with three problems and twelve minutes. Your own examples are the ones that make the room lean in.

Be explicit about accountability. The clinician signing the note remains responsible for it, and saying so plainly removes an anxiety that otherwise sits under the whole session. It also frames review as clinical work rather than as an administrative check, which is the framing that survives week ten.

Keep it to ninety minutes and make attendance worth the time. Long sessions are rescheduled, and rescheduled sessions become optional. Give people something usable in the first fifteen minutes.

One further point, applying to any patient facing deployment. Several states now regulate disclosure when generative AI is used in patient communications, and clinical staff need to know the rule in the places you operate before they are asked by a patient. The California page covers one of the more developed examples, and the phone agent page covers how disclosure works in practice on a live call.

A fixed fee stated in a written proposal before the work starts, scaled to the number of roles and sites rather than charged per seat. There is no per seat licence on the material and no recurring fee: the curriculum is handed over in editable form and you own it. The strategy call that produces the proposal is free.

We take no vendor commissions, so the curriculum has no incentive to be longer than the job requires or to be delivered on anything in particular. Where your existing learning management system can carry the modules, it should, and we will build for it.

After handover the programme is yours to run for new starters and for refreshers. Most clients run it themselves from the train the trainer pack. Refreshers matter more than people expect: model and product updates can change behaviour under a familiar interface, so a short refresher tied to the vendor's release cycle is worth scheduling. If the oversight standard the training teaches does not exist yet, build it first through AI governance and compliance. If the deployment itself is not yet sequenced, that is the deployment roadmap. And if you want to see where staff readiness sits against your other constraints before committing to anything, the readiness assessment scores operations as one of its four categories and is free.