levelpartner.ai
Reporting and attribution

Customer journey framework: how it works and how to set it up

A customer journey framework is the rulebook behind your journey: the agreed definitions, owners, entry rules and measures that every team works to. Without one, sales calls a contact "qualified" on Tuesday and marketing calls the same contact a cold lead on Wednesday. This article answers a narrow question: what goes into the framework, and how do you encode it in the levelpartner.ai platform so that the rules are enforced by the system instead of remembered by people.

What a framework contains

Think of it in five layers. Stages are the steps a customer moves through. Definitions say exactly what has to be true for a contact to be in each stage. Owners name the person or role accountable for moving contacts out of that stage. Measures are the one or two numbers you watch per stage. Review is the rhythm in which you check the whole thing.

A journey map is a picture. A framework is the contract between the teams that sit behind the picture. You can have a map without a framework, but it will drift within a quarter.

Before you start

  • A first draft of your stages. The customer journey stages guide helps if you do not have one.
  • Leaders from sales, marketing and delivery willing to agree definitions in writing.
  • Admin access to Settings for custom fields, and to Opportunities for pipelines.
  • One person who will own the framework document and its changes.

How to set it up

  1. Write one sentence per stage stating the condition a contact must meet to enter it.
  2. Agree the exit condition for each stage, which is the entry condition of the next.
  3. Name a single owning role for each stage, not a team.
  4. Pick no more than two measures per stage, such as volume in and deals gone stale.
  5. In Opportunities > Pipelines, create a pipeline with one stage per framework stage.
  6. In Settings > Custom Fields, create a field for any manual entry condition.
  7. Build a workflow with Find Opportunity, then an Update Opportunity action.
  8. Add an Assign to User action to a Pipeline Stage Changed workflow per stage.
  9. Add a dashboard widget for each measure you named.
  10. Book a recurring monthly review for the framework owner and stage owners.

Writing definitions people cannot argue with

A good definition is testable. "Interested prospect" fails, because two people will disagree. "Has booked a discovery call and given a project start date" passes, because the platform can check both.

Every definition should point at a field, a tag, a booking or a payment. If you cannot name the record that proves the condition, the definition is still an opinion.

Illustration: a 60-person agency writing its first framework

Say the agency agrees five stages: enquiry, qualified, proposal, client, renewal. Qualified means a booked call plus a budget field above £15,000. Proposal means a proposal sent with a recorded value. If sales had been reporting 90 qualified leads a month and marketing 140, the framework would leave one figure, perhaps 104, because both teams read the same field. These figures are illustrative.

What it is for in a stalled business

When revenue is flat, the first meeting about it usually turns into an argument about whose numbers are right. A framework ends that argument before it starts. It also makes handoffs visible. When a stage has a named owner and a time measure, a stage that silently holds contacts for six weeks becomes someone's problem.

It replaces the job descriptions, the slide deck from the last offsite and the shared spreadsheet that nobody updates after March.

Time it takes each week

Writing the framework takes two half-day sessions. Encoding it in the platform takes one to three days. Ongoing, the framework owner spends about 30 minutes a week checking that stage counts look plausible and an hour a month running the review.

The mistake most people make

The common mistake

Letting each team keep its own version. Marketing keeps "MQL" in a spreadsheet, sales keeps "SQL" in their heads, and the platform holds a third version. One framework, one set of fields, one pipeline. Everything else is retired.

When not to use one

A firm with fewer than ten staff and one person handling every enquiry does not need a written framework. That person is the framework. It becomes necessary when two or more people touch the same customer, or when you start reporting stage numbers to a board. For the operating rhythm that follows, see customer journey management.

Troubleshooting

Opportunities skip stages

Staff are dragging cards straight to won. Restrict who can edit stage values, or rely on workflows to move cards based on the entry fields.

Two stages overlap

Their definitions share a condition. Rewrite one so that a contact can satisfy only one at a time.

Owners ignore their stage

The measure is not visible to them. Put their stage count and stale-deal count on a dashboard they open daily, which the customer journey visualization guide explains.

The framework document and the platform disagree

Someone changed a workflow without updating the document. Make the framework owner the only person who approves stage or definition changes.

Frequently asked questions

How is a framework different from a model?

The model is the shape of the journey, such as a straight funnel or a loop that returns through referrals. The framework is the set of rules that runs it. A customer journey model comes first; the framework makes it operational.

How often should we change the framework?

Rarely. Review it monthly but change it only when a definition is clearly failing. Frequent changes break your trend data.

Can different services use different frameworks?

They can share one framework and run separate pipelines. Keep the definitions identical so that reporting across services remains comparable.