Meet the TheyDo Agent

How to recognize and organize journeys at scale

The hardest question in journey management is not how to build a journey. It is deciding what counts as one, and whether the one you need already exists. This article gives you working rules for spotting a journey, placing it at the right decision-making altitude, naming it so other people can find it, and connecting it into the graph rather than duplicating it. It is for whoever is responsible for the shape of the portfolio, not just the content of one map.

Is it a journey, a phase, or a step?

Most arguments about structure are this question in disguise. Three tests usually settle it.

The goal test. A journey is something a customer is trying to accomplish, with a beginning and an end they would recognize. "Move house" is a goal. "Awareness" is not: nobody sets out to become aware. If your candidate has no customer goal, it is probably a phase.

The retelling test. Ask someone to describe it out loud. If they naturally say "first they do this, then this, then this", you have a sequence, so a journey. If they say "it is the bit where they are deciding", you have a phase inside someone else's journey.

The evidence test. A journey needs enough evidence of its own to be worth maintaining. If everything you know about it would fit as two insights on a single step of a journey you already have, make it a step.

Note: getting this wrong is not fatal and not permanent. A step that grows up can become a nested journey later, and an over-ambitious journey can be absorbed back into a step.

Check the graph before you create anything

This is the habit that matters most at scale, and the one teams skip.

Because a journey in TheyDo can be referenced by more than one journey above it, the shared parts of an experience only need to exist once. "Finance application" is the same experience whether the customer started in a showroom or online. Built once and connected in both places, it has one owner and one set of evidence. Built twice, it has two of each, and within a month they disagree.

So before creating a journey:

Search the journey library for the customer's goal, not your project name. Most duplicates are the same journey named twice.
If something close already exists, ask whether it is genuinely a different experience or the same one seen from a different starting point. If it is the same, connect the existing journey where you needed it instead of creating a new one.
If it is genuinely new, create it, then connect it immediately. An unconnected journey is invisible to everyone navigating the structure.

Tip: build once, reference many times. If you find yourself typing a journey name that already exists in the workspace, stop and connect instead.

Place it at a decision-making altitude

Before creating anything, decide which height the journey belongs at. Height is not about how much detail you plan to add. It is about which decisions get made there and by whom:

Lifecycle. Where you decide where to invest across the whole customer relationship. Usually one per customer type. Audience is leadership.
Macro. Where you decide what to fix or build within one major experience, such as "Buying a phone" or "Making a claim". This is where most journeys live, and where most decisions get made.
Micro. Where you decide how something should actually work, such as "Activating the SIM". Audience is the people designing and researching it.

A quick self-check: name the person who would open this journey on a Monday morning and say what they would decide from it. If you cannot name either, the journey may not need to exist yet. See Journey framework zoom levels.

Name journeys so other people can find them

Naming is the cheapest governance you will ever do, and the easiest to skip. In a graph it matters twice over, because a journey nobody can find is a journey somebody rebuilds.

Name the customer's goal, not the internal project. "Renew a policy" ages well. "Q3 renewals workstream" does not.
Use the customer's verb. Journeys that start with a verb ("Open an account", "Report a fault") read as journeys. Nouns tend to read as phases.
Keep one vocabulary per altitude. If one macro journey is "Buying a phone", its siblings should not be "Device purchase process" and "Handset acquisition".
Leave the level out of the title where you can. The structure already says where it sits.
Say which market or segment it is, when that is what makes it different. Two journeys with the same name and no qualifier is the most common cause of duplicated work at scale.

Tip: agree the naming pattern with the people who create journeys, not only the people who read them.

Decide whether to connect, nest, or split

Once a journey is real, one more decision follows.

Connect it in more than one place when the same experience genuinely belongs under several journeys. This is the move a filing tree cannot make, and the reason the structure is worth building.

Nest it when the detail belongs to a specific step of a bigger journey, when different audiences need different depth on the same experience, or when a journey has grown too long to read in one screen. See What are nested journeys?

Split it when two experiences do not share a customer goal, or when two branches diverge so early that mapping them together hides more than it shows.

Keep a growing graph clean

Four habits do most of the work.

Give every journey an owner. A journey without a named owner will not be maintained, and unmaintained journeys are what make a portfolio untrustworthy.
Hunt for orphans. A journey that belongs in the structure but was never connected cannot be reached by anyone navigating it. If your workspace shows an Observatory page, it can filter for exactly these.
Walk the graph, not the list. Once a quarter, start at the top and move down each branch: is this journey still at the right altitude, still owned, still touched by anyone. Duplicates and orphans are far easier to see in the structure than in a flat list.
Archive rather than delete. A journey that is finished but historically interesting should be archived, so it leaves the working portfolio without losing the evidence attached to it. See What is archiving?