Lifecycle Segmentation
Part of Lifecycle programme governance
Agreeing on shared lifecycle metrics with sales and support
Agree on the population, outcome, window, exceptions and owner behind a shared lifecycle scorecard.
Agree on shared lifecycle metrics by choosing a customer outcome that marketing, sales and support can recognise, then writing one counting rule for it. Keep message delivery, sales activity and support workload as separate diagnostics. Three figures called “activation” are not comparable if they count different units or outcomes.
Agree on the question first
Choose a decision that needs input from all three teams. For example: “Of newly eligible accounts, how many reached a confirmed usable setup?”
Marketing can describe the journey, sales can explain account and handover states, and support can identify assisted outcomes or unresolved setup faults. Decide separately whether an open issue affects the outcome, its interpretation or a diagnostic measure.
For each shared metric, agree on:
- Unit:person, account, order or agreement.
- Eligible population:who enters, when and with which exclusions.
- Outcome:the verified result, including any assisted or offline route.
- Window:when observation starts and how long a result can count.
- Uncertainty:how missing, late, duplicate and corrected records appear.
- Owner:who approves changes and resolves disputed cases.
Apply the written rule to the same sample customer histories. If the teams classify a case differently, settle the definition before adopting the chart.
Shared Lifecycle Metrics: Key Elements for Alignment Across Teams
- Unit
- person, account, order or agreement
- Eligible Population
- Who enters, when and with which exclusions
- Outcome
- The verified result, including assisted or offline routes
- Window
- When observation starts and how long a result can count
- Uncertainty
- How missing, late, duplicate and corrected records appear
- Owner
- Who approves changes and resolves disputed cases
Keep the scorecard small
Show eligible units, confirmed outcomes and unresolved exceptions for the same cohort. Add team diagnostics that help explain the result: journey entries or wrong sends, accepted handovers, and relevant unresolved or repeated support contacts. Label each diagnostic with its own unit and definition.
Suppose a hypothetical account completes setup with an agent’s help. If the outcome is “usable setup confirmed”, the support record may establish it even without a product completion event. If the outcome is “self-service task completed”, it does not. The customer history is the same; the agreed question determines the count.
Dashboard settings can change a displayed rate. In Amplitude Funnel Analysis, the conversion window is a parameter you can set. Check the chart settings against the written rule before sharing its figure.
Key Considerations for Dashboard Accuracy
- Conversion Window in Amplitude Funnel Analysis
- A configurable parameter that affects displayed rates
- Same Customer History, Different Outcomes
- Depends on agreed question — e.g., self-service vs. agent-assisted setup
- Unresolved Exceptions
- Should remain visible, not forced into success or failure
Resolve disputes and changes
Review boundary cases such as a multi-user account, an assisted completion, a late event, a sales-led deal and a reopened support issue. Record the classification and reason.
The metric owner publishes the agreed definition; the source owner investigates a faulty record. Keep unresolved cases visible rather than forcing them into success or failure.
When the definition changes, set an effective date and mark the reporting break. Recalculate earlier periods only if the source records support the new rule. A rate can move because its definition changed even when customer behaviour did not.
State what the metric can claim. An outcome recorded after a journey message shows sequence, not that the message caused it. Assessing the journey’s added effect requires a suitable comparison.
Pros and Cons of Using Assisted Outcomes in Lifecycle Metrics
- Pros
- Captures real-world user behaviour; accounts for support-led completions
- Cons
- Can introduce ambiguity if not clearly defined; may complicate cross-team alignment
