Two ways to use the tool — both directions of the same coin.
Customer experience (CX) and operational excellence (OpEx) are two sides of one coin. This tool connects them. Below are two complete, step-by-step worked examples: one running forward — from a customer journey to an executable process — and one running backward — from a live process and customer feedback to a redesigned journey.
All companies, personas, quotes, metrics and diagrams below are invented for illustration. The fictional company is "Northwind Cloud," a mid-market B2B SaaS provider, and the persona is "Elena," IT Operations Lead at a customer account.
You start outside-in: you map how the customer experiences things today, design how they should experience them, then translate that target into an executable process your operation can actually run. The customer's experience becomes the specification for the operation.
Scenario
Northwind Cloud's renewal experience is leaking revenue. Customers say renewals feel like a surprise invoice, and the Customer Success team is firefighting cancellations. The goal: redesign the renewal journey, then operationalise it so it runs the same way every time.
Frame the journey and the persona
Step · scope
Pick one journey and one persona — narrow beats broad. Define the trigger (where it starts), the goal (what "done" looks like for the customer), and the boundary (where it ends).
Journey: Subscription renewal
Persona: Elena — IT Operations Lead, renewal decision-maker
Trigger: 90 days before contract end · Goal: renew with confidence · Boundary: signed renewal or churn
Output A one-line journey charter everyone agrees on before mapping starts.
Map the As-Is journey (what happens today)
Step · As-Is CJM
Lay out the current stages left to right. For each, capture the customer action, the touchpoint/channel, what they feel (emotion), and the friction. Use evidence, not opinion — pull from tickets, interviews, and survey verbatims.
Stage
Customer action
Touchpoint
Emotion
Pain point
Awareness
Gets a renewal invoice by email
Billing email
Surprised
No heads-up; feels transactional
Review
Tries to compare usage vs. cost
Portal · spreadsheet
Frustrated
Usage data scattered, hard to justify internally
Decision
Escalates to procurement
Email · phone
Anxious
Slow back-and-forth, unclear who owns it
Action
Signs (or stalls)
PDF contract
Reluctant
Manual signature loop; deadline pressure
Post
Waits for confirmation
Email
Uncertain
No confirmation that anything changed
Output An evidence-based As-Is map with the friction (the red zones) made visible. The renewal "moment that matters" is the Review stage — that's where trust is won or lost.
Design the Future journey (what should happen)
Step · Future CJM
Redesign the same stages around the customer's goal, removing friction and adding proactivity. Keep the same columns so the As-Is and Future maps line up one-to-one — this makes the gap (the change you're committing to) obvious.
Stage
Future experience
Touchpoint
Emotion
Design move
Awareness
Proactive renewal heads-up 90 days out, with a usage summary
Output A Future journey map (the Target Journey Map, or TJM) — the agreed target experience, stage by stage. This is the specification for the operation.
Translate the Target Journey Map into BPMN
Step · derivation
Now the tool's core move: each element of the Future journey map maps mechanically to a specific BPMN 2.0 element. Nothing is invented — every stage, action, decision and pain point has a direct counterpart. This is the bridge from CX to OpEx.
Journey map stage
Awareness — proactive heads-up (T-90 days)
→
BPMN element
Timer start event (fires 90 days before contract end)
Journey map stage
Review — renewal readiness view
→
BPMN element
Service task: assemble usage + ROI · Data store (usage DB)
Journey map stage
Decision — renew / adjust / talk to CSM
→
BPMN element
Exclusive gateway (three outgoing paths)
Journey map stage
Pain point — deadline pressure / stall risk
→
BPMN element
Boundary timer event: nudge + escalate to CSM
Journey map stage
Action — e-signature in portal
→
BPMN element
User task assigned to the customer pool (e-sign)
Journey map stage
Post — instant confirmation
→
BPMN element
Send task + message end event (renewed)
Output A one-to-one derivation table — the audit trail that proves the process came from the customer's experience, not from internal convenience.
Assemble the executable BPMN diagram
Step · BPMN 2.0
Place each derived element on swimlanes drawn from your Target Operating Model (TOM) — who owns each step. The result is a runnable process where every lane traces back to a role, every gateway to a business rule, and every task to a system.
R01 · Renewal·Northwind Cloud
Target SLA · sign within 90 days
Output An executable BPMN 2.0 process — the operational expression of the redesigned experience, ready to hand to engineering, configure in a workflow engine, or use as the blueprint for the target operating model.
The point of direction 1: the customer's experience drives the design of the operation. You can trace every task, lane and rule in the process back to a stage on the journey map — so the operation is provably built around the customer, not around internal habit.
Use case 2 · Reverse
From process and feedback to a redesigned journey.
OpEx→CXExisting BPMN process + Voice of Customer → pain points → Future journey map
Sometimes you start inside-out: a process already exists and is running, and customers are telling you something is wrong. Here you read the process and the Voice of Customer (VoC) together, locate exactly where the operation is hurting the experience, and work back to a redesigned journey — which can then loop through direction 1 again.
Scenario
Northwind Cloud already runs an automated support-ticket process. It's efficient on paper — fast routing, tight SLAs — yet support satisfaction is falling. The process is optimised for throughput; the experience is suffering. We use VoC to find out why.
Start from the existing process
Step · As-Is BPMN
Read the live process exactly as it runs today. Note the automation, the routing logic, and the SLA gates — these are where operations meets the customer, and where friction usually hides.
S01 · Support ticket·As-Is
Optimised for throughput
Output A clear read of the As-Is process and its decision/SLA points — the candidate friction locations to test against customer feedback.
Gather the Voice of Customer
Step · VoC
Pull customer signal from every channel — surveys, support verbatims, interviews, reviews. Don't just count scores; read what customers actually say. The quotes tell you where in the process the experience breaks.
CSAT survey · verbatim
"The bot kept looping me. I just wanted a human."
Tier-1 ticket · CSAT 2/5
Interview · Elena
"It got closed in 4 hours, but my problem wasn't actually solved."
IT Ops Lead · enterprise account
Review site
"Fast to respond, slow to fix. Felt like a stopwatch, not support."
3★ · public review
VoC themes (coded from 140 invented verbatims): (1) bot deflection feels like a wall · (2) SLA-driven closures mask unresolved issues · (3) no follow-up after "closed."
Output Three coded VoC themes, each tied to a measurable signal — ready to pin onto the process.
Pin pain points onto the process
Step · diagnosis
Overlay the VoC themes directly onto the BPMN steps. This is the reverse of the derivation bridge: instead of journey → process, you go process step → customer pain. It pinpoints which operational decisions are creating the bad experience.
Process step
"Bot self-serve" branch (tier-1)
→
Customer pain
Theme 1 — deflection feels like a wall; no easy human escape hatch
Process step
"SLA 4h" boundary timer
→
Customer pain
Theme 2 — closing to beat the clock, not to solve the problem
Process step
"Resolve + close" → end event
→
Customer pain
Theme 3 — no confirmation the fix actually worked; no follow-up
Output A diagnosis that names the exact operational levers (a gateway, an SLA rule, an end event) hurting the experience — defensible because each is backed by a VoC theme.
Work back to a redesigned journey
Step · Future CJM
Translate each diagnosed pain into a journey design move. You're rebuilding the experience from the operational evidence — the customer-facing target that the next process redesign must deliver.
Stage
Pain today
Redesigned experience
Emotion shift
Contact
Bot loops, no escape
One-tap "talk to a human" always visible
Trapped → Heard
Handling
Closed to beat SLA
"Resolution confirmed by customer" gate, not just elapsed time
Rushed → Respected
Closure
No proof it's fixed
Confirm-fix step + 48h follow-up check
Uncertain → Confident
Output A redesigned Future journey map grounded in real operational evidence — the new Target Journey Map.
Close the loop
Step · CX → OpEx again
Feed that redesigned journey straight back into direction 1: derive the new BPMN process (a customer-confirmation gate replacing the time-only SLA close, a persistent human-escape path, a follow-up timer event). The two directions form a continuous improvement loop.
Output A revised, executable process — and a closed CX ↔ OpEx loop where experience and operations keep correcting each other.
The point of direction 2: an "efficient" process is not automatically a good experience. Reading the process and the Voice of Customer together shows you exactly where operational design is costing you customer trust — and gives you an evidence-backed mandate to redesign.
In short
One coin, two directions.
Forward · CX → OpEx
Start with the customer. Map As-Is, design the Future journey, then translate it into an executable BPMN process. The experience becomes the spec for the operation.
Reverse · OpEx → CX
Start with the running process and the Voice of Customer. Pin pain to steps, redesign the journey from the evidence, then re-derive the process. Operations reveals where the experience breaks.
Use direction 1 when you're designing something new or redesigning a known journey. Use direction 2 when something live is underperforming and you need to find out why. Run them in a loop and CX and OpEx keep each other honest.