The power of a visual for customer experience management

How a mundane thing changed the quality of our customer experience orchestration.

Many people at Swisscom work on improving customer experience. In fact, they’re working on many individual experiences in individual projects. Everyone tries to do their best to understand what everyone else is doing to make sure the user experience fits.

Experience orchestration in the past

In the past we’ve been sending back and forth presentations to outline what we’re doing. These include — of course — a business case, a prose description of the approach and a list of requirements. We’ve had a management board review those experience projects and sign them off for realisation.

A few months later they’d have been released to our customers at which point we would finally see whether all individual experiences come together as one.

Decreasing time to market

At the same time we’re rebuilding our organisation to release experiences quicker. Lots quicker actually — every month instead of a few times per year.

This leads to us making smaller changes to the customer’s experience. But at the same time, we’re making many more changes, which are harder to find, understand and communicate.

Step one: visualise what’s next

I’ve thus introduced a very mundane thing. We require all projects to create one single visual. We’re looking at all of those once a month with everyone.

The single visual needs to follow a single rule: it needs to show what customers will experience. Apart from this rule it can be anything, from an aesthetic mock-up over an ugly whiteboard scribble to a plain short text message. I print all these and hang them in a physical room.

The crucial trick now is when we’re looking at those visuals. As said we’re doing this once a month, but we’re doing it nine to twelve months before it’s released to the market. This is long before we actually start conceptual design (and long before a board signs off the project’s implementation).

Benefit: a trigger for alignment

With this, we’re giving the experiences’ owners a trigger to do two things:

• first, start their project ideation with an experience (instead of a prose description) and
• second, know who they need to align with (before even starting conceptual design).

What I haven’t solved so far is how projects methodically do the actual experience alignment. But we’re working on this with an agile setup.

I’m curious: how do you orchestrate experiences?

— This article is about my work at Swisscom and written in my personal capacity.