A journey map hierarchy is a set of journey maps arranged by altitude, where each map covers a defined slice of the customer experience, connects upward to a parent map, and connects downward to any child maps that detail its steps. It is structure, not storage.
Most teams arrive at the idea late. You have eleven maps, three of them overlap, one is a forty-column monster nobody opens, and when a new colleague asks which map shows onboarding, the honest answer takes two minutes to give. Assigning altitudes is what makes that question answerable in a sentence, and it is the piece of managing multiple customer journeys that the rest of the practice sits on.
What a journey map hierarchy is
Three levels cover most organizations. An L1 lifecycle journey follows the whole relationship, from the moment someone recognizes a need through renewal or exit. An L2 journey covers one coherent experience inside a lifecycle stage: opening an account, resolving a billing dispute, returning a product. An L3 micro-journey covers a single interaction or task sequence, such as verifying identity, and spans minutes rather than weeks.
What makes this a hierarchy rather than three unrelated maps is the join. A step in the parent becomes the entire scope of the child, and the parent's step name becomes the child's title. If a map you are calling a child does not correspond to exactly one step in its parent, it is not a child map. You have two maps at similar altitudes with a line drawn between them, which is the state most portfolios are already in.
Each level also answers to a different reader. L1 supports portfolio and investment conversations, so it stays coarse on purpose. L2 belongs to the teams who own an experience and carries the pain points they are working from. L3 belongs to whoever is designing a specific form, script, or handoff, and it is the only level where interaction detail is worth maintaining.
Hierarchy is also not filing. Folders, tags, and a searchable journey map repository answer where a map lives. Hierarchy answers how one map relates to another and which one you should have open. Teams can have immaculate filing and no hierarchy at all, and it shows the first time two people present conflicting versions of the same stage.
One warning about numbering. Level naming is not standardized anywhere: some frameworks add a tier above the lifecycle map for the wider ecosystem of partners and internal systems, and others number from the detail end upward, so two documents can both say level 3 and mean opposite things. Pick a scheme, write the definitions where people will find them, and put the level in every map title.
Deciding where one level ends and the next begins
The hard part of a hierarchy is deciding, for one specific stretch of experience, whether it stays a step inside its parent or becomes a map in its own right. Get that wrong in one direction and the lifecycle map fills with screen-level detail until nobody senior will look at it. Get it wrong in the other and you have thirty maps whose relationship to each other is a matter of opinion.
The promotion test
A step gets promoted into its own map when it stops working as a step. Three checks, and one yes is enough.
Several actions are hiding inside it.
The customer would describe the step as several distinct things they did, in order. "Verify your identity" often turns out to be find the document, photograph it, wait, get rejected for glare, try again. Five actions, three of which can fail, sitting under one label.
It has its own emotional arc.
There is a drop and a recovery inside the step that the parent flattens into one value. When a single step takes a customer from confident to stuck to relieved, any number on the parent map is an average of three different experiences.
It sits with a different owner.
Improving it is somebody else's project, with its own backlog and definition of done. Hierarchy that follows ownership boundaries tends to get maintained. Hierarchy that cuts across them gets abandoned, because no single person can approve a change to it.
If all three come back no, the stretch stays a step, and the detail belongs in the step's card content or the evidence attached to it. A separate map means a separate review cycle and one more thing to keep true.
One counter-check keeps the test from generating maps forever: if nobody can name a decision the child map would change, do not make it. A map created for completeness is maintenance cost with no reader.
Use step counts as a diagnostic
Counts are the fastest way to spot a map at the wrong altitude, and they take ten seconds to check. An L1 that runs past roughly eight to twelve stages has stopped being readable at portfolio altitude. An L2 is usually legible between ten and twenty steps, and an L3 tends to sit between five and fifteen.
A count outside those bands is worth investigating on its own. Sometimes the map is at the wrong level, but more often one stage inside it is carrying a promotion candidate, and splitting that stage out brings the parent back into range. Watch the arithmetic trap on the way out: cutting a forty-step map into four ten-step maps produces four maps at the same altitude, and nothing has been layered unless there is a parent above them whose individual steps those four correspond to.
Where personas fit, and why they are not a level
Hierarchy follows the shape of the experience, and the persona is an attribute of each map rather than a rung on the ladder. Adding personas as a level multiplies the portfolio without adding structure, which is how teams end up with sixty maps and no clearer picture than they had with fifteen. This is the same discipline that governs how personas in journey mapping get used, as a point of view on a map. So run one hierarchy per distinct experience shape, and create persona variants only where the steps themselves differ.
The honest exception is structural. A self-serve buyer who never speaks to anyone and a tendered enterprise buyer with a six-month procurement move through genuinely different lifecycles, and they need separate L1 backbones rather than variants of one.
When a fourth level is justified
A fourth level is justified when a real reader exists for it and the promotion test passes twice in a row from the same starting point, most often in organizations mapping across multiple business units or needing a view above the lifecycle covering partners and channels. Weigh the cost first: every level adds review cycles and one more opportunity for two maps to disagree about the same step. Four levels maintained by a team that could only sustain three is worse than three, because the bottom level stops being true and people stop trusting the whole structure.
Sizing, naming, and titling so the hierarchy stays legible
Most people meet a journey map in a list, not on a canvas. That makes the title the navigation, and it is the reason a hierarchy that looks clean in a diagram can still be unusable in practice.
A title pattern that works has three parts: the level, the persona or segment where it matters, and the scope in the customer's language. "L2 - New business customer - Opening an account" tells a reader everything they need before they click. Keep the scope phrasing customer-side, because "Account origination workflow" is the title that gets a map opened by the wrong person and ignored by the right one.
Use the same words in the parent's step and the child's title. When the step is called "Verify identity" and the child map is called "KYC checks", the join survives exactly until someone renames one of them.
Two more signals belong in the list view, because their absence lets stale maps get read as current: an owner and a last-reviewed date on every map, and a separate state for maps that are archived rather than active. Those are the same fields a journey map governance practice runs on, and without them a hierarchy turns into a list where the map from 2023 and the map from last month look identical.
Smaply links maps into a Journey Hierarchy, so every step with detail behind it opens the map that has it.
Retrofitting a hierarchy onto the maps you already have
Nobody builds a hierarchy on an empty account. The realistic starting point is a pile of maps built independently by different teams in different formats, and the sequence below sorts them in one working session rather than a quarter-long project. The example running through it is an insurer with 23 maps spread across four teams: marketing, digital, claims, and a service design group that had run workshops for all three.
Inventory before you classify
Put every map in one row with seven fields: title, owner, persona, first step, last step, step count, and last update date. Do the whole inventory before making a single classification decision, because altitude judgments made map by map drift as you go.
The two fields that do the real work are the first and last step, because scope overlap is invisible in titles and obvious in endpoints. Two maps called "Onboarding" and "Getting started" look like different things until you notice they both start at contract signature and end at first successful login.
Assign an altitude to every map, including the awkward ones
Most maps land at L2 without much argument, because the workshop-shaped map covering one experience is the default artifact almost everyone produces. A handful are clearly L3, and the L1 usually does not exist. Three kinds of awkward case are worth deciding in advance rather than debating each time:
- Maps that start at an internal trigger rather than a customer intention. "Application received" is not a customer step, and these need re-scoping before they can be placed.
- Maps covering two lifecycle stages at once. These get split, and the split point is almost always a handoff between two internal owners.
- Maps that are really process documentation with an emotion row added. These are not journey maps at any altitude, and calling them one is what makes a hierarchy feel arbitrary.
At the insurer, that classification took a single working session, and it left four teams looking at the same list for the first time:
| Maps | What the audit found | Action taken |
|---|---|---|
| 14 | Sat comfortably at L2, one experience each | Kept, parent stage assigned to each |
| 3 | Genuinely L3, all of them in claims | Kept, attached to the claims journey steps they detail |
| 4 | Duplicates of the same onboarding stretch, owned by different teams | Merged to one, the other three archived with their evidence carried across |
| 2 | Mapped internal handoffs rather than customer experience | Re-scoped as service blueprints, removed from the hierarchy |
| 0 | No L1 lifecycle map existed anywhere in the business | One built afterwards, derived from the surviving L2 maps |
The four duplicates were the expensive finding. Each team had been maintaining its own version of onboarding and briefing delivery work from it, which is how three roadmaps end up disagreeing about the same two weeks of a customer's life.
Build the missing lifecycle backbone last
The L1 map gets built after the audit, and it stays deliberately thin. Eight to twelve stages, derived from the L2 maps you already have plus the stages nobody has mapped yet, with no lanes beyond what a leadership audience will read.
Building it is where the audit produces genuinely new information. At the insurer, the backbone showed four maps stacked on onboarding and nothing at all on renewal, an imbalance that survives for years when maps are only ever looked at one at a time. That gap list is a better input to journey prioritization than a scoring workshop, because it says where you have no visibility rather than where you have competing opinions.
Resolve duplicates and orphans
For two maps covering the same stretch, keep the one with traceable evidence behind it and carry the other's evidence and open pain points across before archiving it. Archive rather than delete, so the merge decision stays checkable by whoever disagrees with it in six months.
For a map whose scope corresponds to no step in any parent, two options are both fine: create the parent above it, or reclassify it as something other than a journey map. The insurer's two unplaceable maps became service blueprints of internal handoffs, which is what they had been all along.
How to tell a hierarchy is wrong
A broken hierarchy announces itself in review meetings long before anyone diagnoses it. The symptoms below are all observable in the artifacts themselves, so you can check for them in an afternoon without interviewing anybody.
The second one is worth expanding. When two teams have mapped the same stretch at different altitudes, the instinct is to pick a winner, and that reliably produces a political argument. The better move is to ask which of the two is the parent, because usually one is a legitimate child of the other with a bad title, and subordinating it costs nobody their work.
What the hierarchy pays for
Filing is the smallest benefit here. A hierarchy repays the maintenance it costs through three things that are hard to do with a flat set of maps.
Traceability in both directions.
A failure found in an L3 interaction can be located in the L2 journey and the L1 stage it damages, which turns a usability finding into an argument leadership can act on. Read the other way, a falling lifecycle-stage metric points at the journeys underneath it that could explain the drop.
Comparison that holds up.
Prioritizing across maps only works when the maps sit at comparable altitudes. A micro-journey's pain points and a lifecycle stage's pain points are not the same size of problem, and ranking them in one list produces a backlog where the loudest map wins.
Ownership that can act, and a clear rule about rollup.
Levels give you somewhere to attach owners with real authority: L2 maps to the teams that run those experiences, the L1 to whoever is accountable for the relationship. Step-level numbers inform the journey above them without averaging into it, and the lifecycle view carries relationship-level measures plus a coverage picture.
In Smaply, Journey Hierarchy is the structure that connects maps into navigable levels, and a Linked Journey card is the card type you place on a step to link out to the map covering that step in detail. The card is the mechanism and the hierarchy is what the cards add up to, which matters when auditing a portfolio: you can see which steps have detail behind them and which are still claims nobody has checked. Structure of this kind is the part of customer journey management that makes the rest of it work, because prioritization, governance, and measurement all assume you know which map you mean.
Smaply keeps a portfolio navigable: parent and child maps, owners, review dates, and one place to find them.
Frequently asked questions
How many levels should a journey hierarchy have?
Three covers most organizations: lifecycle, journey, and micro-journey. The condition for adding a fourth is a named reader who needs it and a stretch of experience where the promotion test passes twice from the same starting point.
How many maps should sit at each level?
One L1 per distinct lifecycle, roughly ten to thirty L2 journeys covering your core experiences, and L3 maps created for specific analysis rather than for coverage. The L3 count should go up and down over time. If it only ever goes up, maps are being made for completeness.
What is the difference between a journey map hierarchy and a journey map repository?
A hierarchy is the relationship between maps: which one is the parent, which steps have detail beneath them. A repository is where maps live and how people find them. Neither substitutes for the other.
Can one map have more than one parent?
Shared interactions like identity verification or payment do appear inside several journeys. Give the map one home in the hierarchy and reference it from the others, rather than maintaining copies that will drift apart within two review cycles.
Who should own the hierarchy itself?
One named custodian who approves altitude assignments and signs off on new maps, with ownership of individual maps distributed to the teams that run those experiences. Splitting the structural decision from the content decisions keeps the levels consistent while the maps stay close to the work.
The first classification pass
Start by assigning an altitude to every map you already have, then look at which lifecycle stages have three maps and which have none. That single pass usually reorders whatever you thought your next mapping project should be.
A portfolio with no assigned altitudes has not avoided the decision. It has made it one map at a time, at whatever zoom the team that built each map happened to need that week, and the bill arrives as four maps of the onboarding stage that disagree with each other and a lifecycle view nobody has ever seen.
