The Customer Journey Mapping Workshop Cookbook: Pre-Work, Agenda, Decision Map, Fix Owners

Customer journey mapping is the practice of laying out, on one page, the steps a person takes to reach a goal, together with what they think and feel at each step. Nielsen Norman Group defines a journey map as a visualization of the process that a person goes through to accomplish a goal. In its simplest form the work starts by compiling a series of actions into a timeline, then adds thoughts and emotions to turn the timeline into a narrative. The purpose is not a handsome diagram. It is a shared picture that people from different departments can point at when they disagree.

The strongest reason to run a workshop is organizational, not creative. NN/g observes that fragmented understanding is common where success metrics are siloed, because no one is responsible for looking at the whole experience from the customer's side. Marketing sees the click, sales sees the call, support sees the complaint, and nobody sees the week in between. A workshop puts those views in one room and forces them to be reconciled. A second reason is analytic. NN/g notes that when analytics show something happening, such as a plateau in online sales, a journey map can help find out why.

This pack gives you four working pieces. The pre-work checklist makes sure the room arrives with evidence. The agenda runs three hours and ends with decisions. The decision map is our adaptation of the usual action, thought and emotion rows: it centers each phase on a decision the buyer is making and records where our materials, people or processes fail to support it. The fix-ownership sheet carries the findings into work that someone is accountable for. Each piece has a CSV you can edit.

It is not always the right tool. A journey map suits scenarios with a sequence of events, a process that unfolds over time or several channels. NN/g notes that blueprints, which extend a journey map to include what happens behind the scenes, are better suited when the experience is omnichannel or requires several departments to coordinate. If your question is about one page or one screen, a usability test or a conversion review will answer it faster. Be honest at the start about which of these you are doing.

Choose the actor first. NN/g advises one point of view per map, with the example that a university would build separate maps for a student and for a faculty member because each produces a different journey. The same applies to a business that sells to both a buyer and an influencer, or to a founder and a finance lead. Name the actor in one sentence and write what they are trying to achieve, in their words, as the scenario. "A facilities manager at a mid-size office trying to replace a failing supplier without disrupting tenants" is a scenario. "Our customers" is not.

Then collect what the company already knows. The GOV.UK Service Manual lists ways to learn about users, starting with reviewing existing evidence such as analytics, search logs, call-center data and previous research. Do the same here. Pull the site search terms and the most common entry pages, the questions asked on sales calls, the reasons recorded for lost deals, support tickets from the first thirty days, and any survey or review text the company is entitled to use. Anonymize anything that identifies a person, and keep the original wording, because the exact phrases are what make the map credible.

If evidence is thin, schedule a few customer conversations before the workshop rather than filling the gap with guesses. Ask people to walk you through the last time they went through the scenario, in order, from the first moment they realized they had the problem. Ask what they did, what they were afraid of and who else they consulted. Ask for the moment they nearly gave up. A handful of well-run conversations beats a room of confident opinions. We do not give a minimum number because the right number depends on how varied your customers are.

Choose participants who touch the journey at different points: marketing, sales, support or customer success, someone who owns the web experience and one person with authority to commit resources. Keep the group small enough that everyone speaks. Send the evidence a few days ahead with a request to read it, and assign one person to bring each source. Give the facilitator control of the wall, and the sponsor the final say on priorities. Mixing those roles leads to a day where the loudest person draws the map.

The agenda below is built so that the group maps first and judges second. The temptation in any mapping session is to jump to solutions the moment a pain point appears. The facilitator's job is to park those ideas on a separate board and keep the group on the journey until it is complete. Solutions come in the final blocks, when the group can see which pain points matter most.

Use two colors of card throughout. One color is for evidence, with the source written on it, and the other is for assumptions. A map that is entirely one color is a warning. All evidence suggests the group has not yet tried to describe the parts nobody has data for. All assumptions suggest the pre-work was skipped. The ratio is not a score. It simply shows the group where the map is solid and where it is a guess, and the assumption cards become the list of things to check afterward.

Keep the session timed, and let the facilitator cut conversations that run over by writing the unresolved point on the parking board with an owner. Hold the break. People who return from a break make better decisions than those who sat through three hours of back-to-back argument. If the group is remote, keep the same agenda but shorten the blocks and use a shared board with the evidence cards pre-loaded, and ask people to place cards silently for the first few minutes of each block so that quieter participants are heard.

