Change management in automation: why adoption fails without it

An automation that runs correctly and that nobody uses has failed. In Colombia and Mexico this is a more common outcome than a technical failure, and the cause is consistent: the question of what happens to the people doing the work was left until after the build.

Below: why resistance is usually rational, the question that has to be answered first, who has to answer it, what to do with the freed capacity, and how adoption is measured.

Change management has a reputation as the soft part of the project — workshops, communications, a launch email. That reputation is why it gets cut when the timeline compresses, and why the automation ships into an organisation that has decided in advance not to trust it.

The version that works is neither soft nor expensive. It is a small number of concrete answers, given early, by people with the authority to give them.

Resistance is usually rational

The team asked to validate an automation is the team whose work it removes. If nobody has said what happens to the capacity that frees up, the honest reading of the situation is that finding problems is safer than finding fixes.

Treating that as a communications failure — more explanation, better messaging, an enthusiasm campaign — misdiagnoses it completely. The team understands the project perfectly well. What they do not have is an answer to the only question that affects them.

The tell is easy to recognise: edge cases arrive as objections rather than as requirements. When a team wants the automation to work, the same knowledge produces a list of cases to handle; when it does not, the same list arrives as reasons it cannot be done.

The question that has to be answered first

What happens to the people whose work is automated. Not in general terms — specifically, for this team, on this process.

There are only a few honest answers. The capacity is redeployed to work the team considers better. The capacity absorbs growth that would otherwise have required hiring. Or headcount genuinely reduces, in which case saying so plainly is better than the alternative, because the team will conclude it anyway and will conclude it about every future project too.

What does not work is leaving it open. An unanswered question is answered by rumour, and rumour defaults to the worst available interpretation.

Who has to answer it

Not the project team, and not IT. The answer only carries weight from someone who could actually decide otherwise — the leader whose budget holds the headcount.

This is the part that gets skipped, usually because arranging it is politically uncomfortable and the project can technically proceed without it. It proceeds into the failure mode described above.

It takes one meeting and one sentence said out loud to the affected team. Measured against the cost of an automation that runs and is worked around, it is the highest-return activity in the entire programme.

What to do with the freed capacity

The strongest position is to have the answer before the pilot, and to have it be something the team wants. Most administrative teams have a backlog of work they consider more valuable and never reach — analysis, exception resolution, supplier or customer follow-up.

Naming that backlog specifically converts the automation from a threat into the thing that finally clears it. The framing is not spin: it is what actually happens when the routine work goes, provided somebody decided in advance where the hours go.

Where they are not decided, the hours dissipate. The process gets slower again, the saving does not appear in any measurable form, and the second automation is harder to fund because the first one cannot be shown to have paid.

The training that actually matters

Not how to use the automation — most run unattended and there is nothing to use. What the team needs to know is how to tell when it has failed, what to do about it, and how to run the process manually while it is down.

That last one is consistently neglected, and it is the one that decides how the first incident goes. Six months after the automation started, nobody remembers the manual steps, and a two-hour outage becomes a two-day one.

A short written fallback procedure, tested once, is the whole requirement. It is also the artefact that most reassures the team, because it demonstrates the organisation has not bet everything on something they were not asked about.

The sponsor problem

Automation programmes are usually sponsored by whoever benefits from the saving and delivered into a team that reports elsewhere. That split is the structural reason change management gets skipped: the sponsor has no authority over the affected team, and the person who does has no stake in the project.

It is fixable, and cheaply, by making the process owner a named participant rather than a stakeholder to be informed. The distinction is not semantic — a participant attends the design sessions, signs off the exception rules, and owns the adoption numbers afterwards.

Where that arrangement does not exist, the programme depends on goodwill that has no owner, and it holds only until the first disagreement about an exception case.

What this costs when it is skipped

Rarely a cancelled project. Almost always a slower one, and a second one that never starts.

The specific mechanism is that the first automation gets delivered, gets tolerated, and produces a saving nobody can substantiate because the freed hours went nowhere in particular. When the programme asks for funding for the next three processes, it has a working automation and no evidence, which is a weak position in any budget conversation.

The organisations that build a portfolio rather than a pilot are almost never the ones with better technology. They are the ones that answered the ownership and capacity questions on the first process and could therefore prove what the second one would be worth.

How adoption is measured

By what the process does, not by what people say about it in a survey. Three signals are enough: the share of volume actually going through the automated path, the exception rate over time, and the number of manual workarounds that have appeared alongside it.

The third is the one that reveals a failure the other two hide. If volume is high and exceptions are low but the team has built a parallel spreadsheet, the automation is being tolerated rather than adopted, and the moment it needs a change nobody will defend it.

These are cheap to measure and worth reviewing monthly for the first quarter. After that, an automation that has survived three months of real conditions with no shadow process is generally safe to leave alone.

Where to start

With the ownership and capacity questions answered before the build, not after — which is a sequencing decision rather than a budget one.

A process automation assessment covers both alongside the technical feasibility, so the automation plan reaches production instead of stopping at a pilot everyone agrees was impressive.

Frequently asked questions

Why is an automation not adopted even when it works?

Usually because nobody said what happens to the capacity it frees. The team asked to validate it is the team whose work it removes, and without an answer, finding problems is safer than finding fixes.

Is resistance a communications problem?

No. It is a rational response to an unanswered question. More explanation does not resolve it; a specific answer from someone with the authority to give it does.

Who should answer the capacity question?

The leader whose budget holds the headcount — not the project team and not IT. The answer only carries weight from someone who could have decided otherwise.

What training does the team actually need?

How to tell when the automation has failed, what to do about it, and how to run the process manually while it is down. The manual fallback is the part most often skipped and the one that decides how the first incident goes.

How is adoption measured?

Share of volume through the automated path, exception rate over time, and the number of manual workarounds that appear alongside it. A parallel spreadsheet means it is tolerated, not adopted.

What if headcount really does reduce?

Say so plainly. The team will conclude it anyway, and an evasive answer costs credibility on every future project as well as this one.