Agentic AI is changing how we interact with services, so it’s time to change how we think about the classic customer journey.
A
I’s arrival will reshape how services are experienced in two significant ways. One is where AI is taking the place of the human who previously used to access and interact with the service. The other is where organisations try to use AI to serve them more efficiently. Both of these related developments have huge implications for service design.And it’s why, instead of diving head first into experimenting with AI, we need to step back and take a wider view of what’s going on.
Over the last decade, customer journeys were something we thought we could see. We mapped them in Miro. We colour-coded touchpoints. We traced pathways from discovery to conversion to support, and end of service. Product teams rallied around the maps. Executives nodded approvingly at accompanying slide decks.
But I believe we forgot something along the way. Journey mapping was only ever a means to an end: a way for teams to get agreement and alignment by capturing how customers interacted with services, where they were having issues, and what might be missing.
The truth is, these maps were an idealised, ordered version of how people moved through services, and they didn’t always reflect the messy reality of exceptions, edge cases and escalations.
In a world of AI, it’s time to stop thinking about the map as the artefact: and I say this as someone who’s been guilty in the past of creating big journey maps that I definitely polished more than was strictly necessary.
(I’d still argue there’s a time and place where maps are still really valuable. But the metaphor doesn’t always do justice to the world we’re living in now.)
That world is one where the ‘customer’ we’re designing for might not be a human at all. AI’s capabilities are progressing rapidly, to a point where automated systems can – in theory anyway – make decisions and take action with little or no human intervention. A customer might ask ChatGPT to choose a pension provider or recommend a savings plan. They might rely on a virtual assistant to book a holiday. A smart fridge can re-order products before the owner even knows they’re running low on milk.
(I’ll say here: I’m not making the argument that AI will be doing this for everyone. I would not be comfortable letting AI book me a £5,000 holiday end to end without having been involved in the research myself and seen some of the options. That’s too much responsibility to give to an automated decision system.)
These voice assistants, chatbots, summarisation engines, and recommendation models don’t work the same way that people do. They reframe, reroute, or entirely bypass traditional flows.
These ‘customer’ journeys aren’t linear sequences from homepage to product to checkout, or from problem to solution to support. These agents don’t see visual design or read pages. They parse structure, logic, and trust signals.
With AI, journeys are now generated in real time, based on context, intent, channel, and prior history. Two people with the same need might experience the service in completely different ways: one through a chatbot, another through an AI-written summary, a third through a human agent who never sees the same tools or prompts.
And most organisations can’t see any of it.
If your service isn’t legible to these systems, it may never reach the person at all.
I’ll pause here to give reassurance. I’m not trying to describe some dystopian future; in fact, it’s just a little bit of history repeating. What’s happening now reminds me of SEO’s early days, when we had to make websites readable to both humans and search engines. We used schema, tags, and alt text to help crawlers interpret what we were offering, even when it wasn’t visible to the human eye.
This is why the ‘map’ metaphor no longer holds up. And it’s why we need to be intentional about our design choices both as the customer perceives them, and how they work in practice within the organisation.
We need a systems view.
Choosing where to deploy AI along a customer journey is a decision that needs to be thought through and designed intentionally. That’s especially true of larger organisations like telcos or financial and insurance businesses with multi-service offerings.
Most large organisations are trying to lower the number of customer calls coming into their call centres and they see AI-powered chatbots as a way to reduce their cost to serve. Today, that might work for narrow tasks that are easy to fix, like updating a customer’s email or postal address. But for a multi-product customer, the ways it can go wrong exponentially increase.
Large organisations are siloed and can operate independently, but it’s worth remembering that the customer doesn’t see those multiple entities, and they don’t think in terms of journeys; they think they’re dealing with one brand, and they just want a question answered or a problem solved. At what point does the AI stop becoming useful, and when does a human need to intervene and support the customer?
Taking a service design approach means going back to basics and asking fundamental questions about what you’re trying to do with AI: is it just to gain efficiencies in the business, or is there a material benefit to the customer by solving their problem and delivering a meaningful interaction?
That’s where service design provides the structure to scale safely. It brings the messy reality of human workflows into view. AI systems involve multiple teams, from product and engineering to IT and compliance. Each has their own goals, constraints, and interpretations of what ‘good’ looks like.
Service design helps teams define where AI fits, what it changes, and how to keep the experience coherent, even when decisions are distributed across people, models, and machines. It’s a great way to deal with the increased complexity that AI brings, because it helps us to consider multiple ‘actors’ rather than single ‘customers’: we can use it to think about AI-augmented, non-linear, multi-agent contexts.
Service design gives teams a shared structure for ownership and alignment, and avoids a situation where the systems drift and friction grows.
There’s still a place for maps: use them to align teams. But the concept of a map implies fixed, unchanging terrain: borders, landmarks, and predictable routes, whereas journeys in AI-powered services don’t behave like that. Instead, they’re fluid, adaptive, and partly invisible.
We need a new vocabulary to reflect the coming reality that the human/customer/user isn’t always the one in control. That calls for words like orchestration, simulation, navigation and agent-aware design.
Personally, I’m drawn to the metaphor of an orchestra because it makes us think of a conductor managing distributed groups of musicians, playing different instruments at different registers, while the audience experiences a unified, cohesive piece of music. The metaphor fits because modern services are a mix of human, machine and invisible actors operating asynchronously. It reflects coordination across roles, channels, and contexts, not just steps.
That leads us to tools to manage the system. Orchestration platforms like TheyDo or JourneyTrack let organisations link journey steps to owners, metrics, and live updates. These aren’t replacements for design thinking. They’re scaffolding for the operational reality I’ve described above.
To be ready for this new world of AI, we need to make journey management an operational necessity, not just a research or design activity.
Journey management software alone won’t do it: there’s skill and leadership needed to make things work within a large organisation, by winning people over to a shared vision using service design principles. Start by going back to basics. Ask: what are we trying to design? Do we need to re-engineer workflows with humans alongside AI? The hard work of getting various teams and departments to agree on a shared view of the world is needed more than ever.
Then when the team is aligned, it can build services that make sense to humans and to machines, and design for ‘users’ we may never see. It’s time to start treating journeys not as static maps, but as systems in motion, and to build shared models that allow cross-functional teams to sense-make, experiment, and coordinate. Like an orchestra.