NN/g describes the middle of a journey map as high-level phases made up of the actor's actions, mindsets and emotions, and notes that mindsets are the person's thoughts, questions, motivations and information needs, ideally in customers' own words. The decision map takes that framework and puts the choice at the center of each phase. Every phase has a decision, such as "do I trust this supplier enough to ask for a quote", and the other columns describe what the person asks, what they look for, what they find and what they do next.

The columns are deliberately few. The phase names the stage in the actor's terms, not the company's. The decision is the choice they are making, written as a question. The questions they ask are the specific things they want to know, quoted where possible. The evidence they look for is what would reassure them: a price, a person, a reference, a demonstration. What we provide is the page, message, call or document they actually meet. Where it fails describes the gap, and the evidence column links to the card on the wall or the source on file. A final column records the emotion in a word or two, since feeling often explains why a person stopped.

A phase label from the company's own vocabulary is a common trap. HubSpot's lifecycle stages, such as lead or marketing qualified lead, describe how the company classifies a record, not how a person experiences the journey. Use them later, to connect the map to your CRM reporting, but begin with the phase names the actor would use. NN/g gives examples of phase sets that vary with the scenario, from discover, try, buy, use and seek support for an online purchase to engagement, education and later stages for a large purchase. Your phases should come from your evidence.

Write the failure column in plain, checkable terms. "Pricing page does not say what is included, so buyers ask on the first call" is a failure that points to a fix and a check. "Website feels cold" is a mood that no one can own. If the group can only produce a mood, mark the row as an assumption and add a research task to find out what the person actually experienced.

NN/g notes that the output of a map is often a set of opportunities and internal ownership, and the order matters: opportunities with no owner are the reason most maps end up on a wall. The fix-ownership sheet is where the workshop turns into work. Each row is a fix, linked to the failure point it addresses. It has an owner role, the measure that will show whether the fix helped, a check that someone else can run to confirm the fix is in place, and a review date.

Be careful with the measure column. Use a measure that the company already collects, such as the share of new leads that book a call, the number of pricing questions raised on first calls, or the count of tickets on a topic. Do not invent a target number in the workshop. A target needs a baseline, and the baseline needs data that the room may not hold. Write the existing measure, name who will pull the baseline, and set the target after the baseline is known.

Separate fixes by the size of the job. Some are small enough to ship in a week by one person and need no coordination. Others cross departments, such as a change to how a lead is handed from marketing to sales, and need a more detailed look. NN/g describes service blueprints as a second step after the journey map: a diagram that links the customer's steps to frontstage actions the customer can see and backstage actions they cannot, along with the supporting processes. If a fix has a backstage component, build the blueprint for that phase before committing to a date.

Limit the number of fixes taken forward. A map can generate dozens of ideas, and a team that commits to all of them completes none. Choose the few that address the highest-ranked failure points, put the rest in a visible backlog and revisit it at the review date. The backlog is not a graveyard. It is a record that the group saw the problem, which matters when a later review finds that it was the right call to wait.

Close the loop by checking whether a fix worked. At the review date, rerun the check, pull the measure and compare it with the baseline. Update the decision map: strike through failures that have been fixed, add new ones, and move assumption cards to evidence or remove them. A map that is never updated starts to describe a company that no longer exists.

The wall at the end of the day is a hypothesis. It reflects what the people in the room know and believe, backed by whatever evidence they brought. Before large decisions rest on it, test the assumption cards. Interview a handful of customers who fit the actor, ask them to walk through the decision map, and note where it is wrong. Review recorded calls or tickets where the company has consent. Compare the failure points against the analytics. The GOV.UK Service Manual says good user needs should be based on evidence from user research and not on assumptions, and that they should be validated and refined continually as you learn. The same discipline applies here.

Share the result in a form that people will open. A photograph of the wall and a one-page summary of the actor, the scenario, the top failure points and the owned fixes will do more than a long report. Send it to participants within two working days while the discussion is fresh, and ask them to flag errors. Store the decision map and the fix-ownership sheet in a shared location with a version date, and link them from the place where marketing, sales and support plan their work.

Set a review date for the map itself. Journeys change when pricing changes, when a new channel appears, when a competitor changes what buyers expect and when the product changes. A reasonable default is to revisit the map when the fix review happens and again at a longer interval that suits how quickly your business changes. If the map is no longer true, say so and retire it. A stale map misleads more than no map.

Last, keep your claims about the map modest. A journey map does not prove that fixing a failure point will raise conversion, and this cookbook does not claim it will. It shows where buyers appear to need something the company does not provide, and it gives the company a shared way to decide what to fix first. The proof that a fix helped comes from the measure at the review date.