Journey Governance
Part of Lifecycle programme governance
Assigning owners to customer stages and event definitions
Decide who owns each lifecycle stage’s meaning, event data and use in customer journeys.
Give each customer stage three owners: a business owner decides what it means, a data owner maintains its supporting events, and a journey owner approves each customer-facing use. A disputed definition, a broken feed and a wrong message then have clear decision routes.
Start with the decision the definition controls
List where the stage or event is used: audience entry, message wording, sales handover, support routing and reporting. Write the customer fact it is meant to represent.
“Active” is too loose until the team specifies whether it means a current agreement, recent use or a verified completed task.
| Question | Owner to appoint | Decision to record |
|---|---|---|
| What counts as the stage? | Business owner | Entry, exit and exceptions |
| Does the event record it reliably? | Data owner | Source, schema and quality checks |
| May this journey use it now? | Journey owner | Eligibility and fallback when evidence is uncertain |
| How is it counted? | Metric owner | Unit, window and definition version |
Name a person or accountable role, a delegate and an escalation route. A shared team name alone may leave a disagreement unresolved. One person can hold more than one role.
Keep an ownership card
For each stage and event, record its plain-language meaning, approved uses, accountable owner, source-system contact, effective date and definition version. Include what the event cannot distinguish.
If a completed task can be reversed or done outside the product, state how those outcomes are recorded.
A Twilio Segment Tracking Plan can describe expected event names and properties and flag data that violates its specification. It cannot establish that the product sends a completion event at the right moment.
Business and data owners should compare the proposed rule with representative customer histories before approving its use.
For example, in a hypothetical shared workspace, product could own the meaning of “first useful task completed”, engineering the event and account identifier, and lifecycle marketing the setup reminder that uses them.
If support can complete setup for a customer, the card needs a rule for whether that confirmed outcome closes the reminder.
These assignments depend on the organisation; the point is to separate the decisions.
Resolve conflicts and changes
When systems disagree, record the affected customer or account, source records, event times and decisions waiting on the answer. The business owner resolves the meaning, the data owner investigates the feed, and the journey owner reviews any message that depends on the disputed fact. A metric owner marks affected reporting periods where needed.
For a definition change, identify dependent journeys and reports, approve an effective date and decide whether source records support recalculating history. Retain the previous definition so earlier decisions remain explainable.
A renamed event may describe the same outcome; an unchanged name may hide a changed meaning.
Revisit ownership when the product route, source system or responsible team changes. The card should tell a colleague who approves the definition, who can repair its data and who assesses its customer-facing use.
