There’s always someone arguing the customer journey map can be built in a workshop.
Get the right people in a room for a day, sketch the stages, agree the pain points, done.
It produces something.
It just produces the version the organisation already believes about itself, which is the one thing a journey map shouldn’t be.
Doing it properly means several analysts working in parallel across different parts of the business, then somebody holding all of it together.
That coordination is a different job to process mapping, so it’s worth being deliberate about.
🧭 Set the spine before anyone starts
The first mistake is sending 5 analysts out with no shared frame.
They’ll come back with 5 different levels of granularity, incompatible terminology, plus maps that can’t be joined.
Agree the spine first.
- The stages, named from the customer’s point of view rather than the organisation’s
- Where the journey starts, which is usually earlier than anyone expects
- Where it ends, which is often after the transaction rather than at it
- The channels in scope, including the ones nobody owns
- Modelling conventions, so every map joins cleanly at the edges
- A task ID scheme that stays stable when names change
Half a day agreeing that saves 3 weeks of rework later.
The stage names matter more than people think.
“Application received” is the organisation’s framing.
“Waiting to hear back” is the customer’s.
Same moment, completely different map underneath it.
👥 Divide the work without fragmenting it
The obvious split is by internal team, since that’s how access works.
It’s also the split that guarantees you’ll miss the handoffs, which is where most customer pain actually lives.
Better to assign analysts by journey stage rather than by department.
One analyst owns onboarding end to end, across every team it touches.
Another owns the complaint path, wherever it goes.
That way somebody is accountable for the seams.
A few practical rules.
- Every handoff belongs to whoever owns the stage it lands in
- Where 2 stages meet, both analysts attend the same session
- Nobody maps a stage they can’t follow to its conclusion
- Each analyst produces a short list of open questions, not just a map
🔁 Keep them aligned without meeting constantly
Daily standups are overkill on work that moves in weekly increments.
Twice weekly works better.
Monday is forward looking, covering focus for the week, what’s blocked, who clears it.
Friday is backward looking, covering what’s done, what’s carrying over.
Between those, run a fortnightly session with a different purpose entirely.
Put the partial maps up next to each other, then look only at the joins.
That’s where you’ll find the customer waiting 3 days because 2 teams each believe the other initiates the next step.
Nobody finds that inside their own stage.
📊 Insist on numbers alongside the maps
A journey map without data is a diagram of opinions.
Ask every analyst for the same basic figures against their stage.
- Volume through each path
- Elapsed time, particularly where the customer is waiting
- Drop off or abandonment points
- Contact volume generated, meaning how often the customer has to chase
- Rework rate
That fourth one is the useful one for journey work.
Every time a customer has to follow up, something upstream failed.
Map where those contacts originate, then you’ve located the problems worth fixing, in priority order.
Numbers also protect your team.
When a department disputes a finding, an analyst with volumes behind them holds the line far better than one with a diagram.
🗣️ Protect your analysts from the politics
Journey work crosses departmental boundaries, so it surfaces things people would rather weren’t surfaced.
A team will occasionally push back hard on a map that makes them look slow.
Your job is absorbing that, rather than leaving a mid-level analyst to defend it alone.
What helps.
- Brief department heads before their area gets mapped, not after
- Frame findings around the customer experience, never around a team’s performance
- Present both accounts where teams disagree, letting the owner decide
- Never let an analyst arbitrate between 2 departments
- Take the difficult meeting yourself when it comes
An analyst who gets burned once in front of a director becomes cautious for the rest of the program.
Cautious analysts produce sanitised maps, which defeats the exercise.
✅ What you’re actually delivering
The map is the artefact, not the output.
What lands with an executive is shorter.
- Where the customer waits, plus how long
- Where they have to repeat themselves
- Where they give up
- Which moments generate most of the inbound contact
- What each of those costs, roughly
Lead with that, put the maps in the appendix.
Then be clear about which fixes are cheap, which need investment, which are governance decisions rather than process ones.
Your team spent 8 weeks understanding the journey.
The value of that work depends entirely on whether the last 4 pages are readable by someone who wasn’t there.
About the author
Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.
His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.
He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.
alisodigital.com
