One Journey Map, Three Tracks

One Journey Map, Three Tracks

Why this matters

How a simple onboarding journey map became three planning tracks right before annual planning.

One Journey Map, Three Tracks How a deliberately simple onboarding journey map for group practices became three planning tracks a few weeks before annual planning. How a simple onboarding journey map became three planning tracks right before annual planning. Build the journey map from the people who onboard customers by hand, mark friction in one color, then split findings into tracks by purpose (pricing, scalability, time to value) so each can be prioritized on its own.

How a deliberately simple onboarding journey map for group practices became three planning tracks a few weeks before annual planning.

A design lead on our team finalized a journey map this week for group practices getting onboarded, and the first thing he said about it was that it isn’t a true journey map. He kept it simple on purpose. It came out of 5 calls with sales, customer success, and the onboarding specialists who walk new practices through setup by hand, run with a partner from the onboarding side who’s been in every one of those calls. That sourcing is the first move worth stealing. The people who onboard customers manually already know where the product falls short, because they’re the ones filling the gap.

The structure is one managed path, where practices get a specialist and hands-on training, and four self-serve paths where they don’t. Everything in red is friction: a place where setup becomes a problem for the specialist or for the practice on its own. It’s a pretty big list under that column, and it’s platform-wide. Documentation shows up. Calendar settings show up. Nothing about it is scoped to the squad that made it, which is what makes it useful to everyone else.

A journey map earns its keep by what it feeds. This one fed 3 planning tracks a month before annual planning.

He was clear that squads won’t get much from the overall journey. They’ll get the bucketed issues, not a feature list. The value is in the split he made downstream. The map now feeds 3 tracks, each with a different purpose. Group SKU work, which is about planning and pricing. Group scalability work, which is about the systems holding up as practices grow and traces back to an onsite earlier this year. And onboarding and setup, which is about time to value: cutting the days between starting an account and seeing a first client, including getting teammates in, intake documents built, clients added, locations, calendar settings, service codes, and rates per clinician.

Splitting the findings that way means each track can be prioritized on its own terms. Pricing questions go to the people who own pricing. Scalability goes to the platform conversation. Time to value becomes a near-term lever, mostly in-product guidance and cleaner setup workflows, that doesn’t have to wait on the other two. And it landed a few weeks before annual planning, which is the tactic. A map that arrives after the roadmap is set is a nice artifact. A map that arrives before it is an argument.

The last thing I’ll credit him for is restraint. It would have been easy to make this a polished, end-to-end journey with personas and emotion curves. He made a working document with a red column and 3 exits, and it’s already shaping the asks going into planning.

Filed under TB Toolbox — Frameworks you can steal.