Business practice
AI adoption.
Buying the tool was the easy part. You end up with named use cases, the people who own them, and adoption you can see in the work rather than in a licence count.
A licence count is not adoption. It is a receipt.
Most rollouts stall in the same place. The tool arrives, a few people find a use for it, everyone else goes back to the way they worked in March, and the renewal comes around with no way to say whether any of it helped. Nobody was against it. It was just never anybody's job.
Adoption happens when a specific piece of work is named, a specific person owns it, and the result shows up somewhere you already look. We start from the work rather than the tool: which tasks AI should touch, which it should not go near, and what has to be true before either answer changes.
The approach
Three words we work by.
Choose.
We start with your work, not the feature list. A short pass across the tasks your team repeats, sorted by how much time they take and how much judgement they need. What comes out is a small set of candidates worth trying and a clear line around the work AI should stay away from, written down so nobody has to guess.
Own.
Every use case gets one name against it. Not a committee and not a champion network, one person who is accountable for it working and who has the authority to change how the task is done. Where the owner needs guardrails to say yes safely, they get them in writing.
Measure.
Each use case carries a measure chosen before the work starts, in a number your team already tracks. Hours on a task, turnaround on a request, rework caught before it reached a client. That is what tells you adoption is real, and it is the number that decides whether to widen, hold or stop.
The work
Four workstreams, in sequence.
Use case selection
A short inventory of the repeated work in your team, scored on time spent and judgement required. You get a ranked shortlist of what AI should touch, and an explicit list of what it should not, so the boundary is a decision rather than an assumption.
Owners and guardrails
Each shortlisted use case is assigned to a named owner, with the data rules and review steps they need to run it without asking permission twice. Where your AI use policy already answers a question, we point at it rather than writing a second version.
Build and pilot
The top use cases get built and run on real work with the people who will use them. Prompts, steps and checks written down as procedure, not as a demo, so the second person to do the task gets the same result as the first.
Adoption tracking
The measure for each use case is wired into where the work already happens, so adoption is visible without a survey. You leave with a simple view of what is being used, by whom, and what it changed, which is what a renewal conversation actually needs.
Related reading.
All insights
Governance
Shadow AI is already in your firm. Here is the map.
The median hundred person company shows between fourteen and twenty two distinct generative AI services in its browser telemetry. One or two of them are approved. The gap is not a technology problem and it is not solved by blocking domains, because the work that drove people to those tools does not go away when
Governance
The AI policy your insurer is about to ask about
Cyber and professional liability renewals added a question this year, and most firms cannot answer it yet. A defensible answer is shorter than people expect, but it has four specific parts, and a policy missing any one of them will not survive the follow
Questions
Asked before, answered plainly.
No. In most cases the tool is fine and the missing pieces are a named use case and an owner. We start with what you already pay for, and we only raise the question of a different tool when a use case your team cares about genuinely cannot be done with it.
From your work and your obligations, not from a general policy. Client data with confidentiality terms, anything a regulator or insurer will ask you to explain, and any judgement your clients are paying a named professional to make. Those get written down as out of scope, so the boundary is visible rather than assumed.
It changes the order, not the answer. We ask people what worries them before anything is chosen, and use cases that would take work away from someone go to the bottom of the list. The first ones we build are the tasks people already describe as the worst part of their week.
A number your team already looks at moving in the right direction. Turnaround time on a recurring request, hours logged against a task, drafts that reach a reviewer in better shape. If the only evidence is seats assigned or logins counted, that is a licence count, and we will say so.
Weeks, not quarters. The first use case is chosen and running inside the engagement, with its measure taken before and after. If the number does not move, that is a result too, and it is a cheaper one to learn now than at renewal.