What a Year of AI Conversations Taught Us

Over the past year, we have spoken with companies at very different stages of using AI. Some already had systems running in their daily operations. Others were still deciding where to start. Three observations from those conversations have stayed with us, partly because they changed how we work ourselves.

1. Same business, very different starting points

“We’re probably behind the others.” We heard some version of this from companies at both ends of the spectrum. Even those with AI already in daily use were unsure where they stood. From inside an organisation, it can be difficult to tell.

Two legal-protection insurers made the contrast particularly clear. They sold much the same product, handled similar claims and operated under the same regulatory requirements. One had an AI intake system in production and was working on voice bots to handle whole customer conversations. The other was still working out whether a customer email could be put into a language model at all.

We saw comparable differences elsewhere. Industry, size and budget did not seem to explain them consistently. Our impression was that earlier decisions played a large part, including how companies approached data protection. In some cases, the discussion had become specific: where a model could run, who could access the data and how results would be checked. In others, the basic question of whether to use AI remained open.

These are substantial questions, especially when customer information is involved. Resolving them for a first project also gives the next one a starting point. Part of what looks like a technology gap may be the experience one company has already built up.

2. Ideas were rarely the missing piece

We expected to spend more time explaining where AI might be useful. Instead, people often arrived with a list of processes they wanted to improve. They knew the volumes, the repetitive steps and exactly where the work was piling up.

The difficulty was getting from that list to a project someone could commit to. Early on, people needed a clearer picture of what they were being asked to back: what employees would actually use, which part of their work would change and how much effort a first attempt would require. Without that, even a promising idea was hard to move forward.

Further along, the difficulty changed. A demo might work well, but getting it into daily use meant connecting it to existing software, testing it against real cases and keeping it running after launch. That takes time and expertise. Budget came into both stages: a vague proposal is hard to fund, and a project stuck between demo and production makes it harder to argue for the next one.

3. An early version changes the conversation

At the start of our projects, we sometimes spent too long discussing a system in the abstract. Everyone in the room could agree with the description while picturing something slightly different. More explanation did not always help.

Showing an early version on the company’s own cases changed the conversation. People could point to a result, explain what was wrong with it and tell us what they needed instead. We had something specific to work on together, and the next version could reflect that feedback.

Using their own cases mattered. The people doing the work could judge the output against cases they understood, including the awkward details that are easy to miss in a general discussion. A result can look sensible to an outsider and still miss something obvious to the person who handles these cases every day.

We now try to reach that point earlier. The first version still needs proper testing and development before anyone can rely on it. But it helps us see where our understanding is incomplete, and gives everyone a more concrete basis for deciding whether the idea is worth taking further.