Ecosystem Journey Framework: Managing Customer Journeys

Created by TheyDo (reference write-up; no single originator) - https://www.theydo.com/blog/articles/simplify-journey-mapping-with-the-journey-framework

Overview

The Ecosystem Journey Framework is a way to hold every customer journey an organization knows about in one layered structure, from a single overview of the whole customer relationship down to individual interactions. The customer journey hierarchy levels are usually labelled L0 to L3. Instead of treating each journey map as a standalone deliverable, the framework treats the full set as a portfolio that is inventoried, connected, prioritized, owned, and kept current. That shift from mapping journeys to managing them is the reason the framework exists.

The framework as described here follows the journey management platform TheyDo, whose article Simplify journey mapping with the journey framework defines a journey framework as "a structured system for organizing, managing, and prioritizing customer journeys at scale." TheyDo does not claim to have invented the idea. The same article says it is "not a totally new concept," notes that Forrester calls it the "Journey Atlas" and Deloitte the "Journey Foundation," and lists "ecosystem" among its other names, alongside collection, universe, catalog, and library. The name Ecosystem Journey Framework reflects that last label and the framework's focus on how journeys connect. No single person is credited with the L0-L3 numbering, and the sources below number the levels in different ways.

The problem it addresses is familiar to any organization with more than one team touching customers. Marketing maps acquisition, product maps onboarding, and support maps service recovery. Marc Stickdorn of Smaply describes what follows in Managing multiple customer journeys: the same touchpoints mapped differently by different teams, maps in inconsistent formats, orphan maps nobody maintains, no view of how maps connect, and no basis for deciding which journeys deserve investment. A journey framework answers those problems with a hierarchy, explicit connections between journeys, and governance.

The four customer journey hierarchy levels give everyone a shared zoom setting. In TheyDo's version, L0 is a strategic overview for executives, L1 is a macro view of a whole purchasing journey, L2 holds micro journeys such as navigating an online store, and L3 holds individual-level source journeys. JourneyTrack's L0 to L3 guide calls L0 the "Ecosystem View," a network of teams, partners, systems, and journeys, with L1 as the customer lifecycle, L2 as core journeys like onboarding, and L3 as task flows like resetting a password. This page uses those JourneyTrack definitions as its working convention because they are the most explicit. The skill on Ecosystem Journey Framework levels covers how to set the boundaries.

The case for managing journeys rather than touchpoints has research behind it. In the Harvard Business Review article The Truth About Customer Experience, McKinsey partners Alex Rawson, Ewan Duncan, and Conor Jones report that performance on journeys is 30% to 40% more strongly correlated with customer satisfaction than performance on touchpoints. They also recommend that companies identify the journeys that matter most and build cross-functional processes to redesign them. Nielsen Norman Group's Kim Flaherty argues in The Practice of Customer-Journey Management that journeys should be managed like products, by people in journey-dedicated roles who research, measure, optimize, and orchestrate them over time.

Put together, the framework produces a small set of durable artifacts: a customer journey inventory of every known journey, an agreed level for each journey, a map of how journeys and touchpoints connect, a ranked list of journeys to improve, a named owner and review rhythm per journey, and a running register of cross-journey insights. The customer journey inventory is usually the first of these to build. Ownership is what turns the rest into journey management team alignment, and the skill on aligning teams around journey ownership covers it in detail.

The framework does not prescribe a research method. Interviews, analytics, and service blueprints still produce the content of each journey. The framework is the structure those efforts plug into, which Essense describes in its journey framework guide as "a bit like the table of contents of your entire service." Teams that keep their method and blueprints in Hamster can store the hierarchy and ownership decisions alongside them, so agents working on customer experience read the same structure the team agreed on.

Core Principles

Journeys Form a Connected Portfolio

Every journey sits next to others. A confusing invoice shows up in the billing journey, the support journey, and the renewal journey. Smaply's guide to managing multiple journeys names three kinds of connection: parent and child links in the hierarchy, handoffs between sequential journeys, and shared touchpoints that appear in several journeys. Treating journeys as a connected set is what lets one fix help several journeys at once.

Levels Create a Shared Language

When an executive and a designer both say "onboarding," they often mean different scopes. Agreeing that onboarding is an L2 journey under the Use stage of the L1 lifecycle removes that ambiguity. Forrester's CX Cast episode on journey atlases, featuring analyst Joana de Quintanilha, says a journey atlas helps companies "establish and sustain a shared customer-centric language across silos." The level labels matter less than everyone using the same ones.

Management Keeps Maps Useful

A journey map describes an experience at one moment, and the experience keeps changing. Smaply's journey management guide says mapping captures a snapshot while management treats the map as a living asset connected to measurement and action. Without owners and reviews, maps drift out of date and people stop trusting any of them. The framework assumes journey knowledge is maintained the way a product backlog is maintained.

Prioritize Across the Portfolio

Not every journey deserves the same investment. Rawson, Duncan, and Jones recommend combining top-down executive judgment with bottom-up data analysis to identify key journeys, and note that best-in-class companies use regression models to see which journeys most affect satisfaction and business outcomes (HBR). Ranking journeys against explicit criteria keeps investment away from whichever journey was mapped last or whichever stakeholder complained loudest.

Every Journey Needs a Named Owner

Customer journeys cross departments, so without an explicit owner nobody is accountable for the whole experience. Nielsen Norman Group compares the journey manager to a product owner and advises that a journey manager should own just a single customer journey (NN/g). An owner does not do all the work. They keep the journey's picture current, surface problems, and coordinate the teams who fix them.

