Why training alone stalls
The pattern is familiar. Licences were bought, a training session was run, a few enthusiasts use the tools well, and most people tried them twice and went back to the old way. The problem is rarely that staff do not understand AI. It is that nobody has connected the tools to the actual work: the monthly report that pulls from three systems, the intake form that someone retypes, the triage queue that needs a first draft and a check.
Fixing that takes engineering and coaching at the same time. An engineer alone builds things nobody adopts. A trainer alone teaches skills that have nowhere to land. This role is one person doing both, inside your organisation, under your leadership.
What the work involves
I work through a cycle that repeats for each workflow:
- Map. With the team lead, write down how the work is done today, how long it takes, what data it touches and who checks the output. This is also where some candidates get dropped: the data is too sensitive for the approved tools, or the task is rare enough that it is not worth automating.
- Build. Use the simplest thing that works: a well-structured assistant with the right instructions and reference material, a prompt library, a script that removes copy-and-paste between systems, or a small integration. Every workflow has a review step where a person checks anything that leaves the team or changes a record.
- Coach. Sit with the people who will use it, on their own work, and adjust the workflow to what they actually do. Train one maintainer per workflow in how it works and how to change it.
- Measure. Compare against the baseline after a few weeks of use. Some workflows stick; some need rework; some get retired. All three are useful results.
The signature deliverable
You end with an implementation-and-coaching remit, a workflow backlog and an adoption handover. The backlog is the working document throughout. Illustrative example:
| Workflow | Team | What gets built | Review step | Owner after | Adoption measure |
|---|---|---|---|---|---|
| Monthly ops report | Operations | Assistant with data extracts and report template | Ops lead approves before circulation | Ops analyst | Hours to first draft; corrections at review |
| Supplier query triage | Procurement | Drafted replies from policy library | Buyer edits and sends | Procurement lead | Share of queries using the draft |
| Meeting actions | Programme office | Notes-to-tracker script | Owner confirms each action | PMO coordinator | Actions logged within one day |
Illustrative example showing the format, not a record from a client engagement.
How acceptance is judged
The sponsor and the team lead for each workflow agree the baseline and adoption measure before it goes live, and review it together a few weeks later. A workflow is accepted when its owner and maintainer can run and change it without me, and when the measure shows it is in use. A workflow that is not adopted is either reworked or retired, and the reason goes in the backlog so the next attempt starts better informed.
Ownership and handover
Workflows belong to the teams that use them, not to me or to IT by default. Each has a named owner, a maintainer, a runbook and a measure. The adoption handover to your sponsor covers the live workflows, their measures so far, the remaining backlog ranked by value, and the policy or access issues that blocked others.
When to choose something else
If no one internally owns enablement, start with the fractional AI enablement lead. If you want a defined pilot with one team delivered as an outcome, see AI enablement. To build a network of internal champions, use the AI champions programme. If the requirement is a single integration between systems, workflow automation is scoped for that. To measure what you have already rolled out, start with the adoption measurement worksheet.