An Automation You Have Not Switched On Is Not a Saving Yet

The automation is built. It works in testing. It is sitting in the account waiting to be switched on, and the slide deck already counts the eleven hours a month it will save.

It has saved nothing. The work is still being done by hand, exactly as it was, and it will keep being done by hand until somebody changes what the people actually do. The gap between those two states is where most automation programmes lose their credibility.

Built, live and adopted are three different things

Built means the workflow exists. This is the part engineers control and the part that gets celebrated.

Live means it is switched on and running against real data. Usually a few days or weeks after built, sometimes never, because switching on requires somebody to accept responsibility for what happens next.

Adopted means the humans have stopped doing the old version. This is the one that gets skipped in every report, and it is the only one that corresponds to the saving.

The uncomfortable middle state is an automation that is live while the manual process also continues, because the team does not yet trust it. Now you are paying for both, the automation is generating output somebody has to check against the manual version, and the process costs more than it did before you started.

That state is normal and it should be short. The problem is that nobody measures it, so it is not short, and six months later the hours in the business case have never appeared while everybody assumes they have.

Count the work as manual until somebody says otherwise

The discipline that fixes this is simple and slightly annoying, which is why it works.

Whatever record you keep of how the work runs, do not update it when the automation is built. Do not update it when the automation is switched on. Update it when the person who does that job confirms they have stopped doing it the old way.

Until then the process still counts as manual, with all of its hours, because that is the truth. A workflow you have designed but not adopted is a plan, and a plan that appears in your numbers as a saving is how a company ends up confidently reporting capacity it does not have.

In abi. Agent Studio a designed workflow shows on your map as a ghost, and the work it would replace keeps counting as manual until you say the change has actually been made. The map records the business as it is, not as it is about to be.

What to measure in the first month

Three things, all cheap to collect.

How often the old path still gets used. If the manual route still runs forty times in a month, the automation is not adopted regardless of what the dashboard says.

How often somebody overrides it. A high override rate is not a sign of a bad automation. It is a sign you automated a decision that turns out to have exceptions, and the exceptions are the thing to go and look at.

Who checks the output, and how long for. Verification is supposed to taper. If somebody is still reading every single result at week eight, either they do not trust it or they are right not to, and both answers need a conversation rather than a reminder.

The part nobody puts in the business case

Give it a decommissioning date for the old process. An actual date, agreed with the person who runs it, on which the manual route stops being available.

Without that date the two paths coexist indefinitely, because running both is nobody's problem individually and only becomes visible in aggregate. With it, the questions that matter get asked at a time when somebody can still do something about them.

And if the date arrives and the team is not ready, do not force it. Move it once, in public, with the reason written down. A moved date is information. A quietly ignored one is how an automation ends up live, unused, and still counted as a saving in a report that somebody is going to be asked about eventually.