A home insurance claim journey map: six columns, a colored emotion curve running underneath, pain points tagged in red, presented to the leadership group and approved. Every step reads in customer voice, because somebody did that pass before the review.
There is no column for the eleven days between "assessor visit booked" and "assessor visits." That gap is the part of the claim a customer would describe first if you asked them about it, and the map has a column for every form the insurer touches and none for the wait.
That is mapping process, not experience. A process map shows the work your organization performs, in the order it performs it. A journey map shows what the customer is doing, deciding, and waiting through, in the order they live it. When the second gets built on the first one's skeleton, you end up with an artifact that can be well researched, well facilitated, and beautifully rendered, and still only capable of confirming what the organization already believed.
How to tell whether you mapped your process or the customer's experience
You can check this against a map that already exists, on a wall or in a shared drive, in about ten minutes. The four symptoms below are structural, which is why they survive a language pass: every label can be worded flawlessly from the customer's side while the frame holding them stays organized around your workflow. Work through them against the claim map, or against yours.
- The boundaries match your involvementStarts at first contact, ends at case closed
- Column width follows internal effortDense where you work, empty where they wait
- Your handoffs appear as customer stepsRouting decisions no customer ever experienced
- Every channel on the map is one you ownNothing happens outside a system you control
Each of the four is checkable in a couple of minutes, and one hit is enough to make the other three worth running.
The map starts and ends where your involvement does
The first column on most journey maps is the customer's first contact with the organization. On the claim map it is "customer reports claim." The customer's journey started well before that: the storm, the call to a neighbor who claimed last year and spent four months on it, twenty minutes hunting for the policy number in a drawer, and the decision about whether the damage is even worth the excess and the renewal hit. All of that determines what mood they arrive in, and none of it is on the map.
The same thing happens at the far end. The map stops at "claim paid." The customer's experience runs on into the repair work, the builder's invoice that came in higher than the settlement, and the renewal quote four months later with the claim priced into it.
The check: find your first and last columns, then ask what the customer was doing the day before the first one and in the week after the last one. If nobody in the room can answer without guessing, the boundaries came from your process. This matters more than anything in the middle, because the moments with the most leverage in a journey tend to sit just outside the range an organization instruments, for the same reason they are missing from the map.
Column widths follow internal effort, not customer attention
Count the columns and mark each one as either work your organization performs or time the customer spends. On the claim map, five of the six are organizational activity. Document intake gets three columns because three teams touch it. The eleven-day wait gets none, because no system logged anything while it was happening.
Visual weight then does its own arguing. Anyone reading the map concludes the problem lives where the columns are dense, and the columns are dense where internal labor is dense. That is close to the inverse of where the customer's problem lives.
Allocating columns by customer attention instead sometimes means one column for a fortnight in which nothing happens and four columns for a ten-minute phone call that went badly. That looks wrong to a process owner and right to anyone who has made a claim.
Your handoffs became the customer's steps
Steps like "escalated to tier 2," "routed to underwriting," or "file passed to assessment" are internal transitions wearing step clothing. No customer has ever experienced a routing decision. What they experience at that moment is telling the whole story again to a second person who has not read the first person's notes.
Scan every step and ask whether the customer could tell you it happened. If the only evidence a step occurred is a status change in an internal system, it belongs to the process view.
The asymmetry is what makes this expensive. One internal handoff usually generates several distinct customer experiences: waiting, repeating themselves, and then getting an answer that contradicts the first one. Collapsing all of that into a tidy arrow is how the most complained-about stretch of a service ends up looking clean on the map.
Nothing on the map happens in a channel you don't own
Every touchpoint on the claim map has a login, a phone number, or a tracking pixel behind it. Absent: the trades forum thread about which insurers argue hardest over water damage, the message to a friend who works in construction, the builder standing in the kitchen saying he has seen this go badly before.
Those are not fringe events. In most journeys the decisions that set the outcome get made in conversations you never see, using information you did not supply.
The check is one question. Point at a step where the customer is getting information about you from someone who does not work for you. If no such step exists anywhere on the map, what you have is a record of your own channels.
Why it happens, and why renaming the stages doesn't fix it
On day one the only material in the room is internal. Process documentation, the CRM stage list, system logs, and the working knowledge of the people who own each part of the workflow. The people in the room are the process owners, because those are the people who can get a two-day workshop scheduled and get their teams released to attend it.
So the skeleton gets decided in the first thirty minutes from the only source available, and everything after that is poured into it. Interviews, verbatims, survey data, support transcripts: all of it fills cells, none of it questions columns. This is why a genuinely research-backed map can still be process-shaped. The evidence fills in the structure and makes it look settled, which makes it harder to challenge rather than easier.
The structure decision itself almost never gets reviewed. Teams review the content of a journey map constantly, arguing about whether a pain point is real, whether the emotion curve is too generous, whether the persona fits. Very few go back and ask where the columns came from, and by the time the map is finished the columns feel like a description of reality rather than a choice somebody made in the first half hour.
Relabeling is the fix most teams stop at. Turning "Lead Qualification" into "Figuring out what I need" is worth doing, and it changes how the map reads in a room. It does not move a single column. A process map with customer-voice labels is still organized around your workflow, and the language pass can make the underlying problem harder to spot, because the map now passes the one test everybody knows to run.
Smaply structures maps in stages, steps and lanes, so the customer waiting shows up as clearly as your work.
What the process-shaped map costs you
A map that mirrors the organization can only produce improvements the organization already knows how to imagine. It surfaces friction where teams already look, which is why the output of the workshop tends to be a prioritized list of things the process owners had on their roadmap anyway. The session feels productive and the results feel familiar, and those two facts have the same cause. The version that validates the current operating model is also the version most likely to get approved, so this is the shape of map that clears review and gets budget.
How to repair a map that's already process-shaped
You don't need to start over, and starting over is usually the wrong call politically. The evidence inside the cells is mostly fine. The frame around it is what's wrong, and a frame can be re-cut without discarding six weeks of research and a stakeholder sign-off. Do these in order: re-cutting the boundaries changes what the other four moves are operating on.
Only the first move requires talking to anyone new.
Re-cut the boundaries before touching anything else
Ask five customers, or five people from a team that talks to customers daily, two questions: what were you doing the day before our first column, and what happened in the week after our last one. Extend the map at both ends on the strength of the answers, before you edit anything in the middle. On most journeys the extension relocates the emotional low point out of the range the original map covered, which changes the priority order of everything downstream.
Give the waiting its own columns
Walk the map and find every gap where the customer is waiting on you. Each one becomes a column, labeled with what the customer is doing and thinking during it rather than with what you are processing. Expect the shape to change: wider in the stretches nobody wanted to look at, narrower where the internal detail used to be.
Convert your handoffs into what the customer experiences
For each internal transition on the map, replace it with the customer-side events it causes. One handoff often becomes two or three steps, and those steps are usually where the verbatims you already have turn out to be most quotable. If a handoff produces nothing the customer can perceive, take it off the journey map. It belongs in the process view, which has its own uses.
Fill the off-stage steps with evidence you already have
The material for the steps outside your channels is usually sitting somewhere in the building already. Sales call notes describing what people tried before they called. Support transcripts where customers explain the workaround they found on a forum. Churn interviews, onboarding questions, review sites. Mark each step you add as verified or assumed. A map that distinguishes the two is more useful in an argument than one presenting everything at the same confidence level, and it tells you what to go and research next.
Take the rebuilt map back to the people who approved the old one
Show both versions side by side rather than swapping one for the other. The comparison does the arguing, and it lands better than a critique of work they signed off on. Expect one objection in particular: the customer-shaped map looks less actionable, because its steps no longer map cleanly onto team ownership. That is the finding, not a flaw in the map. The steps that belong to nobody are the ones generating the complaints.
Where the process view belongs once the journey map is honest
Process maps are good at the questions journey maps handle badly, the ones about internal mechanics, capacity, and cost. Those need the inside-out view, and the customer's emotional state is noise when you are answering them. The problem was never the process map. It was one artifact being asked to do both jobs and losing the customer's half of it.
The split is cleanest when you look at the questions each artifact can actually answer:
- How long does this internal step take?
- Where is the bottleneck?
- Who hands off to whom?
- What does a case cost us to handle?
- Which team owns this activity?
- What is the customer trying to get done?
- Where do they wait, and for how long?
- What do they have to repeat?
- Who else are they asking about us?
- Where do they decide to give up?
The two views meet in a service blueprint, which is the mechanism behind the common advice to use both. A blueprint stacks them in a single frame, aligned column by column, with the customer's experience above the line of interaction and the frontstage and backstage work below it. Read a column top to bottom and you can see which internal step produces which customer moment, which is exactly the connection a separate process map and a separate journey map cannot make.
Sequence matters here. Fix the journey map first, then blueprint the two or three steps that turned out to matter. Blueprinting an entire journey before you know where the problem is reproduces the original mistake at higher cost, because you will blueprint the stretches your process documentation covers best. Customer journey mapping only changes what gets built when the map describes the customer's experience rather than a reflection of the org chart in customer voice.
The repaired claim map creates one specific argument in the next review, and it is worth knowing that it is coming. The eleven-day column now sits in the middle of the map with nothing underneath it, and the assessment team will say the delay is a supplier capacity problem outside their control, while the claims team will say it only looks that way because nobody owns the customer during it. Both are right. Neither of them could have said it in front of the old map.
Bring interviews, transcripts and support notes into Smaply and connect them to the steps they explain.
Frequently asked questions
What is the difference between a process map and a customer journey map?
A process map documents the activities your organization performs to deliver something, in the sequence the organization performs them. A customer journey map documents what the customer does, thinks, feels, and waits through, in the sequence they experience it. The same service produces two quite different pictures, and the journey map is the only one that includes the time the customer spends doing nothing while waiting on you.
Our stages are already written in customer language. Is our map fine?
Not necessarily. Rewriting stage labels the way a customer would say them is a real improvement, but it operates on the wording and leaves the structure untouched. Check the columns rather than the text: if their boundaries, widths, and transitions still track your internal workflow, you have a process map with better manners.
We used real customer research. Can our journey map still be process-shaped?
Yes, and this is the most common version of the problem. Research usually arrives after the structure has been agreed, so the interviews and verbatims get filed into columns that were derived from internal documentation. The evidence is genuine and the frame around it still came from your workflow.
Do we have to redo the map from scratch?
Almost never. The content inside the cells is usually sound, and the repair is a reframing job: extend the boundaries, add columns for the waiting, convert internal handoffs into the customer-side events they cause, and add the steps that happen outside your channels. Rebuilding from zero also costs you the stakeholder agreement you already have.
How do we map steps that happen outside our systems, where we have no data?
Use the qualitative evidence your organization already collects. Sales call notes, support transcripts, churn interviews, onboarding questions, and public reviews all contain descriptions of what customers did before and between their interactions with you. Add those steps and mark them as assumed until you have validated them, so the map shows its own confidence levels rather than presenting everything as equally certain.
