AI Adoption That Lasts: 25 lessons learned the hard way

Part 1What turns the dial

01Leaders go first, and they have to actually use it

Every programme we've seen move quickly started with the leadership team. Most organisations know this and book a leadership briefing. The bit they miss is that going first isn't the same as using it.

What we've seen. In one programme, some leaders were visibly using AI in their own work. Others asked their teams why AI couldn't do something, without ever having tried it themselves. Staff noticed the difference within weeks. A leader who is privately anti-AI, or simply doesn't get it, will undermine a programme without saying a word: people read what leaders do, not what the launch email says.

What to do.

• Run a session for leaders before anyone else, and make it hands-on. Show live, real-time demonstrations of what's possible now, using the leaders' own kind of work. When people see how easy something is once you understand the model, the conversation changes.
• Ask each leader to do one real piece of work with AI before the wider launch, and to talk about it.
• Have leaders give explicit permission to experiment. Curiosity is the most useful trait a team can have with AI, because these systems keep doing things nobody planned for. People need to hear that trying things is the job, not a distraction from it.

Where we come in. Our leadership sessions are run by people who use these tools all day and can show what's possible on the spot, then answer the hard questions that follow.

02Make the first session mandatory, and invite people by name

Voluntary training fills with the people who were going to use AI anyway. Everyone else waits to see if it matters.

What we've seen. At one client, attendance at the foundation session stalled. When the session was made mandatory and invitations went to people individually, by name, the cohort filled within days.

What to do.

• Make the foundation session mandatory for everyone who needs the basics, with a faster track for experienced users (lesson 22). Keep it short (see lesson 6).
• Send named invitations from someone people report to, not a generic all-staff email.
• Make everything after that voluntary. Once people have the basics, the pull takes over.

03Start with the tools people already have

It's tempting to design the programme around the most powerful licence. Most of your people won't have it.

What we've seen. In a Copilot rollout, far more people picked up the basic chat tool in the first month than the plan had assumed, several times more. The programme was designed so that everything started with what works on any licence, and the paid licence was there for the people who needed it.

What to do.

• Design the foundation for the licence most people have.
• Check every exercise and demo against what your audience can actually access. Content built for features people don't have is wasted, and it frustrates them.
• Treat paid licences as a step people earn through use, not a starting point.

04Teach how AI works, not where the buttons are

Tool training feels productive and goes out of date fast. The menu moves, the feature gets renamed, a new model behaves differently, and people who learned the clicks are lost again.

What we've seen. The people who get furthest aren't the ones who know a particular tool best. They're the ones who understand what an AI model is actually doing: why it gets things wrong, what it needs from you, why the same request gives a different answer tomorrow. With that understanding they can pick up any tool, and they know why the button moved. Mindset beats tool knowledge every time.

What to do.

• Start the learning with how AI works, once people know what's allowed (lesson 10): what a large language model is, what it's good and bad at, why context matters, where the risks are.
• Teach techniques that work in any tool, then show them in your tool.
• Keep a short, plain explanation of the risks in front of people from day one.

Where we come in. Our AI Primer starts here, and our platform keeps the mental model current as the tools change underneath it.

05Start with what's in it for each person

Organisations want productivity. People want their Tuesday afternoon back. If you only sell the first, you won't get the second.

What we've seen. The moment adoption takes off for an individual is when they find one thing that saves them real time in their own job. After that they go looking for more. Programmes that lead with organisational ROI get polite attention. Programmes that help each person find their own use case get people coming back.

What to do.

• Build use-case discovery into the first weeks: help each person find two or three uses in their own work, not generic examples.
• Ask "what do you do every week that you'd happily never do again?" It's a better starting point than any list of use cases.
• Let the business case build up from the bottom. Personal wins add up to team wins.

Where we come in. We run use-case discovery as a structured activity, and we have a library of real use cases by role to start the conversation.

06Short, frequent and in a fixed slot

Long training days feel thorough, and a launch event gets attention for a day. Most of both is forgotten by the following week. Small pieces, in the same slot every week, build a habit.

