§ Case Study · Journey Management · In progress
Turning scattered customer insights into a journey that teams can understand, use, and improve together.
Product teams optimise their own screens. Research sits in reports. CX tracks satisfaction. Tech logs errors. Each view is accurate, and none of them shows what the customer actually experiences from end to end.
Journey Management closes that gap — not by producing a better diagram, but by giving every discipline one shared view of the customer experience that they contribute to and make decisions against. That only works if the journey is maintained, connected to real evidence, and used in the places where scope gets decided.
§ 02 — The starting pointWhen I picked the work up, two things were already in place: CXomni had been selected as the Journey Management tool, and initial stakeholder conversations had happened. What didn't exist was everything that makes a tool useful.
So the work was never really "create a journey map." It was to establish a practical way for UX, PX, Product, CX, Tech, and Data to work from the same end-to-end view.
§ 03 — The challengeThe predictable failure mode for journey work is a beautiful artefact that nobody updates. Six months later it describes a product that no longer exists, and teams quietly go back to their own views.
Avoiding that meant treating the journey as infrastructure rather than a deliverable: it needs a structure people can add to without asking permission, evidence attached to the right place, and a reason for teams to open it during planning rather than after.
§ 04 — The first journeyRather than mapping the whole organisation at once, we started with one journey that mattered and could be built properly: the operative purchaser — the same persona at the centre of the marketplace redesign — moving through her core purchasing path.
Five stages is deliberately modest. It's narrow enough to complete to a real standard, and recognisable enough that every team can find their own work inside it.
§ 05 — Anatomy of a stageThe structure is what makes a journey usable by more than one discipline. Each stage holds eight layers, so a researcher, a PM, and an engineer can all open the same stage and find the thing they came for.
What the buyer is trying to achieve at this point, in her terms.
What she actually does, and where — screen, email, phone, offline.
Where the experience breaks down, blocks, or slows her.
Evidence from interviews, usability tests, and feedback — attached to the stage it belongs to.
What could be improved, framed as an opportunity rather than a solution.
Known constraints, errors, and dependencies affecting this stage.
The delivery work already connected to this part of the journey.
The measures that tell us whether this stage is getting better or worse.
Most organisations don't lack research. They lack a way to find it again. A finding lives in the presentation where it was first reported, and the person who needs it eighteen months later doesn't know it exists.
CXomni does real work: it holds the journey structure, connects insights, opportunities, KPIs, and Jira tickets to stages, and makes the whole thing visible to everyone at once. That's the enabling layer.
But a tool doesn't decide who maintains a stage, what qualifies as an insight worth adding, or when the journey gets reviewed. Those are the parts that determine whether anyone still uses it next year.
One agreed anatomy, so every stage is built the same way.
A named owner per journey and per stage, accountable for currency.
What gets added, by whom, at what level of evidence.
A recurring rhythm for updating, not an annual clean-up.
Opportunities connect to Jira, so the journey touches real work.
Enough common understanding that teams read the journey the same way.
The point of a shared journey is that each discipline contributes what only it can see, and reads what the others contribute. UX and PX bring qualitative evidence and opportunities; Product brings scope and priority; CX brings satisfaction signals; Tech brings constraints and error reality; Data brings the KPIs that show movement.
Getting there is largely a stakeholder task rather than a design task — showing each group what the journey gives back to them before asking them to maintain a part of it.
This is a practice being built rather than a project being delivered, so my contribution is a mix of structural design, research integration, and internal advocacy.
The practice is partly established and still being built. Rather than claim an outcome, here is what is actually true today.
First journey set up in CXomni. Structure and information layers defined. Existing research and user needs brought in. Initial stakeholders involved across disciplines.
Populating stages to a consistent standard. Connecting insights, opportunities, KPIs, and Jira tickets. Establishing ownership per stage and a review rhythm.
Extending beyond the operative purchaser to further journeys. Embedding the journey in planning and prioritisation. Contribution rules and shared literacy across teams.
Evidence of adoption once available — journey views, stakeholder feedback, and examples of decisions the journey actually informed.
Journey Management becomes valuable when it moves from being a visual map to becoming a shared decision-making tool.
Everything difficult about this project has been organisational rather than visual: agreeing a structure, finding owners, making contribution cheap enough to happen, and giving teams a reason to look. The diagram was the easy part — which is the same lesson the marketplace redesign taught, in a different register.