Business practice
AI change management.
A rollout that arrives as an announcement gets treated as one. When your SaaS or AI company brings AI into support, success or operations, you get a change plan built for the people doing the work, training on their real tasks, and a check after go-live, so the new way survives the first busy week.
The first busy week decides whether a change survives. Almost nothing else does.
A rollout announced at an all-hands is a message, not a plan. People nod, the deck gets passed around, and then the queue spikes and everyone reaches for the way of working they already trust. By the time anyone notices, the new process has quietly become optional.
The practical work of adoption lands on frontline managers. They're the ones getting the team on board, changing the workflow and retraining people while the tickets keep coming, and they feel it: in DDI's Global Leadership Forecast 2025, frontline leaders were three times more likely than senior leaders to be concerned about AI's impact. That's manager work, and Manager Fundamentals is where frontline managers learn to run it.
What holds is AI change management built around the people who have to do the work differently. That means knowing where the resistance actually sits before you design the training, teaching the real task rather than the feature list, and coming back after go-live, when the drift starts and nobody's watching.
The approach
Three words we work by.
Ask.
Resistance gets asked about rather than assumed. Short conversations with the people whose work changes, plus an anonymous read where seniority would keep someone quiet. Most of what surfaces is practical: a step that breaks, a customer who'll notice, a release week or renewal crunch nobody upstream planned for.
Train.
Training is built around the task somebody actually has to finish, not around the features of the tool. People practice on their own live work, with their own tickets and accounts, so what they leave with is a way to get Thursday done rather than a set of screenshots they'll never open again.
Check.
A checkpoint is scheduled after go-live, at the point where attention has moved on and the old way starts creeping back. It's a short, specific look at whether the new way is being used, where it's being worked around, and what needs fixing before the workaround becomes the standard.
The work
Four workstreams, in sequence.
Resistance read
Conversations with the people whose day changes, plus an anonymous route for anything they wouldn't say out loud. You get the real objections, sorted into the ones that are a training problem, the ones that are a process problem, and the ones telling you the plan is wrong.
Change plan
A plan written for the people doing the work: what changes, when, who's affected, what they stop doing, and who they ask when it breaks. It names the busy periods it has to survive, like quarter-end renewals or a major release, and sequences around them rather than through them.
Training on the real task
Sessions built on your own live work, run in small groups, with the procedure written down afterward in your team's words. Anyone who joins next month can follow the same path without needing the person who ran the session.
Post go-live checkpoint
A scheduled return after the attention has moved on. Usage looked at honestly, workarounds surfaced without blame, and a short list of fixes made while changing them is still cheap.
Related reading.
All insights Governance
Shadow AI is already in your company. Here's the map
Ask a CEO how many AI tools are in use across the company and you'll usually hear about the ones on the invoice. Ask the team anonymously and the list gets longer: free chatbot accounts, browser extensions, meeting notetakers, and AI features switched on inside software you
Operations
The two-person dependency test
Every SaaS company has them. Two people, sometimes one, who hold a process together through memory and habit. They're usually excellent, they're usually loyal, and they're usually the reason nobody has ever needed to write the process down.
Questions
Asked before, answered plainly.
Usually, and often faster than the first attempt. A stalled rollout has already shown you where the friction is, which is information the first attempt didn't have. We start by asking the people who went back to the old way why, and that conversation is usually where the plan comes from.
A short conversation each for the people whose work changes, and one training session in a small group. The plan and the write-up are our work, not homework we hand back to your team. The heaviest ask is the checkpoint after go-live, and that's an hour.
It's written for them because that's where we're asked most often, and because AI rollouts fail in a particular way: people quietly stop using the tool and nothing on a dashboard says so. The same plan works for a new process or a new system, like a help desk migration or a new CRM. The questions don't change much.
Then the plan changes. Some of what surfaces isn't resistance at all. It's people telling you the new way breaks something you didn't know about, like a step the escalation path depends on. Finding that in week one is the point. It's far cheaper than finding it in the first busy week with customers watching.
The checkpoint looks at use, not opinion. Is the new way showing up in the work, where are people routing around it, and has anything quietly reverted? You get that read in writing, with the fixes worth making, while they're still small.