What we've seen. A leadership session briefed at four hours met a chief executive who expected two. We cut it to three, with a break every hour and the most useful material first, and we've designed in small pieces ever since. At one client, a voluntary webinar in the same slot every week drew around a quarter of the organisation, week after week. We've also run single broadcasts to thousands of people verify: ~4,500, Mike's figure and regular sessions of 100 to 200 verify. The format that works best is about 15 minutes of content, then 15 to 45 minutes of questions answered by a practitioner.

What to do.

• Break learning into units people can finish in a few minutes, and give them something to come back to. We use a deck of cards, each linking to a short lesson.
• Pick a weekly slot and keep it. Same day, same time.
• Keep the content to around 15 minutes and spend the rest on questions. The questions tell you what to teach next.
• Make AI a standing item on every team's agenda, and ask the chief executive to open each all-hands with an AI use case.
• Produce it properly: a studio set-up, with someone producing alongside the presenter.

Where we come in. Our platform is built around short learning cards, and we run studio-produced webinars with practitioners taking questions live.

07Train on people's real work, function by function

Generic training gives everyone the same examples. Nobody's job looks like the examples.

What we've seen. With one insurer's marketing team we ran two half-days. The first mapped their real work and the ideas worth trying. Between sessions we sent a written summary and a small piece of homework. In the second, everyone loaded and used an AI skill on the day, four small teams each built a skill for their own work, and another team tested each one.

What to do.

• Run sessions by function or team, not just company-wide.
• Split it in two: discover first, build second, with time to think in between.
• Have people work on their own material, not exercises.
• Swap-test whatever gets built. If another team can't use it, it isn't finished.

Where we come in. Our functional workshops follow this pattern and leave teams with something working, not just notes.

08Build skills, not one-off prompts or agents

A good prompt helps one person once. A skill (a reusable, shareable set of instructions an AI follows for a particular job) helps everyone who does that job, every time, and gets better as you improve it.

What we've seen. When champions at one client were encouraged to build agents, they built quite a few, and most of them had exactly one user: the person who built them. Meanwhile the teams that built shared skills got repeatable results, and the major vendors, Microsoft included, are now building skills into their own products. Whatever tool you're on, this is where it's going.

What to do.

• Teach people to turn a task they repeat into a skill.
• When the output is wrong, fix the skill, not just the output. Otherwise you fix the same thing again next week.
• Keep look and task separate: one skill for your house style, another for the job.
• Give every shared skill a named owner, so it improves in one place.

Where we come in. We teach skill-building from the foundation level up, and our own business runs on them.

09Put practitioners, not trainers, in front of people

The best moment in any session is when someone asks the question that isn't on the slides. Whether that moment helps or frustrates depends on who's at the front.

What we've seen. In one programme's sessions, more than a hundred questions came from dozens of different people, and most of them were specific: about their tools, their data, their job. Rooms are mixed: some people have never used AI, others have been using it at home for years. The advanced users rated generic sessions lowest. What all of them valued was someone who could answer from experience.

What to do.

• Choose people who use AI daily in their own work to run sessions, not people who learned the material last month.
• Leave long Q&A time. If your presenter can't fill it, that tells you something.
• Capture every question. They become your FAQ, your next session and your measure of what's landing.

Where we come in. Everyone who presents for us builds with these tools every day. That's why we can keep the Q&A open.

Part 2What to set up

10A short manifesto, before anything else

Before people learn anything, they need to know what's allowed. Without it, the cautious don't start and the keen go off on their own.

What we've seen. The question people most often ask in their first session isn't how to do something. It's "am I allowed to?" Organisations that answered that up front moved faster than those still drafting a policy.

What to do. Write one page that says:

• Using AI isn't cheating. It's expected.
• You own the work. Whatever comes out of AI, you're accountable for it, so check it.
• Here are the edges: what data never goes into which tools, and where to ask if you're unsure.
• Here's where to go to learn more and to share what you've found.

Make sure everyone has the same understanding of the risks, so they know where the edges are, and build the security rules into the training itself, not a separate document nobody reads.

