How to run a journey mapping session that finds the drop-off

On-Off Group

October 2026

Run the journey mapping session around numbers you pull beforehand: volumes, turnaround time and completion at each step. Map the real flow, mark where people stop, then agree one drop-off figure and one turnaround time as your baseline before anyone leaves the room.

This is for digital and CX teams who have already run a journey mapping session, filled a wall with sticky notes, and come out with nothing they could show a boss.

The fix is getting a few numbers before the session starts. It is pulling a handful of numbers before the session starts, and refusing to end the session until one of them has been agreed as a baseline.

Here is the order that works, based on running these sessions for Philippine banks and insurers since 2015.

Get the numbers on the wall before anyone talks about pain points

The normal version: the workshop opens, everyone describes the customer's experience from memory, and the wall fills with opinions. Nobody can say how many customers are actually affected, so the loudest story wins.

Before the session, ask for four things about the journey you are mapping. How many people start it a month. How many finish. How long it takes end to end. Where the handoffs sit between systems or teams.

It will be incomplete. That is fine. Print what you have, tape it up, and put a blank sheet next to it headed "we don't know". Onboarding volumes usually exist somewhere. Turnaround time often does not, and that gap is itself a finding worth writing down.

Once the room can see how many customers start the flow and how many finish, the talk moves off opinions and onto the steps where people drop out.

Map what happens, not what the process document says

The process document shows the flow as it was designed, not as it runs. The real one includes the call to the branch, the screenshot sent over Viber, the form that gets re-typed by an officer because the upload keeps failing.

So map with the people who do the work. Branch staff, contact centre agents, the ops person who clears the queue. Not only the managers who own the journey.

Run it as one horizontal line of steps, left to right, one step per card. Under each step write two things: who touches it, and how long it sits there. Most of the turnaround time is waiting time between steps, and that waiting time is not in the process document.

A useful rule in the room: if two people describe the same step differently, you have found a step worth investigating. Do not resolve it by vote. Write both versions and move on.

Mark where people stop, and argue about it

By this point the wall has a flow. Now go step by step and ask one question: how many people are still here.

Some of that comes from analytics. Some comes from a system report nobody has opened in a year. Some comes from asking the person who processes the queue how many applications they reject and why.

Mark the drop between each step. Two or three steps will be obviously worse than the rest. That is your shortlist, and it is usually not where the team expected. Verification, document upload and anything requiring a second visit tend to be the ones.

More on doing this part without the wall of sticky notes: Instead of sticky notes on a wall, get a drop-off number out of the session.

Leave with one number written down and owned

This is the step that gets skipped, and it is the reason the last session produced nothing you could report.

Before people leave, agree two figures for the journey you mapped. Completion rate, start to finish. Turnaround time, in days or hours. Write them on one sheet with the date and the name of the person who pulled them.

If the number is a guess, label it a guess. A rough baseline you can measure the same way in eight weeks beats a precise number nobody can reproduce.

That sheet is what makes the next conversation possible. When somebody asks whether the pilot worked, you have a before figure to put next to the after figure. Without it, all you can say is that it feels better, which is how a six month project ends in a slide pack.

Fix one journey, measure it, then widen

After a good session the pull is to fix everything at once, which turns into a platform project and no change to turnaround time this year.

Pick the one step with the worst drop. Change that. Measure the same two numbers again.

In a series of five-day design sprints with a large insurer, customer-facing web journeys that had previously taken six months or more to get out were designed and tested with customers in two weeks and live in four. Completion rates on the new journeys rose 80 per cent and the old drop-off points disappeared. What made that possible was knowing which step to attack and having the old completion figure to compare against.

The argument for going one journey at a time is here: Instead of a platform project: ship one customer journey, measure it, then widen.

If AI is on the list, do the mapping first

A lot of these sessions now end with somebody suggesting a chatbot or a document reader on the worst step.

Sometimes that is the right call. But if most customers already abandon that step, automating it only makes them abandon it faster. Get the completion figure first, fix the obvious break, then decide whether AI is the next move. Fix the customer journey before you put AI on it covers what that looks like in practice.

What to do this week

Ask for monthly starts, monthly completions and end-to-end turnaround time on one journey. Note what nobody can answer.
Invite two people who touch the journey daily, including someone from branch or the contact centre.
Book two hours, not a full day, and map one journey only.
End the session with a single sheet: completion rate, turnaround time, date, and the person who owns the number.
Put a date eight weeks out to pull the same two numbers the same way.

Questions people ask

What if we have no data to bring into the session?
Bring what exists, even if it is rough: application counts, cycle times from a system log, or a manual tally kept by branch staff for a week. A weak number you can repeat later is more useful than no number at all.

How many people should be in the room?
Small enough that everyone speaks. The people who touch the journey daily, one person who can pull the data, and one person who can approve a change to the flow.

Should we map the journey or run usability testing first?
Map first if you do not know where people stop. Once the session points at one or two steps, watch five real users try those steps on video, because that shows you why the drop-off happens.

How long until a mapped journey can actually change?
Faster than most teams expect. In a series of five-day design sprints with a large insurer, journeys that had taken six months or more were designed and tested with customers in two weeks and live in four.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with customer journey mapping.