The Ecosystem Journey Framework: Managing the Customer Journey as a Living System
The Ecosystem Journey Framework is a structured system for organizing every customer journey an organization touches into a managed hierarchy of four levels (L0 through L3). It moves teams beyond static journey maps toward dynamic journey management, connecting touchpoints across departments so organizations can spot patterns, prioritize improvements, and align around shared customer outcomes.
Overview
Most organizations discover, at some point, that they have dozens or even hundreds of customer journey maps scattered across teams, tools, and slide decks. A product team maps onboarding. A support team maps escalation. Marketing maps acquisition. Each map tells a useful local story, but nobody can see how those stories connect, where they contradict each other, or which journeys actually matter most to the business. The Ecosystem Journey Framework was introduced by the TheyDo team to solve exactly this structural problem. Rather than treating journey mapping as a one-off research exercise, it proposes a permanent, hierarchical inventory of journeys that a company actively manages over time.
The framework's core claim is that customer journeys are not isolated artifacts. They form an interconnected ecosystem, and the relationships between journeys carry as much signal as the journeys themselves. A friction point in the onboarding journey might explain churn patterns visible three levels up in a lifecycle journey. A support journey might reveal upsell opportunities that belong in a sales journey nobody has mapped yet. By organizing journeys into four nested levels, L0 (lifecycle), L1 (major phases), L2 (specific journeys within phases), and L3 (granular steps or sub-journeys), the framework gives teams a shared coordinate system for talking about customer experience without losing detail or drowning in it.
This approach sits at the intersection of service design, customer experience management, and portfolio thinking. Where traditional journey mapping borrows from design thinking and ethnographic research, the Ecosystem Journey Framework borrows from how product teams manage backlogs or how portfolio managers think about asset allocation. It asks: given everything we know about every journey our customers take with us, where should we invest next? That question cannot be answered by a single journey map, no matter how beautiful. It requires a view of the whole landscape.
The framework has evolved since its introduction as more organizations adopted journey management as a discipline rather than a project. Early versions focused heavily on the hierarchy itself, essentially a taxonomy problem. More recent thinking emphasizes the dynamic aspects: how journeys change over time, how insights flow between levels, and how teams take ownership of specific parts of the hierarchy without losing sight of the whole. The shift from mapping to management is the central thesis. A map is a snapshot. Management is an ongoing practice. Organizations that treat their customer journey portfolio the way they treat their product portfolio, with regular review, clear ownership, and data-driven prioritization, tend to find more actionable insights and close more cross-functional gaps.
The Ecosystem Journey Framework is most valuable for mid-size and enterprise organizations where multiple teams touch the customer experience and where the sheer volume of journeys makes ad-hoc mapping unsustainable. Startups with a single product and a small team can usually hold their customer journey in their heads. But once an organization crosses roughly 50 people, or ships more than one product, or serves more than two distinct customer segments, the coordination cost of journey knowledge rises sharply. That is where a framework, not just a map, starts to pay for itself.
It is worth noting what the framework does not do. It does not prescribe a specific research methodology. It does not tell you how to run a journey mapping workshop or what sticky notes to use. It is a structural layer that sits above individual mapping efforts, giving them a home, a context, and a way to be compared. Think of it as the filing system for your journey intelligence. The quality of each file still depends on the research that goes into it, but without the system, files get lost, duplicated, or ignored.
Teams working within Hamster can organize their journey hierarchy as a living workspace, using AI agents to surface cross-journey patterns and keep the portfolio current without manual overhead.
How It Works
Step 1: Audit Your Existing Journey Knowledge
Before building a hierarchy, gather everything your organization already knows about customer journeys. This includes formal journey maps, service blueprints, user research reports, support ticket analyses, sales process documents, and even informal sketches on whiteboards. Interview team leads across product, marketing, support, and sales to surface journey knowledge that exists in people's heads but has never been documented. The goal is not to validate or refine these artifacts yet, just to collect them. You will likely find redundancy (three teams mapped onboarding differently), gaps (nobody has mapped the renewal experience), and contradictions (marketing thinks the trial journey is smooth while support data says otherwise). Document what you find in a simple inventory with columns for journey name, owning team, date created, and current status. A common mistake here is trying to standardize or reconcile everything in this step. Resist that urge. Cataloguing comes first.
Step 2: Define Your L0 Lifecycle Journey
The L0 level represents the entire customer lifecycle from first awareness through long-term advocacy or churn. Sketch this as a single, high-level arc with broad phases. For a B2B SaaS company, this might be: Awareness, Evaluation, Purchase, Onboarding, Adoption, Expansion, Renewal, Advocacy. For an e-commerce brand, it might be: Discovery, Consideration, Purchase, Delivery, Use, Repurchase. Keep the L0 simple, typically 5-8 phases. It should fit on one screen or one whiteboard. The L0 is not where detail lives. It is the map of the map, the table of contents for your journey portfolio. Validate it with at least three stakeholders from different departments to ensure the phases reflect reality, not just one team's perspective. Watch out for the tendency to make L0 too granular. If you have more than 10 phases at L0, you are probably mixing levels.
Step 3: Identify L1 Journey Categories Within Each Phase
For each L0 phase, identify the major journey categories that customers experience. ' L1 journeys should be recognizable to any team that touches that phase. They represent the primary paths customers take, not every possible variation. Reference the inventory from Step 1 to see which existing maps and research fit into which L1 categories. Some will map cleanly. Others will reveal that two teams described the same journey differently, which is valuable information. Assign a preliminary owner to each L1 journey, even if ownership is contested. Contested ownership is a finding, not a blocker. You will resolve it in a later step.
Step 4: Prioritize Which L1 Journeys to Deepen Into L2
You cannot and should not map every journey at L2 detail simultaneously. ). Score each L1 journey and select the top 3-5 for deeper exploration. This is where portfolio thinking becomes practical. Stakeholders will push for their own journeys to be prioritized. Having explicit criteria and scores makes the conversation productive rather than political. Revisit this prioritization quarterly as business context shifts. A journey that was low-priority last quarter might become urgent after a product launch or competitive shift.
Step 5: Map Priority Journeys at L2 and L3 Detail
For each prioritized L1 journey, conduct the research needed to map it at L2 (specific journeys within the category) and, where warranted, L3 (individual steps, interactions, or moments within those journeys). This is where traditional journey mapping methodology applies: customer interviews, behavioral data analysis, service blueprinting, and cross-functional workshops. The key difference from standalone mapping is that you are now placing each map within the hierarchy, which means every L2 and L3 map has a clear parent and clear boundaries. Define where each journey starts and ends explicitly. A common pitfall is allowing L2 journeys to bleed into each other because the boundaries were never agreed upon. Document not just the journey itself but its connections: what journey precedes it? What follows? Where do customers branch into alternative paths?
Step 6: Assign Ownership and Establish Review Cadence
For each level of the hierarchy, assign a clear owner. L0 is typically owned by a CX leader or chief customer officer. L1 owners are usually department heads or senior managers whose teams have the most influence over that phase. L2 and L3 owners are the practitioners, product managers, designers, or service leads closest to the work. Ownership means three things: keeping the journey knowledge current, surfacing cross-journey insights to the appropriate audience, and coordinating improvement efforts. Establish a review cadence. Monthly reviews for active L2/L3 journeys under improvement, quarterly reviews for the L1 portfolio, and annual reviews for the L0 lifecycle. Without a cadence, the hierarchy becomes another set of static artifacts. The review is also the mechanism for insights to flow between levels, a ground-level L3 finding surfaces to inform an L1 strategic decision.
Step 7: Surface Cross-Journey Insights and Act on Them
The framework's highest-value output is not any individual journey map but the patterns that emerge across journeys. Look for recurring pain points that appear in multiple L2 journeys, which often indicates a systemic issue rather than a local one. Look for handoff failures between journeys owned by different teams. Look for moments where customer expectations set in one journey are violated in another. Create a mechanism for capturing and routing these insights, whether that is a shared board, a regular cross-functional meeting, or a dedicated insights channel. The danger at this step is analysis paralysis. Not every cross-journey pattern requires action. Prioritize insights the same way you prioritized journeys: by business impact, customer pain, and strategic relevance. Start with one or two cross-journey improvements, demonstrate the value, and use those wins to build organizational commitment to the practice.
When to Use
- When your organization has accumulated more than 15-20 journey maps across different teams, tools, and time periods, and nobody can confidently say which maps are current, which overlap, or which contradict each other. The framework gives you a taxonomy to organize existing knowledge before it becomes unusable.
- When multiple departments (product, marketing, support, sales, success) each touch the customer experience and need a shared vocabulary for discussing cross-functional friction. Without a hierarchy, each team defines 'the customer journey' differently, and alignment meetings become translation exercises rather than decision-making sessions.
- When leadership asks 'where should we invest in customer experience next?' and the CX team cannot answer with data-backed prioritization because journey insights are trapped in individual maps with no mechanism for comparison. The portfolio view the framework provides turns a subjective debate into a structured analysis.
- When you are scaling a customer experience practice from one researcher doing occasional mapping to a team or program responsible for ongoing journey intelligence. The framework provides the scaffolding that makes CX a managed discipline rather than a project-based activity.
- When your organization serves multiple customer segments (e.g., self-serve SMB, mid-market with onboarding, enterprise with dedicated success managers) and needs to understand how journey patterns differ across segments without building entirely separate journey programs for each.
When Not to Use
- When you are a small team (under 20 people) with a single product and a single customer segment. At that scale, you can hold the entire customer journey in your head, and the overhead of maintaining a four-level hierarchy will outweigh the coordination benefits. A simple journey map on a whiteboard, reviewed monthly, is sufficient until complexity demands more structure.
- When the immediate need is deep qualitative research into one specific journey, such as understanding why trial-to-paid conversion dropped 15% last quarter. The framework is a portfolio-level organizational tool, not a research methodology. Trying to set up a full hierarchy when you need a focused investigation will delay the insight you actually need. Do the research first, then find where the results fit in the framework.
- When the organization has no existing journey knowledge at all, no maps, no research, no customer interviews, no behavioral data. The framework organizes and connects journey intelligence. It does not generate it from nothing. Without at least some foundational research, you will end up with an elegant empty taxonomy. Build some journey understanding first, even rough and scrappy, before imposing structure.
- When the organization's CX maturity is very low and stakeholders do not yet see the value of journey thinking. Introducing a hierarchical framework before people believe in journey mapping at all tends to feel like bureaucracy imposed from above. Start with one compelling journey map that changes someone's mind, then scale to the framework once you have internal champions.
- When your business model involves a single, short transaction with no ongoing relationship (e.g., a one-time e-commerce purchase with no account creation). The framework's power comes from mapping interconnected journeys over time. If the customer relationship is a single event, the framework adds unnecessary complexity.
Examples
Example: B2B SaaS Company With 200 Employees and Three Product Lines
A mid-market SaaS company selling project management, time tracking, and invoicing tools discovered it had 47 journey maps created by different teams over three years. Product had onboarding maps for each tool. Marketing had acquisition funnels for each segment. Support had escalation maps. Nobody could say which maps were current. The CX team ran a two-week audit, catalogued all 47 maps, and found that 19 were outdated, 8 were duplicates with conflicting information, and several critical journeys (like cross-product upsell) had never been mapped at all. They built an L0 lifecycle with 7 phases, identified 22 L1 journeys, and prioritized 5 for L2 investigation based on a scoring model weighted toward revenue impact and support ticket volume. 3x higher retention, an insight invisible in any single journey map. The team would do one thing differently next time: involve sales leadership earlier, because the sales team's journey knowledge was the richest and most current, but they were only brought in during Step 5.
Example: E-Commerce Brand Scaling From 1 to 4 Markets
An e-commerce fashion brand expanding from the UK into Germany, France, and the Netherlands used the framework to understand how the customer journey differed by market. Their L0 lifecycle was straightforward: Discovery, Browse, Purchase, Delivery, Return, Repurchase. At L1, they identified 14 journey categories. But when they deepened into L2 for the 'Return' phase, they discovered that the German market had fundamentally different return expectations (free returns with no questions asked were table stakes), which required a different logistics journey, different communication journey, and different refund timeline. Without the framework, the team would have designed a single return journey for all markets based on their UK experience. ' at every level. They mapped L2 returns for each market in parallel, revealing that return-related support contacts in Germany were 3x higher than the UK due to unclear communication, not policy. They fixed the communication flow and reduced contacts by 60%. Next time, they would build market segmentation into the L1 structure from the start rather than discovering it at L2.
Example: Healthcare Technology Platform Aligning Clinical and Commercial Teams
A health-tech company with 500 employees sold a patient engagement platform to hospitals. The customer journey involved two distinct personas: the hospital administrator who purchased the platform and the clinical staff who used it daily. These two groups had separate journeys that intersected at critical handoff points (procurement to implementation, training to daily use, contract renewal to feature adoption review). The company had strong journey maps for the administrator buying journey (owned by sales) and almost no documentation of the clinical staff experience (owned by nobody). Building the L0 lifecycle revealed this gap immediately. ' The cross-journey insight was significant: clinical staff dissatisfaction during the first two weeks of use was the strongest predictor of contract non-renewal 18 months later, stronger than administrator satisfaction, pricing, or feature gaps. This reshaped the company's investment priorities, moving resources from sales enablement toward clinical onboarding. The team learned that L0 should be validated with customer data, not just internal assumptions, because their original lifecycle phases did not match how customers actually experienced the relationship.
Example: Financial Services Firm Reducing Cross-Channel Friction
A retail bank with both branch and digital channels used the framework to understand why customers who started a mortgage application online frequently abandoned it and restarted in a branch. Their L0 lifecycle included phases for Awareness, Application, Underwriting, Closing, and Servicing. At L1, they had separate journeys for 'Digital application' and 'Branch application,' but these were managed by different departments with no coordination. The L2 mapping of 'Digital application' revealed 12 distinct steps. When they overlaid branch visit data, they found that 34% of digital applicants visited a branch between steps 6 and 8, the documentation upload and income verification phase. Customers were not abandoning digital. They were supplementing it with branch visits because the digital experience did not provide enough reassurance during a high-anxiety decision. The cross-journey view (mapping touchpoint interconnections between the digital and branch journeys) showed this was not a digital UX problem alone but a confidence gap that required a blended journey design. They added a video consultation option at step 7, reducing branch visits for digital applicants by 45% and cutting average time-to-close by 6 days. The lesson: journeys that appear separate to the organization are often a single journey in the customer's mind. The framework made that mismatch visible.
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.
Structuring Journey Hierarchy Levels (L0-L3)
How to define and organize customer journeys into hierarchical levels from macro (L0) to micro (L3) for scalable journey 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.