Where we come in. We help leadership teams write this in a single session, and we build it into every piece of training that follows.

11Start governance light and build it out, with the people who can say no

Governance programmes that try to approve every tool in advance either never finish or block everything. The risk isn't in the tool. It's in how it's used. And every function that can stop the programme (legal, information security, data protection, HR, procurement) will stop it if they first meet it when something goes wrong.

What we've seen. At one client the most useful idea was a short pre-use check: a handful of questions about accuracy, accountability, data and unintended consequences, which sorts each use case into go ahead, check first, or don't. Where organisations set out to design a full governance framework before starting, it absorbed months. The steering group that worked best had technology, information security, people, legal, data protection and procurement in it from the start, and met regularly. Where the group lapsed, the programme drifted.

What to do.

• Start with the manifesto (lesson 10) and a short pre-use checklist.
• Tier by use case: low-risk work moves fast, scrutiny goes where the stakes are real.
• Put the "no" functions on the steering group from the start. Meet monthly, and give the group one job: clearing blockers fast.
• Decide early who answers the awkward questions: whether to disclose AI use in client work, how long prompts and outputs are kept, how meeting transcripts can be used.
• Grow the governance as use grows. It doesn't need to be finished on day one. Agents that send, buy or change things will need more checks than a chat window.

Where we come in. We bring the questions organisations usually only discover later, and we weave the answers into training so people know where the green lane is.

12A baseline on day one, and the person who owns your usage data

If you don't know where people started, you can't show how far they've come. You'll also want usage numbers, and they're harder to get than anyone expects. Most organisations remember both three months in.

What we've seen. A short form at the start and end of each session is enough. Across our own live sessions, participants report more than twice as many people feeling confident using AI after working with us.^* On a Microsoft rollout, the usage data was weekly, organisation-wide and partly exported by hand verify: current Microsoft reporting position. One call with the person who looked after the admin centre agreed a weekly export and a six-month baseline, after months without usable numbers.

What to do.

• Ask three things before people start: how confident they feel, how much they know, how often they use AI. Ask the same three afterwards, and keep it to two minutes.
• Find whoever administers your AI tools and their reporting, and get them on side in week one.
• Agree what data you can get, how often and in what format before you promise anyone a dashboard, and take a historical baseline before the programme starts.

* Self-reported by participants on our welcome and exit forms, 504 and 120 responses, January 2025 to October 2026.

Where we come in. Our platform runs welcome and exit forms for you and shows programme leads the change.

13Have the answers ready before the questions arrive

Once people understand how AI works, the same questions come in every organisation: Is it safe? Does it learn from my data? Can I use it with clients? What happens to my transcripts? If every answer has to be worked out from scratch, people wait, or they guess.

What we've seen. The questions are remarkably consistent. We now issue a library of well over a hundred standard questions with model answers at the start of a programme, to be adapted to the organisation's own approach.

What to do.

• Prepare answers to the common questions before launch.
• Adapt them to your policies and tools. A generic answer to "can I use this with client data?" isn't good enough.
• Publish them somewhere people can find, and add to them every week.

Where we come in. We start every programme with our FAQ library and keep it current.

14Train and equip your champions, don't just appoint them

Champions are one of the best ideas in adoption and one of the most often wasted. Most organisations appoint them, thank them, and leave them to it.

What we've seen. Champion roles are usually designed at around four hours a week. In practice we've seen one to two, because the day job wins. At one client, champions were asked to come up with agent ideas, and only a small group had the skills to. The real value started to show at around three months, not one.

What to do.

• Give champions the kit, not just the title: ready-made lessons and exercises they can run, how to answer common questions, how to handle objections, how to deal with ethical and security concerns, how to encourage people, and what meetings to set up.
• Train them first, for the skills and a common approach, then train them to train others.
• Protect their time explicitly, with their line manager's agreement.
• Make the ask narrow and specific: "run one 20-minute session a fortnight" beats "drive adoption in your area".
• Judge the network at three months, and expect to extend it.

