Go-live is the middle of a project, not the end of it. The system works, the data is migrated, the training session happened — and then the actual test begins, which is whether people use it on a busy Thursday when the old way is still available and faster for them personally.

That is the problem this service exists to solve, and it is a human one rather than a technical one.

What we actually do

Train on your systems, with your data — not a vendor's demo environment, which teaches people a workflow they will never use again. Write documentation people open, which means short, task-shaped and current rather than a 90-page manual nobody has read. Coach the people others ask, because every team has two or three of them and they determine adoption more than any session does. And run AI skills courses for technical and non-technical teams.

AI training, done on real work

This has become a large part of what we teach, and the framing matters more than the tooling. The course we run is built around a single distinction: use AI on the tasks that make up your work, not on the job you are accountable for. Teams that internalise that get faster safely; teams that do not either avoid the tools or over-trust them, and both are expensive.

We wrote up the lessons from a recent course for a client's technical team as a short series, starting with assistant, not replacement. For non-technical teams the starting path is different and we set it out in AI skills for non-technical teams.

Nobody has ever successfully told a customer that the AI wrote the bit that broke. You still sign the work.

Why one session is not training

A single pre-go-live session teaches the interface to people who have no context for it yet, at the moment they are least able to absorb anything. Two weeks later they have real questions and nobody to ask.

So we split it: a short session before, and a longer one after people have hit their first real problems, when the questions are specific and the answers stick. It is a small scheduling change that materially affects whether a rollout holds, and it is the pattern behind adoption is the project.

What good adoption looks like

The old spreadsheet stops being updated without anyone enforcing it. Questions move from how do I to can it also. The people who were loudest in resisting are training others six months later. And nobody has to be chased for a report, because the report is easier to produce than to avoid.

Who this is for

Businesses going live with something new, businesses whose last rollout did not stick and who suspect they know why, and teams who want to get properly capable with AI rather than experimenting individually and inconsistently. The last group is increasingly the largest, and it is worth doing deliberately before everyone has quietly answered the question for themselves.