How do you get a team to actually adopt AI?

Why do teams drift back to the old way?

Almost never because they dislike AI. They drift back because, on a real deadline, the old way is more predictable. The new tool needs setting up for each task, the output needs heavy checking, and nobody is quite sure whether they are allowed to use it on client files. Faced with a report due at five, a sensible fee earner does what they know works.

Enthusiasm from a launch session fades within weeks if the tool has not changed the job itself. Adoption fails at the level of the task, not the attitude. Getting a team to adopt AI explores this further.

Why is adoption built into the rebuild rather than sold separately?

Because adoption support for a process that was not designed around the people using it is damage control. If the people who do the job are involved from the first day, see the new version working on their own files, and have the awkward cases fixed before go-live, most of the adoption problem is solved by the time the switch happens. The remaining effort is short and specific, and it belongs to the same team that did the build.

So there is no adoption package, change management retainer or rollout programme. There are three parts of the 30 day rebuild that do that job.

Part one: testing on live work

During the build, the new process runs on the team's current workload, not on sample files. The people who will use it compare its drafts with what they would have written, point out what is wrong, and watch it get corrected. By go-live they have already used it on real clients' work and know where it is reliable and where it needs a closer look. That familiarity is worth more than any demonstration.

Part two: training on the process itself

Training happens in week four and covers the rebuilt process, not AI in general. Users learn how to start it, what it will produce, how to review it and what to do when something is off. Reviewers learn what to check before they sign. The training page sets out what the sessions contain and why they are not a general course.

Part three: 30 days of support after go-live

The first month of real use turns up cases nobody predicted: an unusual client, a template variation, a record in an odd format. For 30 days after go-live those are handled as they come up, and the process is adjusted rather than worked around. Support is also where small frustrations are caught before they turn into a quiet return to the old method.

What happens to the old way of working?

It is retired at go-live. Running the new and old processes side by side feels safe, but in practice it gives everyone a reason not to switch. Once the team has tested and been trained on the new version, the old templates and routes are withdrawn, so the rebuilt process becomes how the job is done.

Does this help with staff using AI tools unofficially?

Often, yes. When staff paste client material into public tools, it is usually because the official way of doing a task is slow and nothing better has been offered. A rebuilt process gives them a faster, approved route for that job, with review built in. It does not replace a policy, but it removes one of the main reasons for working around one. Shadow AI looks at this in more detail, and the audit helps find which job to give people a better route for first.