Structuring Customer Journey Hierarchy Levels (L0-L3)
This skill teaches you how to decompose the full customer experience into four nested hierarchy levels, from a single macro lifecycle (L0) down to granular touchpoint interactions (L3), so your organization can manage journeys at every scale without losing strategic context.
Start by defining your L0 lifecycle as the single end-to-end macro journey covering the full customer relationship. Break it into 4-7 L1 stage journeys like Awareness, Onboarding, or Renewal. Decompose each L1 into L2 scenario journeys representing distinct paths or use cases within a stage. Finally, drill L2s into L3 micro-journeys capturing specific interaction sequences at individual touchpoints. Each level inherits context from the one above.
Outcome: You produce a complete, documented hierarchy tree where every journey in your portfolio has a clear level designation (L0 through L3), explicit parent-child relationships, and defined boundaries, enabling your organization to zoom in and out across the customer experience without duplicating work or losing strategic alignment.
Prerequisites
- Familiarity with basic customer journey mapping concepts (stages, touchpoints, personas)
- Access to existing journey maps, customer research, or service blueprints for reference
- Understanding of your organization's customer lifecycle stages
- Stakeholder alignment on what constitutes a 'journey' versus a 'process' or 'workflow'
Overview
Customer journey hierarchy levels solve one of the most persistent problems in experience management: the mismatch between the strategic view of the customer lifecycle and the operational reality of individual interactions. When teams map journeys without a hierarchy, they end up with dozens of disconnected maps at wildly different levels of detail. A product team maps a micro-interaction with a checkout flow while a marketing team maps the entire pre-purchase experience, and neither artifact connects to the other. The result is redundant work, contradictory priorities, and no shared language for discussing where the customer experience breaks down. Structuring journeys into four nested levels, L0 through L3, creates a common architecture that every team can navigate.
This skill sits at the foundation of the Ecosystem Journey Framework. Before you can prioritize journeys, build a portfolio inventory, or identify cross-journey patterns, you need the hierarchy itself. Think of it as the taxonomy that makes everything else possible. Without it, journey management becomes journey chaos. The hierarchy gives you a shared coordinate system: when someone says "the onboarding journey," everyone knows whether they mean the L1 stage journey covering the entire onboarding phase, the L2 scenario journey for enterprise customers specifically, or the L3 micro-journey for the first-login tutorial.
The concrete artifact you produce is a hierarchy tree document. This is typically a visual diagram or structured table showing every journey in your portfolio organized by level, with explicit parent-child relationships, named owners, and boundary definitions. Each node in the tree includes a journey name, its level designation, the parent journey it rolls up to, the entry and exit conditions that define its scope, and the primary persona it serves. A well-built hierarchy for a mid-size SaaS company might have 1 L0, 5-7 L1s, 15-25 L2s, and 40-80 L3s. The exact numbers vary, but the ratio matters: each parent should decompose into 3-7 children. Fewer than three children suggests you have not actually added meaningful resolution. More than seven suggests you need an intermediate grouping.
Success looks like this: any team in the organization can locate their work within the hierarchy, zoom out to understand strategic context, zoom in to find operational detail, and identify adjacent journeys that share touchpoints or handoff moments. The hierarchy becomes a living navigation system, not a one-time deliverable.
How It Works
The hierarchy works because customer experiences are inherently fractal. The same structural pattern, a sequence of interactions that moves a person from one state to another, repeats at every scale. The full customer lifecycle is a journey. So is a single stage within it. So is a specific scenario within that stage. So is a discrete interaction within that scenario. The L0 through L3 framework simply names these natural levels of resolution and gives teams a consistent way to navigate between them.
At L0, you define the macro lifecycle. This is singular. Every organization has exactly one L0, covering the entire relationship from first awareness through advocacy, churning, or win-back. The L0 is not a map you do detailed design work on. It is the strategic frame that ensures all other journeys are accounted for and connected. Think of it as the table of contents for your entire customer experience.
L1 journeys represent lifecycle stages. These are the major phases a customer moves through: Awareness, Consideration, Purchase, Onboarding, Active Use, Renewal, and so on. The naming should match your organization's actual language, not a textbook framework. If your company calls the post-purchase phase "activation" rather than "onboarding," use "activation." L1 journeys answer the question: what are the distinct chapters of the customer relationship? Each L1 should have a clear entry trigger (what causes a customer to enter this stage) and exit condition (what signals they have moved to the next stage or dropped out).
L2 journeys are scenario journeys within a stage. This is where personas, use cases, and context start to differentiate the experience. Within an L1 like "Onboarding," you might have L2 scenarios for self-serve onboarding, guided enterprise onboarding, migration from a competitor, and team rollout. Each L2 shares the same stage but follows a meaningfully different path. The test for whether something is a distinct L2 is whether the touchpoints, actors, or sequence differ enough that a single map would be confusing. If two scenarios share 80% of their touchpoints and the differences are minor, they belong in the same L2 with conditional branches, not separate L2s.
L3 journeys are micro-journeys, the most granular level in the hierarchy. These map specific interaction sequences at individual touchpoints or clusters of closely related touchpoints. Setting up a payment method, completing a product tutorial, contacting support about a billing issue: these are L3s. They are where operational teams do their most detailed design and optimization work. L3 journeys connect directly to UI flows, service scripts, and automation logic.
The hierarchy works within the Ecosystem Journey Framework because it creates a shared coordinate system that other framework activities depend on. Prioritization requires knowing what level you are prioritizing at. Portfolio inventory requires consistent level classification. Cross-journey insights require the hierarchy to identify where journeys at the same level share touchpoints or handoff moments. The hierarchy is not a decoration layered on top of journey maps. It is the structural foundation that transforms a collection of maps into a managed portfolio.
Step-by-Step
Step 1: Audit Existing Journey Artifacts
Gather every journey map, service blueprint, experience map, and customer lifecycle diagram that exists across your organization. This includes formal deliverables from CX teams and informal sketches on whiteboards or in slide decks. ), and the date it was last updated. You are not evaluating quality at this point.
You are establishing what exists so you can see the natural groupings and gaps. Expect to find significant overlap, with multiple teams having mapped versions of the same journey at different levels of detail, and significant gaps, with entire lifecycle stages unmapped.
Tip: Send a short survey to team leads across product, marketing, sales, support, and success asking: 'Do you have any journey maps, customer flow diagrams, or experience maps? Share links or screenshots.' You will almost always discover artifacts that the CX team did not know existed.
Step 2: Define Your Single L0 Lifecycle Journey
Write a one-paragraph description of the entire customer lifecycle for your organization. ' Define the entry point (typically first brand awareness or first touchpoint) and the exit point (typically churn, lapse, or ongoing advocacy). Do not try to map detailed touchpoints at L0. The L0 is a conceptual frame, not a detailed map.
Its purpose is to establish the full scope of your hierarchy and ensure nothing is left out. Document the L0 in a single row at the top of your hierarchy tree with the fields: journey name, level (L0), entry condition, exit condition, and a brief scope statement.
Tip: Resist the urge to create multiple L0 journeys for different customer segments. You always have one L0. Segment differentiation happens at L2. If you feel you need multiple L0s, you are likely confusing personas with journeys.
Step 3: Identify and Name L1 Stage Journeys
Decompose the L0 into 4-7 sequential or overlapping stage journeys. Review your existing artifacts, your sales funnel stages, and your customer success milestones to identify natural phase boundaries. For each candidate L1, write a clear entry trigger (what event or condition causes a customer to enter this stage) and exit condition (what signals transition to the next stage or dropout). Name each L1 using language your organization already uses rather than generic textbook terms.
Validate the set by asking: if a customer moves through every L1 in sequence, does that cover the entire L0 lifecycle? If there are gaps, add missing stages. If stages overlap significantly, consider merging them. Document each L1 as a child of L0 in your hierarchy tree.
Tip: Common L1 stages for B2B SaaS: Discovery, Evaluation, Purchase, Onboarding, Adoption, Expansion, Renewal. For B2C e-commerce: Awareness, Browsing, Purchase, Fulfillment, Use, Repurchase. Use these as starting points but customize to match your actual business language and customer behavior.
Step 4: Decompose Each L1 into L2 Scenario Journeys
For each L1, identify the meaningfully different paths a customer can take through that stage. These differences typically come from persona type (enterprise vs. SMB), channel (self-serve vs. sales-assisted), use case (new purchase vs.
migration), or context (first-time vs. returning). For each candidate L2, apply the differentiation test: do the touchpoints, sequence, or actors differ enough that a single journey map would be confusing or misleading? If yes, it is a distinct L2.
If the differences are minor, it is a conditional branch within an existing L2, not a separate one. Each L1 should produce 2-5 L2 children. Write clear boundary definitions for each L2 specifying the persona, context, entry condition, and exit condition. Document each L2 as a child of its parent L1.
Tip: If you end up with more than 5 L2s under a single L1, you are probably splitting too finely. Look for L2s that could be merged with conditional logic. Conversely, if you have only one L2 under an L1, you either have a very simple stage or you have not yet identified the meaningful variations.
Step 5: Define L3 Micro-Journeys Within Each L2
For each L2, identify the specific interaction sequences that a customer goes through. These are the most granular unit in your hierarchy. An L3 typically corresponds to a single task or goal from the customer's perspective: completing account setup, submitting a support ticket, reviewing a proposal, configuring a feature. Each L2 should decompose into 3-7 L3 micro-journeys.
For each L3, document: the specific touchpoint or touchpoint cluster involved, the customer's goal within this interaction, the start and end points, and the team or system responsible for delivering the experience. L3s are where you connect the journey hierarchy to operational systems, UI flows, and service processes.
Tip: Not every L3 needs to be mapped in detail right away. Identify and name all L3s for completeness, but only build detailed maps for L3s that are high-priority based on customer pain, business impact, or optimization opportunity. This prevents the hierarchy from becoming a multi-month project before anyone gets value from it.
Step 6: Validate Hierarchy Completeness and Consistency
Review the full hierarchy tree from L0 to L3 and run three validation checks. First, the completeness check: trace a customer from the L0 entry point through each L1, L2, and L3 to the L0 exit point. Are there any moments in the experience that are not covered? If a customer goes through an interaction that does not fit any L3, you have a gap.
Second, the mutual exclusivity check: at each level, do the sibling journeys overlap? An L2 scenario should belong under exactly one L1 parent. If you find an L2 that could fit under two L1s, you likely need to refine your L1 boundary definitions. Third, the ratio check: does each parent have 3-7 children?
Fewer than 3 children suggests the parent is too narrow. More than 7 suggests you need an intermediate grouping or you are splitting too finely.
Tip: Walk through the hierarchy with a specific customer story, ideally from a real support case or sales deal. Narrate the customer's journey step by step and point to where each moment lives in the hierarchy. If you cannot locate a moment, the hierarchy has a gap. If a moment fits in two places, you have an overlap to resolve.
Step 7: Assign Ownership and Document Boundaries
For each journey at L1 and L2, assign an owner. This is the person or team accountable for the quality of the experience within that journey's scope. Ownership should follow your organizational structure: marketing might own L1 Awareness and Consideration, product might own L1 Onboarding and Adoption, and customer success might own L1 Renewal and Expansion. For each journey, document explicit boundary definitions in a standardized format: journey name, level, parent journey, owner, entry condition, exit condition, key touchpoints, and primary persona.
These boundary definitions prevent scope creep and ownership ambiguity. They answer the question: where does this journey start and stop, and who is responsible for what happens within it?
Tip: Ownership disputes almost always happen at L1 boundaries, the handoff moments between stages like Evaluation to Purchase or Onboarding to Active Use. Explicitly document these handoff points and assign joint accountability for the transition itself. One pattern that works: the outgoing team owns the handoff trigger, the incoming team owns the receiving experience.
Step 8: Publish and Socialize the Hierarchy
Create two versions of your hierarchy for distribution. First, a visual diagram showing the tree structure from L0 through L3, with journey names and level designations visible at a glance. This can be a simple indented tree, a diagram in a tool like Miro or FigJam, or a structured table in a wiki. Second, a detailed reference document with full boundary definitions, ownership assignments, and links to any existing detailed journey maps at each node.
Share the visual version broadly across the organization in a format where people encounter it naturally, such as a Confluence page, a Notion database, or a shared drive folder that existing journey work links to. Run a 30-minute walkthrough session with journey owners to align on the hierarchy, clarify boundaries, and identify the first L2 or L3 journeys to map in detail.
Tip: Put the hierarchy tree in a living, editable format, not a static PDF. The hierarchy will evolve as you learn more about your customers and as your product changes. A Notion database or Airtable base works well because you can filter by level, owner, or status while maintaining the tree relationships.
Examples
Example: B2B SaaS Company with Sales-Led and Self-Serve Motions
A project management SaaS company serves both SMB customers (self-serve, $20/month) and enterprise customers (sales-assisted, $50K+ annually). They have 12 existing journey maps created by different teams over three years, with no consistent structure or level classification. The CX team has a mandate to build a unified journey management practice in Q1.
The team starts by auditing all 12 existing maps and classifying them by approximate scope. They find 2 maps covering broad lifecycle views, 4 covering onboarding variations, 3 covering support interactions, and 3 covering renewal and expansion. ' They decompose L0 into 6 L1 stages: Discovery, Evaluation, Purchase, Onboarding, Active Use, and Renewal. Each L1 gets an entry trigger and exit condition.
' They then decompose each L1 into L2 scenarios. Onboarding gets 3 L2s: Self-Serve Onboarding (SMB), Guided Onboarding (Enterprise), and Migration from Competitor. Renewal gets 2 L2s: Auto-Renewal (SMB) and Negotiated Renewal (Enterprise). The total hierarchy at L2 has 18 scenario journeys.
They decompose only the Enterprise Onboarding L2 into L3s for the first iteration, identifying 5 micro-journeys: kickoff meeting, data migration, team provisioning, admin training, and success milestone review. The hierarchy tree is published in Notion with links to the 12 existing maps placed at their correct nodes. Within two weeks, the product and success teams are using L-level language in sprint planning.
Example: D2C E-Commerce Brand with Physical and Digital Products
A consumer skincare brand sells through their website, Amazon, and 200 retail partners. They have strong acquisition data but limited visibility into post-purchase experience. The brand team has basic journey maps for the website purchase flow but nothing covering retail or repeat purchase behaviors. They want a hierarchy that covers all channels.
' They identify 5 L1 stages: Awareness, Consideration, First Purchase, Product Experience, and Repurchase. They resist the urge to create separate L0s for online and retail customers, recognizing that many customers interact across both channels. At L2, they decompose based on channel and context. First Purchase gets 4 L2 scenarios: Website Direct Purchase, Amazon Purchase, Retail Discovery Purchase, and Subscription Enrollment.
Product Experience gets 3 L2s: First-Time Use, Routine Use, and Issue Resolution. The team then drills Subscription Enrollment into L3s because it is a high-priority growth initiative: browsing subscription options, selecting a plan, entering payment details, and confirming first shipment. Each L3 connects to specific website UI flows that the product team can directly optimize. The completed hierarchy reveals a major gap: there is no journey coverage for the retail channel after purchase.
The brand has no visibility into how retail customers experience the product or what drives them to repurchase. This gap becomes a Q2 research priority.
Example: Healthcare Platform Connecting Patients, Providers, and Payers
A digital health platform serves three distinct user types: patients booking and managing care, providers delivering care through the platform, and insurance payers processing claims. Each user type has its own journey, but the journeys interconnect at shared touchpoints like appointment scheduling and billing. The team needs a hierarchy that accommodates multiple user types without creating three separate, disconnected frameworks.
The team defines one L0 for each user type that interacts with the platform: Patient Lifecycle, Provider Lifecycle, and Payer Lifecycle. They debate whether this violates the single-L0 rule, but conclude that these are genuinely separate relationships with the platform, not segments within one relationship. The Patient L0 gets 6 L1 stages: Symptom Awareness, Provider Search, Appointment Booking, Care Delivery, Follow-Up, and Ongoing Health Management. At L2, Appointment Booking decomposes into: First Visit Booking, Follow-Up Booking, Specialist Referral Booking, and Urgent Care Booking.
At L3, First Visit Booking breaks into: searching available providers, comparing provider profiles, selecting a time slot, entering insurance information, and receiving confirmation. ' This cross-hierarchy linkage is documented as a shared touchpoint annotation in the hierarchy tree. The hierarchy enables the team to assign clear ownership per user type while identifying the 8 shared touchpoints where cross-team coordination is essential.
Example: Small Startup with Limited Resources
A 12-person fintech startup with a single product (a budgeting app) has no existing journey maps. The product manager wants to establish journey thinking but cannot justify weeks of workshop time. The team needs a lightweight hierarchy they can build in a single afternoon and evolve over time.
The product manager blocks a 3-hour session with the head of growth, the support lead, and one designer. They define L0 as 'User Lifecycle Journey,' from first app store discovery to account deletion or 12 months of inactivity. They identify 4 L1 stages based on their analytics funnel: Discovery (app store or referral to download), Setup (download to completing profile and linking a bank account), Active Budgeting (first budget created to ongoing use), and Lapsed/Re-engagement (30 days inactive to return or churn). They decompose only the Setup L1 into L2s because it has the highest drop-off: Organic Setup (user finds app and self-serves), Referral Setup (user invited by friend, different onboarding flow), and Switch from Competitor (user migrating data).
They defer L3 decomposition entirely, noting that they will add L3s under whichever L2 they decide to optimize first based on drop-off data. The entire hierarchy fits on a single Miro board with 12 nodes. It takes 2 hours to create and 30 minutes to document. The team immediately uses it to structure their next sprint planning conversation, identifying that Referral Setup has a 60% drop-off at bank linking, which becomes their first L3 to decompose and map in detail.
Best Practices
Use your organization's existing language for stage names rather than adopting a generic textbook lifecycle. If your sales team calls the evaluation phase 'discovery' and your marketing team calls it 'consideration,' pick one and standardize. Forcing unfamiliar terminology creates resistance and reduces adoption. The hierarchy only works if people actually use it, and they will not use vocabulary that feels foreign.
Define entry and exit conditions for every journey at every level, not just L1s. Without explicit boundaries, journeys expand to cover adjacent territory and teams lose clarity about what is in scope. An L3 micro-journey for 'submitting a support ticket' should have a clear start (customer opens support channel) and end (ticket confirmed and assigned), not bleed into the resolution journey that follows.
Maintain the 3-7 children ratio at every level of the hierarchy. This ratio is not arbitrary. Fewer than 3 children means you have not added meaningful resolution by going one level deeper, which makes the hierarchy deeper than it needs to be. More than 7 children means the parent is too broad and the children will be difficult to compare, prioritize, or assign coherently.
If you consistently exceed 7, introduce a sub-grouping.
Build the hierarchy top-down but validate it bottom-up. Start with L0 and decompose downward, then take real customer stories and trace them upward through the hierarchy to find gaps and overlaps. Top-down ensures strategic completeness. Bottom-up ensures operational accuracy. Neither approach alone is sufficient.
Do not try to achieve perfect coverage on the first pass. Define all L0, L1, and L2 journeys in your initial hierarchy, but only decompose into L3 for the 2-3 highest-priority L2s. You can progressively elaborate the hierarchy as teams begin working at the L3 level. Attempting to define every L3 upfront leads to analysis paralysis and delays the point where the hierarchy starts delivering value.
Review and update the hierarchy quarterly, not just when someone notices a problem. Customer journeys shift as products evolve, channels change, and market conditions move. A hierarchy that was accurate six months ago may have gaps or stale labels today. Tie the review to an existing cadence like quarterly business reviews so it does not require its own meeting overhead.
Link every detailed journey map back to its node in the hierarchy tree. When a team creates or updates a map for an L2 or L3 journey, the hierarchy entry for that journey should link directly to the map. This transforms the hierarchy from a classification exercise into a living navigation system. Without links, the hierarchy becomes an orphaned taxonomy that nobody references.
Keep L0 and L1 stable. These levels should change only when the fundamental business model or customer lifecycle shifts. L2 and L3 levels evolve more frequently as you add new products, segments, or channels. If you find yourself restructuring L1s regularly, your L1 definitions are probably too narrow or too tied to current product features rather than customer lifecycle phases.
Common Mistakes
Creating multiple L0 journeys for different customer segments or product lines
Correction
The L0 is always singular. It covers the entire relationship between your organization and your customers. When teams create separate L0s for 'enterprise customers' and 'SMB customers,' they lose the ability to see the full ecosystem and identify shared touchpoints. Segment differentiation belongs at L2 where scenario journeys capture different paths through the same lifecycle stage.
If your business has fundamentally separate products with zero customer overlap, you may have separate hierarchies, but each still has a single L0. The signal that you have made this mistake is multiple hierarchy trees with no connection point.
Defining L1 stages based on internal department structure rather than customer experience
Correction
L1 stages should reflect what the customer is trying to accomplish, not how your org chart divides responsibility. When teams name L1s after departments ('Marketing Journey,' 'Sales Journey,' 'Support Journey'), they create silos rather than breaking them. Customers do not experience your departments. They experience stages like evaluating options, getting started, and solving problems.
The signal is L1 names that match org chart boxes rather than customer verbs or states. Test by asking: would a customer recognize this stage name as something they went through?
Splitting L2 scenarios too finely, creating dozens of nearly identical journey variants
Correction
This happens when teams create a separate L2 for every minor variation in the customer experience, such as separate L2s for 'onboarding via mobile,' 'onboarding via desktop,' and 'onboarding via tablet.' The differentiation test exists to prevent this: if two scenarios share more than 80% of their touchpoints and the differences are minor variations rather than fundamentally different paths, they belong in the same L2 with conditional branches noted. The signal is more than 5 L2s under a single L1, many of which look almost identical when you compare their touchpoint sequences. Merge similar scenarios and use annotation to capture the variations.
Skipping boundary definitions and relying on journey names alone to communicate scope
Correction
A journey named 'Enterprise Onboarding' means different things to different teams without explicit entry and exit conditions. The implementation team might think it starts at contract signature and ends at go-live. The sales team might think it starts at deal close and ends at first value delivery. Without documented boundaries, teams unknowingly work on overlapping or disconnected scopes.
The signal is recurring confusion about which team owns specific customer moments, or discovering that two teams have mapped the same touchpoint under different journey names. Write explicit entry triggers and exit conditions for every journey node.
Building the entire hierarchy to L3 before getting any organizational adoption
Correction
Teams sometimes spend months perfecting a comprehensive hierarchy in isolation, only to find that nobody uses it because they were not involved in creating it. The hierarchy is only valuable when teams adopt it as their shared coordinate system. Build L0 through L2 collaboratively with journey owners in a single workshop, publish it, start using it to structure conversations and decisions, and then progressively elaborate L3s only for journeys that are actively being optimized. The signal is a beautifully detailed hierarchy document that no one references in actual project work.
Treating the hierarchy as a static deliverable rather than a living navigation system
Correction
Some teams create the hierarchy once, circulate it in a PDF, and never update it. Within a quarter, new products, channels, or customer segments make the hierarchy inaccurate. When teams encounter journeys that do not fit, they work around the hierarchy rather than updating it, and the artifact loses credibility. The signal is team members saying 'the hierarchy doesn't reflect what we actually do.' Keep the hierarchy in a collaborative, editable tool with a named maintainer and a quarterly review cadence.
Other Skills in This Method
Prioritizing Journeys for Optimization
How to assess and rank journeys by business impact, customer friction, and strategic alignment to decide where to focus improvement efforts.
Transitioning from Journey Mapping to Journey Management
How to evolve static journey maps into a dynamic, continuously managed journey management practice across teams.
Aligning Teams Around Journey Ownership
How to assign cross-functional ownership of journeys at each hierarchy level and establish governance for ongoing journey management.
Building a Journey Portfolio Inventory
How to catalog all customer journeys into a comprehensive portfolio that serves as the foundation for ecosystem-level analysis and management.
Identifying Cross-Journey Insights and Patterns
Techniques for analyzing interconnected journeys to surface systemic pain points, redundancies, and optimization opportunities across the ecosystem.
Mapping Touchpoint Interconnections Across Journeys
How to visualize and document the relationships between touchpoints, channels, and journeys to create a holistic ecosystem view.
Frequently Asked Questions
How do I decide whether something is an L2 scenario or an L3 micro-journey?
Apply the scope test. An L2 scenario represents a complete path through a lifecycle stage for a specific persona or context, covering multiple touchpoints and potentially spanning days or weeks. An L3 micro-journey represents a single interaction or tightly coupled set of interactions at one touchpoint, typically completed in minutes or hours. If the journey you are classifying involves multiple distinct touchpoints across different channels or time periods, it is likely an L2. If it is focused on a single task at a single touchpoint, it is an L3. When in doubt, check whether the candidate could be further decomposed into meaningful sub-interactions. If it can, it is probably an L2.
How long should it take to build the full hierarchy from scratch?
For a first pass covering L0 through L2, plan for 3-5 hours of collaborative workshop time with journey owners, plus 2-3 hours of documentation. L3 decomposition takes 1-2 hours per L2 journey and should be done progressively, not all at once. A mid-size organization with 5-6 L1 stages and 15-20 L2 scenarios can have a usable hierarchy within one week of calendar time. Trying to complete every L3 before publishing the hierarchy is a common cause of delay. Publish at L2 and elaborate L3s as needed.
Should I structure journey hierarchy levels before or after building a journey portfolio inventory?
Build the hierarchy first. The portfolio inventory from [building a journey portfolio inventory](/skills/building-a-journey-portfolio-inventory) requires a consistent classification system to organize journeys by level, owner, and status. Without the hierarchy, your inventory becomes a flat, unsorted list that is difficult to navigate or prioritize. The hierarchy gives you the taxonomy. The inventory populates it with metadata, status, and links to detailed maps.
How do I handle journeys that span multiple L1 stages?
Some customer experiences genuinely cross stage boundaries, such as a 'switching from a competitor' journey that touches Evaluation, Purchase, and Onboarding. Rather than creating an L2 that spans three L1s, break it into stage-specific L2 segments: 'Competitive Evaluation' under Evaluation, 'Competitive Purchase' under Purchase, and 'Migration Onboarding' under Onboarding. Then annotate the cross-stage relationship in your hierarchy documentation so teams know these L2s form a connected sequence. This preserves the clean parent-child structure while acknowledging the cross-stage reality. The [mapping touchpoint interconnections](/skills/mapping-touchpoint-interconnections) skill covers how to formalize these cross-journey links.
Why does my hierarchy keep changing every quarter?
If your L0 and L1 levels are changing frequently, your definitions are probably too narrow or too tied to current product features rather than fundamental customer lifecycle phases. L0 and L1 should be stable for years because the basic shape of the customer lifecycle rarely changes. L2 and L3 levels should evolve more often as you add new products, segments, channels, or optimize specific interactions. If L1 instability is the issue, redefine your L1 stages around customer states (evaluating, onboarding, deriving value) rather than product-specific actions (using feature X, configuring integration Y).
Can I use customer journey hierarchy levels for internal employee journeys or just external customers?
The L0-L3 hierarchy works for any relationship where someone moves through stages with your organization, including employee experience, partner experience, and developer experience. The same principles apply: one L0 lifecycle, stages at L1, scenarios at L2, micro-interactions at L3. Some organizations maintain separate hierarchies for customer and employee journeys but use the same structural conventions so that teams familiar with one can immediately navigate the other. The key is not to mix user types within a single hierarchy unless they share genuine touchpoints that need coordination.
What tools work best for documenting and maintaining the hierarchy tree?
Avoid static tools like PowerPoint or PDF. The hierarchy needs to be searchable, linkable, and editable by multiple people. Structured tools work best: Notion databases with a 'parent journey' relation field, Airtable bases with linked records, or purpose-built journey management platforms like TheyDo or Smaply. For the visual tree diagram, collaborative whiteboard tools like Miro or FigJam work well. The ideal setup is a structured database for the authoritative data (names, levels, owners, boundaries) with a visual diagram generated from or linked to that data. This prevents the common problem of the visual diagram and the documentation drifting apart.