Pillar
Change management
The technology is the easy part. Whether people actually work the new way is what decides if any of it was worth building.
AI programs rarely fail for technical reasons
The model works. The integration works. The pilot demos beautifully. Six months later the old spreadsheet is still the system of record and nobody can quite say when that happened. What went wrong was not technical, and it usually was not sudden.
The pilot works, the rollout doesn't
A pilot runs on volunteers who want it to succeed. Rollout runs on everyone else. That includes the people who were never asked, and the ones whose workaround has quietly worked for eleven years.
People route around it
If the new way is slower on a bad day, it gets skipped on bad days. Then it gets skipped on ordinary days. Nothing announces this; the usage numbers just drift down.
It lives in one person's head
Most programs have one internal champion who understands the whole thing. When they change roles, the program does not fail loudly. It just stops having anyone to defend it.
One bad output ends the trust
People forgive a colleague who is wrong occasionally. They do not extend that to a system, especially one they did not ask for. Recovering that trust costs far more than earning it did.
What we actually do about it
Change management here is not a workshop and a slide deck at the end. It is how the work is run from the first day, and most of it is unglamorous.
Start with whose job changes
Before anything is designed, we work out who is affected, what they currently do, and what they would lose. The people with the most to lose are the ones whose objections are worth the most.
Design with them, not for them
We redesign the process alongside the people who run it. On-site, in the meetings, on the floor. A process designed without them is one they will be asked to accept, not one they helped build.
Train by role, not by feature
Nobody needs a tour of the system. They need to know what their Tuesday looks like now, what to do when the output is wrong, and who to ask. That is a different session for each role.
Measure use, not deployment
Shipped is not adopted. We instrument what actually gets used, review it with you, and treat a falling number as a problem to investigate rather than a training issue to restate.
What good looks like
The test is not whether the system works. It is whether the organization would notice if it stopped.
The old way falls out of use
Not because it was switched off, but because the new way is genuinely faster on a bad day, not just a good one.
More than one person can explain it
The program survives the champion changing jobs, because understanding was spread on purpose rather than concentrated by accident.
People ask for the next one
The clearest signal that the first change landed is a team asking whether the same thing could be done for a different process.
When we'd tell you to wait
Change management fails most often because the rollout started before the organization was ready. These are the three we look for, and any one of them is a reason to fix something else first.
The champion is the only believer
If one person wants this and everyone else is being told about it, adoption is already at risk. We'd spend the first weeks widening that group rather than building anything.
The process is about to change anyway
A reorganization or a system migration already in flight means we'd be automating something that won't exist in six months. Better to wait for it to settle than to build it twice.
The decision isn't really made
If two people in the room still disagree about whether this is happening, the program will stall at the first piece of friction. That's a conversation to finish before there's software to argue about.
Questions we get
Isn't this just training?
Training is one part, and it is the part that fails on its own. Training teaches people to operate a system they were handed. The work here starts before the system exists. We decide what the process should be, with the people who will run it. By the time there is something to train on, it is already theirs.
Our team is already stretched. How much of their time does this cost?
Less than a failed rollout does. In practice that is a few hours from each affected role during discovery, and role-specific sessions at rollout rather than one long all-hands. We work on-site precisely so this fits around the job instead of interrupting it.
What if people resist?
Resistance is usually information. When someone pushes back, they are often protecting something real the new process has not accounted for. An exception. A customer. A reason the old step existed. We would rather hear that in week one than find it in the usage numbers six months later.
How do you know it worked?
We agree what "working" means before we build, in terms of actual use rather than delivery. Then we measure it and review it with you. If the number is falling, that is a finding, not a training problem.
Do you do this without building the automation?
Yes. If the process is the problem and the technology is not the answer, we will say so. That is a cheaper conversation to have early.
Change management is one of three
Change management is not a service bolted onto delivery. It is one of three things that all have to go right, and it does not work in isolation from the other two.
AI Automation
The processes and the agents themselves, built on your real systems and connected to the tools you already use.
Explore AI automationSecurity & Governance
Data secured, governance established, access held to least privilege. Then tested the way an attacker would.
Explore security and governanceTell us what's slowing you down
If a previous rollout stalled, that history is useful. It usually points straight at what to do differently.