Customer experience architecture: why customer journeys aren’t enough

The ways we visualise and understand our organisations leave us with slices of insight that don’t align with each other. We have hundreds of views of what we do and how we do it. There are org charts and RACI’s, technical architectures, enterprise architectures, product lists, feature lists, customer segmentation and marketing rollout plans. But so few of those individual artefacts show how one connects to another to actually deliver value to your customers.

Customer journey maps promise to show you how you deliver value to your customers, but only in slices of the overall experience. They often fall short of delivering on their promise because they don’t play well with each other. There isn’t an agreement about how granular they should be. One is called “buying journey” another is “pay by card” and another “purchase product in store.” This is what happens where there isn’t anything to anchor these to. Each team creates a journey that works for them and their focus. They may be responsible for a single product, or moment, or channel. But when compared to everyone else’s journeys, it’s hard to see how they all connect. If they don’t connect, how do you use them to inform decisions? Enter the Service Architecture.

A unifying scaffold

A Service Architecture is a single, shared view of how you deliver value to your customers. This is the most powerful view of your organisation. More than your org charts, more than your distribution or sales numbers, more than your tech stack. The Service Architecture provides the common reference for all the other documents to hang from. Why services? It’s the one thing that doesn’t change very often. You need a centre that stays still. Org charts change every other year, technology and processes change day to day, products get new features all the time. But what your customer is here to do does not change very often. As the most consistent vantage point, they make the perfect central connector. Besides, there’s no way HR is going to orient themselves around the tech stack.

Service Architecture example overview.

A Service Architecture is made up of nested journeys, and processes oriented across a customer lifecycle. Organisations typically have just one. Occasionally there’s a separate one for the employee lifecycle, but that’s another article.

This framework enables an “outside-in” view of the business, with a common language and approach to label, discuss, share, report on, and therefore improve the customer experience across an organisation. It helps to drive customer-centric understanding and culture by moving away from product, process, system, departmental, channel thinking, towards a customer’s point of view when discussing business performance and value creation.

At a high level, nothing is left out and nothing overlaps. On one page (maybe a big page) you can see everything your organisation does for customers. At the lower levels, the overlapping parts are the most interesting. It can show whether the same broken process is wreaking havoc across the experience, or whether it’s an isolated issue. Line up your technical architecture to your services and you’ll find out that you have five different systems doing the same thing. Not great, but at least now you know.

Layering information for smarter insights

The beauty of creating a Service Architecture is that once you have established it, you can then use it to look at your business through different lenses. It may be that you want to see where the main cost centres are and how they align with revenue, or you may want to see how all of your IT systems underpin and support each of the services you provide. You can apply each of these different lenses as an overlay onto the basic framework of the Service Architecture.

Think of these different lenses or overlays like layers in Google Maps. In the illustration below, if we take the Manhattan grid and how that sits within the context of New York as a metaphor for Service Architecture, you can then see that once you have the foundation, you can then start to apply a number of different layers to it. You can zoom in and out to get different altitudes and apply different filters to find what you need.

Google Maps example with Manhattan grid overview.

The point about this is that everyone across the business is then using the same underlying structure as a reference point, and so they are able to use this as the basis for any number of different enquiries and perspectives. The more layers you add, the more powerful it is as a strategic tool.

An early example of the Service Architecture we created for UK Parliament, with sub-journeys colour coded by the team leading that work. Further research revealed there were 20 roles across 10 teams for the Employee Onboarding service alone.

Depending on the decisions you need to make, and the information you have, it can be used to achieve different goals and inform tradeoffs. Which platform underpins your most important customer moments? Which team is responsible for the best performing experiences? Which journey’s performance is most closely correlated with churn? You can layer on multiple sources of data to understand and demonstrate where issues overlap and opportunities compound. How many teams are “collaborating” to deliver your services without ever speaking to each other? How would it change your performance if they did? Will that expensive transformation programme even affect your most critical journey? The scope for these different overlays is endless and is only limited by the ambition of the organisation and the quality of data available.

When multiple overlays are used, the questions you ask can become more detailed. Building on the google maps analogy, rather than search “sushi restaurants” you can search “sushi restaurants on a cycle lane with more than a 4 star rating” You can use a Service Architecture to prioritise the next round of change initiatives. Which new project could address legacy technology and resolve a compliance risk?

Reflecting your organisation back to you

Service Architectures reflect the organisations they serve. Some are deceptively simple, others describe a whole industry. Each is influenced by the people who are involved in its creation. A well-designed Service Architecture can enhance the customer experience and streamline business processes, resulting in increased efficiency, alignment, and profitability. There isn’t a single right answer, but there are definitely wrong ones. A poorly designed Service Architecture can do more harm than good, leading to confusion, frustration, and ultimately exacerbating existing challenges.

Service Architectures can vary greatly in their complexity to reflect the organisations they describe. Here is one for a manufacturer, and one for a fintech company.

It’s important to note that once you’ve seen your Service Architecture, you can’t unsee it. A properly made Service Architecture will change the way you look at your business, your teams, your services, everything.

Though simple to read and intuitive to use, making them isn’t straightforward. It’s a blend of art and science. This is because there’s usually no collection of documentation, articulation or visualisation of everything an organisation does all in one place. There’s a delicate process of synthesising information that often lives in people’s heads. Stay tuned for part two where we talk about how these are made.

Want to create lasting

change?

Get in touch

Customer experience architecture: why customer journeys aren’t enough

Want to create lasting change?

Want to create lasting

change?