Insights Travel Between Levels

A failed task at L3 can explain a satisfaction drop at L1, and a strategic shift at L0 can make an L2 journey urgent. JourneyTrack describes the value of the levels as tracing insights "from a single failed task (L3) to strategic ecosystem decisions (L0)" (JourneyTrack). The review rhythm is how that traffic happens in practice. When insights stop moving between levels, leaders decide without ground truth and frontline teams fix steps in journeys that may not matter.

Start Broad, Deepen Selectively

Mapping everything at full detail before the structure exists wastes effort on journeys that later turn out to be low priority. Smaply advises starting with the lifecycle and a handful of detailed journeys for the highest-priority experiences, and adding the finest level only where it drives better decisions (Smaply). Depth can always be added later. Momentum lost to an overwhelming first pass is harder to recover.

How Practitioners Number the Levels

The L0-L3 labels are a convention, and sources that use the same labels do not always mean the same thing by them. Before adopting the framework, pick one set of definitions and write it down. The table compares the versions this page draws on.

Two differences matter in practice. Some versions start at L0 with an organization-wide or ecosystem view, while Smaply starts at L1 with the lifecycle, so an "L1" in one team's deck can be an "L0" in another's. The finest level also varies, from individual customers in TheyDo's article to system-level process steps in Conway's version. Neither choice is wrong, but mixing them in one portfolio breaks comparisons.

Steps

1. Inventory Existing Journey Knowledge Collect every journey artifact the organization already has: journey maps, service blueprints, research reports, support ticket analyses, and sales process documents. Interview leads in product, marketing, sales, support, and success to find journeys that live only in people's heads. Record each in a single inventory with its name, owning team, date, source evidence, and status. Expect duplicates, gaps, and contradictions, and record them rather than resolving them yet. The journey portfolio inventory skill describes the attributes to capture.

2. Agree the Level Definitions Choose which numbering convention the organization will use and write a one-line definition and a test for each level. Decide whether L0 is an ecosystem view or the lifecycle itself, and what the finest level contains. Show the definitions to people from at least two different functions and check that they classify a few sample journeys the same way. Publish the definitions before anyone starts assigning levels. Skipping this step leaves each team classifying journeys by its own private convention.

3. Build the Top Levels First Sketch the L0 view and the L1 lifecycle with a small number of broad stages in the customer's language. Kerry Bodine, for example, uses nine customer-language stages: Need, Seek, Choose, Give, Get, Use, Fix, Love, and Leave (Bodine). Place every inventoried journey under a stage, and flag stages with nothing under them as gaps. Keep the top view small enough to read on one screen. If it keeps growing, detail from lower levels is leaking upward.

4. Prioritize Which Journeys to Deepen Score the L2 candidates against explicit criteria such as business impact, customer pain, strategic fit, and feasibility, which are the four inputs Smaply lists for journey prioritization. Use operational and customer data where it exists and executive judgment where it does not, as the HBR authors recommend. Select a small number of journeys to map in depth now and record why the rest wait. Revisit the ranking on a fixed rhythm and whenever strategy changes. The prioritization skill walks through a scoring model.

5. Map Priority Journeys and Their Connections Research and map each selected journey at L2, adding L3 detail only where a specific interaction needs it. Give every map a parent, a clear start, and a clear end, so neighbouring journeys do not bleed into each other. Record what precedes and follows each journey and which touchpoints it shares with others. Service blueprints help at this stage because they tie touchpoints to the backstage processes behind them. The result is a set of connected maps with known boundaries.

6. Assign Owners and a Review Rhythm Name one accountable owner for each journey at each level. Owners of broad levels are usually senior leaders, while owners of detailed journeys are the product managers, designers, or service leads closest to the work. Set a review cadence that matches how fast each journey changes, and add triggers such as a product launch or a sharp metric move. Tie reviews to planning forums that already exist so they do not become an extra meeting nobody attends. Without owners and reviews, the hierarchy decays into another set of static artifacts.

7. Analyze Across Journeys and Route Insights Compare journeys side by side to find pain points, handoff failures, and shared touchpoints that recur in several places. A problem that appears in many journeys usually has one root cause, and fixing it once helps all of them. Record each cross-journey insight with its evidence, the journeys it affects, and an owner. Feed the strongest insights into roadmaps and the next prioritization cycle. Start with one or two improvements, measure the effect, and use the results to build support for the practice.

When to Use

• When several teams each hold journey maps and nobody can say which are current, which overlap, or which contradict each other. The inventory and hierarchy turn scattered artifacts into one picture.
• When product, marketing, sales, support, and success each touch the customer and keep talking past each other about "the journey." Agreed levels give them a shared vocabulary for scope.
• When leadership asks where to invest in customer experience next and the answer depends on opinion. A ranked portfolio gives the discussion a structure and evidence.
• When a customer experience practice is growing from occasional mapping projects into an ongoing program. The framework supplies the ownership and review structure a program needs.
• When the organization serves several segments or products whose journeys overlap. Shared levels and tags make it possible to compare journeys across segments without running separate programs.

When Not to Use

• When a small team with one product and one segment can hold the whole journey in a single map. The overhead of levels, owners, and reviews outweighs the coordination benefit at that size.
• When the immediate need is deep research into one broken journey. Run that research first, then place its results in the framework, because building the portfolio will delay the answer.
• When the organization has almost no journey knowledge yet. The framework organizes and connects research, and without some research it produces an empty structure.
• When stakeholders do not yet value journey thinking at all. One compelling journey map that changes a decision will do more than a hierarchy imposed from above.