Most businesses that have tried AI have a similar story. A vendor or an enthusiastic member of staff shows something impressive. A pilot is agreed. A few weeks later it works, more or less, in a demo. And then, somehow, it never becomes part of how the business actually runs.
The technology is rarely the problem. Pilots stall for a handful of ordinary reasons, and most of them can be avoided before the work starts.
Why pilots stall
- Nobody agreed what success looks like. Without a clear measure, such as time saved per order or errors per month, a pilot can't succeed or fail. It just drifts, and eventually people stop talking about it.
- The data wasn't ready. The demo used clean examples. Real work arrives in a dozen formats, with records that don't match between systems and rules that live in someone's head.
- The old systems weren't part of the plan. The pilot produced a good answer, but someone still had to type it into the accounts package or the agency system by hand. The time saving disappeared.
- The people doing the work were left out. If the team didn't help shape it, they won't trust it, and they will quietly keep doing it the old way.
- It was too big. Trying to automate a whole department, or every exception, means nothing is finished for months.
How to make yours one that does
The pilots that make it into everyday work tend to share the same approach.
- Pick one process that happens often and is easy to check. Frequent, patterned work where a person can quickly see whether the result is right.
- Measure it before you start. How long it takes today, how often it goes wrong, and what it costs. That baseline is what you will compare against.
- Prepare the data and the access first. Gather real examples, agree the rules and exceptions with the people who know them, and arrange access to the systems involved.
- Run it on live work, with a person checking. Not a demo, not a test copy. Real work, with someone reviewing the output until everyone is confident.
- Connect it to the systems people already use. The result should land where the work happens, not in a separate tool someone has to remember to open.
- Involve the team from the first week. They know the exceptions and the shortcuts, and they will be the ones using it.
- Decide on the numbers. After a few weeks, compare against the baseline. Roll it out, adjust it, or stop.
Stopping is a good outcome too
A pilot that shows a process isn't worth automating has done its job, as long as you find out quickly and cheaply. The expensive outcome is the one that never quite fails, never quite works, and keeps absorbing time.
Where we can help
If you aren't sure which process to start with, an Operational Efficiency Review measures the candidates and ranks them by payback. If you already know, an Operational Improvement Project prepares the data and systems, proves the improvement on live work, rolls it out with your team and measures the results before and after.
