Why do teams not use the AI tools they have been given?
Most firms that bought licences did the sensible sounding thing: they rolled out a tool, ran a session or two, and waited. A few enthusiasts took to it. Everyone else went back to how they worked before. That is not stubbornness. A fee earner with a full week and a deadline will always choose the method they know works over one they would have to figure out. A general purpose assistant asks them to invent a new way of working on top of their existing load, and very few people have the slack to do that.
The underlying problem is that a tool is not a process. Nothing about the job changed, so nothing about behaviour changed. We cover this in more depth in a tool is not a process and why AI rollouts fail.
What actually drives adoption?
People adopt a new way of working when three things are true at once: it saves them time on something they dislike, it is easier than the old way from the first day, and the people around them are doing it too. Adoption efforts fail when they rely on only one of these, usually enthusiasm.
That points to a different approach. Instead of spreading a tool thinly across everything, pick one job, make the new way clearly better for that job, and make it the standard for the whole team doing it.
What are the steps to get a team using AI?
- Choose one job everyone recognises. Pick a recurring task that eats time and that people complain about, such as write-ups after client meetings, monthly client reports or first drafts of proposals. If you are unsure which, choosing a process to automate sets out the criteria.
- Involve the people who do it. Sit with them and watch the job as it really runs. They know the shortcuts, the workarounds and the parts that genuinely need judgement. People back a change they helped shape.
- Rebuild the job, not just the prompt. Put the AI step inside the workflow: the right inputs are gathered automatically, the draft comes out in the firm's own template, and the review step is built in. Nobody should have to remember a clever prompt.
- Train on live work. Run training with the team's own current files, not generic examples. The session should end with people having produced real work the new way.
- Retire the old way. Set a date after which the old templates and methods are no longer used for that job. An indefinite overlap lets the old habit win.
- Name an owner. One person is responsible for the process working, for answering questions in the first weeks and for collecting fixes.
- Check use every week. Look at whether each piece of live work went through the new process. Where it did not, find out why and fix the cause.
What role should partners and directors play?
Senior people set the real standard, whatever the memo says. If a partner receives an AI drafted report and rewrites it from nothing, the team learns that the new way is not trusted. If they review it, correct what needs judgement and approve it, the team learns that this is how work is done now.
So the most useful thing leadership can do is simple: use the new process for the part of the job they touch, say so openly, and give reviewers clear authority to approve good drafts rather than polish them endlessly. Senior sign off is also where quality is held, which we set out in reviewing AI output on client work.
How do you handle resistance?
Treat resistance as information. It usually has one of a few causes, and each has a fix.
- "It is slower than doing it myself." Often true for a general tool. Fix the process until it is genuinely faster for this job.
- "I do not trust what it produces." A fair concern. Show where every figure and statement comes from, and keep a named reviewer on every client output.
- "This will take my job." Be honest about what is removed. It is usually assembly and retyping, not the expertise clients pay for.
- "We are not allowed to put client data in it." Give a clear answer through a written policy. See writing an AI policy.
- "Nobody told me how." Training was too general. Repeat it on the person's own work.
How do you tell whether adoption is working?
Measure use and outcome, not attitudes. The useful questions are narrow:
- What share of live pieces of work for this job went through the new process this week?
- How long did the job take compared with before?
- How much did reviewers have to change in each draft, and is that falling?
- Which exceptions forced someone back to the old way?
If use is falling, something in the process is harder than the old way. Find it and fix it rather than running another awareness session. For turning time saved into a figure the partners will recognise, see measuring return on AI.
Is training enough on its own?
Training helps people use a process well. It does not create the process. A team trained on a general tool still has to work out, job by job, how to fit it into their day, and most will not. That is why we train people on a rebuilt job rather than on a tool. The training versus implementation comparison sets out when each makes sense.
What happens after the first job?
Once one process is running and trusted, the second is much easier. The team has seen the pattern work, the owner has learned how to support it, and scepticism has something concrete to answer it. Move to the next job only when the first one is genuinely the default. Adding a second before the first has bedded in divides attention and weakens both.
If you want a starting point, the audit estimates the hours your fee earners lose each week and names the single process to tackle first.