Adoption is where these systems quietly die

The parallel system, and how to find it

The most common failure after go-live is not rejection. It is duplication. The new system runs, the dashboard shows activity, and somewhere in the team a spreadsheet is being maintained that contains the version everybody actually trusts. Nobody is being obstructive. They are managing a risk the project did not address, and they will keep managing it for as long as it feels necessary.

It is visible if you go looking. Someone exports from the new system on the last day of the month and reworks the numbers before sending them on. A group chat exists where the real decisions get made before being entered. One person checks every output before it goes anywhere, and that checking has quietly become a full time part of their week. Work arrives through a channel the system does not cover, and it is handled the old way.

The way to find it is to ask the question in a form that is safe to answer honestly. Not do you use the system, which produces yes. Ask what you do when it gets something wrong, and what you keep outside it just in case. People will tell you, because from where they sit the workaround is diligence rather than resistance.

• A spreadsheet or document that shadows the system and is trusted more than it
• Month end exports that are reworked by hand before anyone sees them
• A chat group where decisions are made and then entered afterwards
• One person quietly checking everything, at a cost nobody counted
• A category of work that never enters the system at all

Do not ask whether people use the system. Ask what they do when it gets something wrong, and what they keep outside it just in case.

Three reasons the old process survives

The first is a broken trust that was never repaired. The system got something wrong early, somebody noticed, and there was no obvious way to report it and no visible correction afterwards. One unexplained error is enough to justify a permanent manual check, and the cost of that check is paid every week thereafter. The repair is not reassurance. It is a way to report a problem in under a minute, and a reply that says what happened, from a person.

The second is a missing exception path. Every process has cases the build did not cover, and if the system offers no route for them, people build their own route and then keep using it for the ordinary cases too, because switching between two routes is harder than using one. A visible queue for anything the system cannot handle, with the reason attached and a named owner, closes this. Without it the workaround becomes the process within a quarter.

The third is measurement. If a team's performance is still assessed on the artefact the old process produced, they will keep producing it whatever the new system does, and they are right to. Changing what is measured is the least technical and most effective intervention available, and it is usually the one nobody has the authority to make, which is why the project needed a real owner before it started.

• A one minute way to report a wrong output, and a human reply that explains it
• A visible exception queue with a reason attached and a named owner
• Performance measured on the new artefact rather than the old one
• A date on which the old system is switched off, decided and announced

Training is not a session

A demonstration the week before launch is not training. It is a presentation, attended by people whose current work is still due, about a system that does not yet contain any of their real cases. What people retain from it is the tone rather than the procedure.

What works is doing real work in the system on the first day, with somebody available while it is happening. Not sample data. Their own queue, their own awkward cases, with permission to get it wrong. An hour of that produces more competence than a morning of slides, and it surfaces the design problems while there is still appetite to fix them.

Then there has to be something written that a person can find at eleven at night when the trainer has gone. Short, task shaped, findable from inside the tool rather than in a shared drive nobody can navigate. Written for the case that goes wrong rather than the one that goes right, since nobody looks up instructions for the easy path.

And there has to be one named person per team who is asked first. Every organisation routes questions to a person rather than a document, whether or not the plan says so, and choosing that person deliberately, giving them early access and a direct line back to whoever built it, is cheaper than pretending it will not happen.

What to measure in week two, not month six

The metrics people plan to report are lagging ones: hours saved, cost per case, satisfaction. Those arrive too late to act on. By month six the parallel process has hardened, the habits are set, and the conversation has become defensive.

In week two, measure what tells you whether the thing is being used and where it is failing. What proportion of eligible cases went through the system rather than around it, which is the single most useful number and the one nobody instruments. How many outputs were overridden, and the reason for each.

How long items sit in the exception queue before a person touches them, because a queue nobody empties teaches people the system cannot be trusted. How many individuals used it at all, rather than total volume, since one enthusiastic user can hide an unadopted team.

And count the questions. A rising number of how do I questions in week two is healthy. Silence is not the same as competence, and a team that has stopped asking has often stopped using it.

Set a review at two weeks and another at six, with a named person who can change something as a result. A measurement nobody is empowered to act on is a report, and reports do not change adoption.

• Share of eligible cases going through the system rather than around it
• Overrides, counted with the reason recorded
• Time items sit in the exception queue before a person touches them
• Number of distinct people using it, not total volume
• The volume of questions being asked, where silence is a warning rather than success

