The pattern is remarkably consistent. A team builds something with AI, shows it in a meeting, everyone's impressed. Three months later someone asks about it – and the answer is that it's still in progress, but things have been busy.

The pilot wasn't bad. It just never became work. In our experience, this happens at three specific points, and the technology is never to blame at any of them.

Problem 1: The Idea Hangs on the Tool, Not the Bottleneck

The origin is often a demo. Someone sees what a tool can do, finds it impressive, and only afterwards thinks about where it could be used in the business. The order is backwards – and it leads to pilots that solve something impressive nobody was actually bothered by.

How you spot it: the pilot gets introduced with “look what this can do”, not “this cost us eleven hours last month”. Ask for the number behind every AI idea. If nobody can say how often the task comes up and how long it takes today, it's not a solution – it's a demo.

The reverse is also true: sometimes the answer reveals that the real problem is a missing interface, or a form nobody fills in. In that case, the right solution is automation without AI – cheaper, more stable, less maintenance. Treating that finding as a success is hard for many people, but it saves the most money.

Problem 2: There's Nobody Who Can Approve It

The pilot works, and then the question comes up: are we actually allowed to use this for real client communication? Nobody knows. So someone asks leadership, who asks the data protection officer, who thinks it's a fair question and wants to review it carefully. Three weeks later, the attention has moved on.

This isn't reluctance – it's a gap. As long as it isn't defined which data classes are allowed, who approves, and who's responsible for an outcome, every single decision is a one-off – and one-offs take time.

The consequence is inconvenient for project plans: the governance questions belong before the pilot, not after. Not as a complete rulebook, but as a minimum set of three answers – which data, who approves, who's liable for the outcome. That's a workshop, not a concept phase.

Problem 3: Nothing Gets Embedded After the Pilot

The third point is the most common. The pilot went well, approval is in place, three people use it – and that's where it stays. Not because everyone else rejects it, but because it never reached them.

Usually three things are missing behind that. There was training, but a generic one: one hour for everyone, showing everything the tool can do, instead of twenty minutes per role on the one task that role actually deals with. There's nobody to ask when something gets stuck after two weeks. And nobody measures whether anyone's actually using it.

That last point is decisive, because it makes everything else visible. “We have twenty licences” isn't a number. “Of twenty people, seven use it weekly, five of them in sales” is one. Only with that number can you ask why finance isn't on board – and the answer is almost always something concrete you can fix.

What Makes the Difference

Knowing the three points means you can plan around them. In practice, that means:

Before the pilot comes an analysis that starts with processes, not tools – with a number for frequency and current time spent for every candidate. At the same time, not afterwards, the minimum rules get clarified: permitted data classes, approval, responsibility. And after the pilot comes a phase that earns its name: role-specific training, named points of contact, measured usage.

That's exactly why our approach has four phases, not three. The fourth – we call it Drive – is the one missing from most projects, and it's the one that decides the difference between an impressive pilot and a genuinely changed way of working.

A Pilot That Dies Isn't Always a Failure

One last check, in reverse: not every pilot that gets shelved is a failure. If Phase 3 shows that a use case only delivers half the hoped-for benefit in practice, that's a useful finding – provided it's actually said out loud rather than dragged along as “still running”.

A stopped pilot isn't the bad outcome. The bad outcome is the one that's never officially stopped and keeps tying up attention.

Our four-phase approach – including the phase that's usually missing →