The point is that I become unnecessary.
Training is not an add-on I sell alongside the build. It is the thing that decides whether the build survives. A system nobody understands is a system that quietly stops being used the first time it does something unexpected.
So every engagement includes teaching, and every session runs on your own tools and your own documents. Staff leave with work they have actually finished — not notes about work they might do later.
Half-day introduction
What these tools are actually good at, where they fail, and what that means for the work your team does on Monday. Run on your own documents, not generic demos.
Deep programme
Several sessions across weeks, building real capability in the staff who will maintain what I hand over. They leave having finished work, not having watched someone else finish it.
Policy and governance
What to permit, what to prohibit, and how to write that down so it survives the next hire. Built around the data you actually handle rather than a generic policy template.
What I teach people to refuse
Knowing where not to use it is half the skill.
Most AI training teaches people to prompt. That is the easy half. The half that protects you is judgement: recognising when the output is confidently wrong, when a task carries too much consequence to delegate, and when the honest answer is that a human should do this.
Staff who can make that call are the reason a rollout does not end in an incident report.
Before you ask
Common questions
We already pay for AI tools nobody uses. Can you fix that?
Often, and it is usually cheaper than buying anything else. Unused licences are almost never a tool problem — they are a problem of nobody knowing which of their actual tasks the thing is good for. Training on your own documents and your own workflows fixes more of that than another subscription will.
Read the full answerHow many people can you train at once?
Half-day introductions work well up to about thirty people. The deeper programmes are deliberately smaller — eight to twelve — because everyone needs to finish real work on their own material rather than watch someone else demonstrate. If you need to cover the whole team, I usually run a wide introduction first and then take the handful of people who will own the systems through the deeper track.
How do you stop it being forgotten a month later?
By training on real work rather than exercises, and by making sure at least two people in the building can change the system rather than one. Sessions run on your own tools and your own documents, staff leave having actually finished something, and the documentation lives in your wiki rather than in a deck I email over afterwards.
Bring me the process that wastes the most time.
A first call takes thirty minutes. You will leave it knowing whether automation is worth doing at all in your case.