Where we come in. We run champions programmes with pre-built material, so champions spend their time helping people, not building content.

15Somewhere to go that stays current, and a way to hear what people need

People need one place to go when they want to learn more or share what they've found. And you need to know what they're asking.

What we've seen. Internal AI hubs mostly end up quiet: people visit at launch and don't come back, because nothing changes and nobody posts. What works is a source that keeps updating, pitched at the right level for each person, plus a steady read of what people are asking. You'll learn more from the questions in a busy webinar than from any survey you send.

What to do.

• Give people one place for learning and sharing, and make sure it changes every week.
• Point each person to content that fits their role and level. A beginner and an experienced user shouldn't get the same path.
• Treat questions as data. Read webinar Q&A, session chat and support requests every week, and let them set the next topics.

Where we come in. Our platform recommends content for each person's role and level, and our weekly content is shaped by what people across all our clients are asking.

16Measure adoption with five metrics, and set a target for each

Most programmes report one number: how many people logged in, and call it active users. It's the easiest number to get and it tells you almost nothing. Someone who opened the tool once and someone whose week runs on it count the same. Measure four signs that the habit is forming, and one that it's paying off.

What we've seen. On one client's weekly dashboard, two teams had the same number of "active users". They looked nothing alike once we asked how often, how deeply, how widely and whether anyone was building. verify

What to do. Count everyone the programme is aimed at and take a baseline before you start. Then set a target for each measure against that baseline. The targets below are starting points, not benchmarks.

• Consistency: is it a habit? The share of people using AI on 3 or more working days a week. Starting target: half by month six, with the "no habit" group shrinking every month.
• Depth: are they doing real work with it? How much people do with AI when they use it, in bands set from your own baseline. Starting target: the typical user moves up one band by month three.
• Breadth: are they using more than chat? The share of regular users who use more than one kind of feature: files, projects, skills, agents. Starting target: one in two regular users by month six.
• Build: is anyone making things others use? Shared skills and assistants that other people use every week. Count the users, not the builds (lesson 8). Starting target: every team has at least one shared skill that most of the team uses weekly.
• Value: is it paying off? One business measure for each priority workflow, such as cycle time, cost per case or turnaround, baselined before you start and agreed with finance. Target: set it with your CFO before the pilot, along with the point at which you'd stop.

Report time-back stories alongside the numbers, because sponsors remember stories. If your tool only reports weekly, or not by team (lesson 12), use a one-question Friday pulse until you can get better data.

17Plan with what you know, and review it every quarter

As Ethan Mollick puts it, "assume this is the worst AI you will ever use." verify: Mollick Every plan you make is built on tools that will be overtaken, so the plan needs a rhythm for changing. Commit to the best plan you can make today, and look for what would prove it wrong.

What we've seen. We scoped our own intranet, with interactive pages and dashboards for the whole business, as a months-long project. It took a week. verify The plan wasn't wrong when we made it. What we could do had changed by the time we started.

What to do.

• Plan with the best information you have. Don't wait for the market to settle, because it won't.
• Review the plan every quarter. Ask what has changed in the tools, in what your people are asking for, and in what the measures show (lesson 16). Then update it.
• When something leaps ahead between reviews, decide in writing: adopt it now, after testing it in your own environment (lesson 19), or hold until the next review, with the reason.
• Build on what lasts (how AI works, habits, judgement), and treat tools and features as replaceable parts (lessons 4 and 20).
• Give every quarter a finish line. The plan has no final version, but each quarter should say what done looks like in 90 days, and what would make you stop.

Where we come in. We run the quarterly review with programme leads: what changed in the market, what your people are asking, what done looks like for the next 90 days, and what to change.

Part 3Don't do this

18Don't build your own AI learning platform

It seems sensible: put the AI training on your own intranet, in your own branding, built for your people. We've helped clients do exactly that.

What we've seen. There was too little content, and it was the wrong content: generic material, not what people were asking. It was also out of date almost as soon as it went live. A new model arrived, a feature moved, a vendor changed what was included. The client was then on a treadmill of making content, catching up, and making more, and most people stopped visiting. Nobody in-house is full-time on this, and nobody is set up to keep pace.

