Mapping the Customer Journey

Before a project starts, draw how the customer lives that process today, end to end. From first contact, whether that is a call, WhatsApp or the web, through to the outcome: which steps do they go through, where do they wait, and at which point are they handed to a person?

This mapping workshop is usually the moment teams see their own process whole for the first time. There is a reason for that. Every team sees the process through the metric it measures. Customer service looks at average handling time, operations at call volume, IT at system uptime. Customer service says "waiting times are long", operations says "call volume is high", IT says "the integration is complex". These are different symptoms of the same process, but three separate teams carry them as three separate complaints without knowing it. Put the process on one timeline and it becomes clear that all three are describing the same thing. Each of them is simply looking at a different part.

The purpose of this stage is to record, not to analyse. You are not yet deciding where the problem is. You are drawing the process exactly as it stands, without judgement. A concrete example: mapping a bank's card unblocking process might produce a table like this:

The table carries no verdict on its own. It only makes the process visible. Even that visibility is usually surprising enough: most teams have never seen it written down that their process has this many steps or touches this many systems.

A suggested workshop format: one representative each from customer service, operations, IT and compliance draws the current process step by step in a session of two to three hours. Four questions are asked for every step: what happens here, on which channel, how long does it take, which system is used. The output is not a flow diagram. It is a document in which every step answers those four questions, and it becomes the raw material for the next phase, identifying friction points.

Two mistakes are common. The first is running the mapping with the IT team alone. IT sees the process through systems and knows what the system does, but not where the customer loses patience. A map drawn without the teams who own the process, customer service and operations, is technically correct and disconnected from reality. The second is mapping the process as it should be rather than as it is. What the procedure document says and what the agent actually does are often different; agents develop their own workarounds wherever the system falls short. Mapping has to make those workarounds visible too, otherwise the real problem never appears on the map.