Why most AI pilots change nothing.

Most of the owners we meet have already tried AI. A licence was bought, a pilot was run, a demo impressed the board. Six months later, the work is done the way it always was.

The pilot usually worked. That is what makes it frustrating. The technology did what it said. The business did not change.

From inside a lot of operations, we see the same five reasons again and again.

1. It started with the technology

“We should be using AI” is not a problem statement. Pilots that start there go looking for somewhere to land, and they land somewhere safe and unimportant.

We start from the other end. We are not trying to find AI use cases; we are trying to find business problems. In one fit-out manufacturer, the most valuable first build had no AI in it at all: it was a link between two systems that removed double data entry. That was the right answer, so that was the recommendation.

2. It ran beside the work, not inside it

A new tool, a new login, a new screen. The team tries it, finds it adds a step, and quietly goes back to the inbox.

The systems that stick live where the work already happens. At one distributor, the support team still works in Outlook. Drafts appear there, and the team approves them there. The dashboard is there for the full picture, not as another place to check. At a 16-branch broker, the follow-up emails go from each advisor’s own Outlook.

3. Nobody owned it

A pilot owned by “the innovation team” ends when the innovation team moves on. A system needs an owner inside the business: someone whose job improves when it works, and who notices when it does not.

The best sign we see is when the client creates that role itself. One broker assigned a person to work its new system full-time. A protection broker’s admin team asked us to roll the system out to everyone and retire the old process. Nobody asked them to.

4. Nobody measured it

If you did not count the minutes before, you cannot prove the minutes after. Many pilots end in a meeting where everyone agrees it “seemed useful”, and nobody funds the next step.

We agree the measure before we build. At the protection broker it was review time per policy: 20 to 30 minutes before, about 4 after. Where a baseline does not exist yet, we say so, and we build one with the client rather than invent a number.

5. It never learned

A pilot is frozen at the moment of the demo. Real work changes every week: new products, new rules, new exceptions.

We hold a short session with the people using the system every week from go-live, and every correction they make goes back into it. At the distributor, the dashboard was rebuilt in the second month on the team’s feedback. Systems that learn from the people using them get better. Systems that don’t get abandoned.

What a pilot should really prove

A good first system answers one question: will this business work differently because of it? That needs the right problem, a place inside the real work, an owner, a number and a way to learn.

Before you run another pilot, ask four questions. Which number will move? Who will own it the day after we leave? Where in the current work will people see it? And how will it learn from them? If any answer is vague, the pilot will probably work, and still change nothing.

It also needs to be small. One workflow, done properly, is worth more than a platform nobody opens. Once the first one works, the next ideas come from the client. That is when you know it has changed something.