Instead. Use a source that someone else keeps current, and spend your own effort on the parts only you can do: your policies, your use cases, your people.

19Don't teach or demo anything you haven't tested where it will run Our mistake

What a vendor says a product does, and what your people can actually do with your licences, settings and security policies, are often different things. We learned the demo half of this the hard way.

What we've seen. Features shown in vendor demos that weren't switched on for the people being trained, or weren't in the licence they had. Agentic features still "under evaluation" by IT months after they were announced. And our own mistake: we built an AI tool for a client to use live in a workshop, couldn't test it inside their systems beforehand, and on the day it didn't perform. We had a fallback exercise and the session held, but it was a lesson.

Instead.

• Test every feature you plan to teach in your own environment, with an ordinary user's account, before you build training around it.
• Test every demo where it will run, with the access your audience has. If you can't, have a fallback ready and say so.

20Don't build methodologies for a moving target Our mistake

We've been here. Early on we built frameworks, scaffolds and methodologies for everything: how to run discovery, how to structure a programme, how to sequence the learning. Some of them were good. Most were out of date before we'd finished them, because the technology underneath kept moving.

What we learned. A methodology built for this year's AI is a constraint next year. There's an element of working it out as you go that every organisation has to accept. Keep principles fixed and methods light, and expect to change them.

21Don't deliver a story that isn't yours Our mistake

What happened. We've delivered sessions built on someone else's material, where the slides were handed over but the story behind them wasn't, and there was no full dry run. It didn't land.

Instead. Whoever presents needs the author's narrative, not just the deck, and a full rehearsal with the people who know the material. If a session is going to run several times, record and transcribe the first one and fold what was said back into the notes.

22Don't put everyone in the same room at the same level

Your organisation contains people who have never opened an AI tool and people who've been using it daily for years. Put them in the same session and you'll bore one group and lose the other.

What we've seen. Advanced users rated foundation sessions lowest, and some said so. Beginners in advanced sessions went quiet. One session format didn't fit a leadership team, a frontline team and a technical team.

Instead. Find out where people are (lesson 12), then offer different routes: a foundation for everyone who needs it, and a faster track for those who don't. Let people check in with peers at their own level.

Part 4Don't worry about this

23The perfect tool, or the perfect prompt

People lose months debating Copilot against ChatGPT against Claude against Gemini, and you'll be offered prompt formulas and courses on writing the perfect prompt. Both are methods built on how AI used to work (lesson 17). The tools leapfrog each other, and each model release needs less coaxing.

What we've seen. What appears in one tool turns up in the others soon after: skills are now a core part of what Microsoft offers. And given the same context, a plainly worded request now does about as well as an engineered formula verify. What makes the difference is the context: the document, the audience, what good looks like. What people need to learn has moved on, from writing prompts to handing work to AI and checking what comes back.

Instead.

• Use the tool you've got, and revisit the choice every quarter as part of the plan review (lesson 17).
• Teach people to give AI context: what it's for, who it's for, the material it needs, what good looks like.
• Judge a template by its blanks. If they ask for your context, it's worth keeping. If they ask for magic words, it's out of date.
• Turn the context you keep giving into a skill, so nobody has to type it again (lesson 8).
• Ask any provider what happens to their prompt method at the next model release.

24A centre of excellence before the crowd moves

A lab or centre of excellence sounds like the serious option. Without people across the organisation already using AI, it has nobody to serve and nothing to build on.

What we've seen. One client's lab never got going: it needed systems, access and governance that weren't in place, and the effort went elsewhere.

Instead. Get the crowd moving first. The people who should be in your centre of excellence will reveal themselves.

25The late adopters

Early sessions fill easily. Then demand drops, and it can look like the programme is failing.

What we've seen. Attendance falls as you move from the people who were keen anyway to everyone else. It's normal. At one client a company-wide deadline for the foundation session brought the rest through.

Instead. Expect it, set a date, and keep the weekly slot going for the people who come later.