What the work looks like alongside a build

Adoption work is not a separate programme and it should not be sold as one. It is a set of commitments attached to a build: who gets early access, what the first week looks like, where the exception queue lives and who empties it, what gets measured at two weeks and at six, and the date the old process is switched off. Those are decisions rather than deliverables, and they cost mostly attention.

There is usually a short period of heightened support around go-live, then a step down. What moves its size is how many teams and sites are affected, since one team in one building is a different job from four sites on different shifts; whether the process is changing as well as the tooling, because a new tool for the same process is far easier than a new process; and how much the change alters what people are measured on, which is where the real resistance lives and where the time goes.

Anyone quoting adoption support without knowing how many teams are involved and whether the process itself is changing is guessing. Ask what the first two weeks look like in detail, and who is present for them.

When resistance is the correct response

Sometimes the team is right and the system is wrong. If people are bypassing it because it produces bad output on a category of case that matters, that is not an adoption problem and no amount of communication will fix it. Treating a legitimate objection as resistance is how a project loses the people who were paying attention, and they are usually the ones who noticed first.

There is a version of this that is harder to hear. If the process was already working well and the automation was chosen because it was available rather than because it paid back, low adoption is an accurate signal.

The question to ask before a change management push is whether the new way is genuinely better for the person being asked to change, in terms they would recognise. If the honest answer is that it is better for reporting and neutral for them, expect the effort to be proportional to that.

And where the change is genuinely unwelcome because it reduces headcount, adoption work is not a substitute for telling people what is happening. People work out the direction of a project quickly, and an organisation that will not say what the intention is gets compliance rather than adoption, which looks identical for about a month.

Who does this work, and why handing it over is the point

Adoption is the one part of an engagement where the answer is always a person. A system cannot notice that the accounts team quietly kept the old spreadsheet, and it certainly cannot ask them why without making them defensive. So this is a human job with a system underneath it: usage data shows where the parallel process survives, and somebody then sits with the team that built it.

Inside the workflows themselves the same rule holds through the first month. Anything the new system does that a person used to do is shown to that person for human approval before it goes out. Not forever, but long enough that they can see it is right. Trust in one of these builds is earned by being visibly correct thirty times, and skipping that is why so many go unused.

Ali owns marketing and sales at Wobble and does most of the training work, because selling a change internally is the same skill as selling anything else. Wobble works from Karachi across 25 engagements in six countries and is answerable for whether the thing is being used, which is a harder promise than whether it was delivered.

The end state is that you do not need us. Written procedures, recorded walkthroughs and live training exist so that you train your team and keep training them after handover, and admin access sits in your name from the first week rather than at the end, so you own the system while it is being adopted rather than afterwards. If this is being run in-house, the single most useful thing to copy is the week two check rather than the month six review.

Common questions

Why do teams keep the old process running alongside a new AI system?

Three reasons account for most of it. The system got something wrong early and there was no visible way to report or correct it, so a manual check became permanent. There is no route for cases the build did not cover. Or performance is still measured on the artefact the old process produced, which makes keeping it rational.

How do I find out whether a parallel process exists?

Ask a question that is safe to answer honestly. Not whether people use the system, which produces yes, but what they do when it gets something wrong and what they keep outside it just in case. Then look for month end exports, a shadow spreadsheet, and one person checking everything.

What does effective training look like?

Real work in the system on day one with someone available while it happens, using the person's own queue rather than sample data. Then a short written page, task shaped, findable from inside the tool, written for the case that goes wrong. Then one named person per team who is asked first.

What should we measure two weeks after go-live?

The share of eligible cases going through the system rather than around it, the number of overrides with reasons recorded, how long items sit in the exception queue, how many distinct people used it, and how many questions are being asked. Hours saved and cost per case arrive far too late to act on.

What is the single most useful adoption number?

The proportion of eligible cases that went around the system rather than through it. Most dashboards only count what came through, which cannot distinguish a well adopted system from one handling a fraction of the work while everything else is done the old way.

When is low adoption the correct response?

When the system produces bad output on a category of case that matters. That is a build problem, and treating it as resistance loses the people who noticed first. It is also correct when the change is better for reporting and neutral for the person being asked to change, which is worth establishing before a communications push.