Start with the journey, not the model

Most AI use-case lists are written in a meeting room. Someone runs a workshop, a vendor shows what their platform can do, and by lunchtime there are forty ideas on a wall. They get scored for feasibility, a handful become pilots, and a year later very few are part of anyone’s working day.

The list wasn’t wrong, exactly. It just described what the technology could do rather than where the journey breaks. Those are different questions, and only the second one leads to value.

Friction lives in the handoffs

When you walk a customer journey end to end, the problems rarely sit inside one team. They sit between teams: between sales and service, between stores and digital, between the business and the partner who sells on its behalf. Each function has optimised its own piece. Nobody owns the whole.

In fashion retail I worked on click-and-collect and returns, where stores and ecommerce were in a long-running argument about who owned the customer. The fix didn’t start with a system. It started with working in the stores and getting every discipline in a room to agree what the best journey looked like. Once the conversation moved from channel ownership to shared outcomes, returns processing time fell by a quarter.

That wasn’t an AI project. But it’s exactly where AI projects should start, because the same handoffs are where an assistant, a workflow or a prediction can do the most good, and where a badly placed one will make things worse.

How to find the real use cases

I use five steps, and none of them involve a vendor.

1. Walk it yourself. Place the order, make the complaint, return the item, chase the delivery. You will find things no dashboard shows you.
2. Watch it. Spend time with customers and with the colleagues serving them. Watch for workarounds: the spreadsheet beside the system, the colleague who “just knows”, the customer who calls because the website didn’t answer.
3. Map the whole journey, including the back office. The customer sees a delay. The cause is three systems and two teams away.
4. Write the problem before the solution. “Customers call to ask where their order is because tracking doesn’t cover the last mile” is a use case waiting to happen. “Deploy a chatbot” is not.
5. Only then ask which AI capability removes it. Reading and extracting, checking and comparing, monitoring and prioritising, understanding intent, or predicting. The capability follows the problem.

At a food services business with more than 600 sites, a flagship location kept complaining about a long-established ordering service. I used it myself, watched customers and the flow of service, then ran an open session with the site team, Product and Data. The result was a set of fixes and commitments everyone believed in, and an approach we then took to more than a hundred other locations. The insight came from the floor, not the backlog.

B2C, B2B and B2B2C need different questions

The discipline is the same in every model. What changes is where to look.

B2C: effort in the moment

High volume, little patience and a lot of emotion. The question is where customers spend effort they shouldn’t have to: repeating themselves, waiting for an answer that exists somewhere in the business, or giving up. AI earns its place by answering, explaining and guiding.

B2B: the gap between a request and a confident answer

Fewer customers, but each one is an account with contracts, pricing, orders and history. The friction is usually admin: a quote that takes days because requirements arrive in an email, an order that needs checking against a contract, a delivery exception nobody spots until the customer calls. AI earns its place by shortening the path from request to a confident answer.

B2B2C: two customers in one journey

Here you serve a partner and the customer they serve. Every delay you cause, the partner has to explain to someone else. When partners can see the answer for themselves, such as delivery status, stock or the progress of a case, they can respond to their own customers without calling you. Value lands twice: once in your cost to serve and once in the partner’s relationship with their customer.

A use case isn’t a use case until you can name the person whose day gets better, the moment in the journey, and the measure that will move.

The test

Before anything goes on a roadmap, I ask three questions:

• Whose day gets better: which customer, which colleague?
• At which moment in the journey?
• Which measure will move, and what is it today?

If you can’t answer all three, you have an idea, not a use case. Go back to the journey. It’s usually only a few hours of watching away.