Prism

Customer Lifecycle

Prism Customer Success Handbook — Section 1.4

Why three categories, not one list

A common failure mode in CS lifecycle docs is treating stages, states, and business processes as one flat sequence — which is how you end up with confused claims like "the customer is in the At-Risk stage" or "Renewal is the end of the lifecycle." Prism's model keeps three categories separate, because each answers a different question:

Category Question it answers Members
Stages Where is the customer in their journey? Sales Handoff → Onboarding → Adoption → Value Realization
States How is the customer doing right now? Healthy, At-Risk, Churned (terminal), Advocate (non-exclusive overlay)
Processes What business motion is currently occurring? Expansion, Renewal — recurring, both originate from Healthy

Stages are linear and (for a successful customer) traversed once. States describe condition and can change repeatedly without moving the customer to a different stage. Processes start, progress, and end, then return the customer to Healthy — they are not a place the customer permanently lives.

Customer Lifecycle

The model

flowchart TD
    A[Sales Handoff] --> B[Onboarding]
    B --> C[Adoption]
    C --> D["Value Realization (milestone)"]
    D --> H["Healthy (ongoing state)"]
    H -->|"recurring process"| E[Expansion]
    H -->|"recurring process"| R[Renewal]
    E --> H
    R --> H
    H -->|"risk signal"| AR[At-Risk]
    AR -->|"recovered"| H
    AR -->|"not recovered"| CH["Churned (terminal)"]
    H -.->|"overlay, non-exclusive"| ADV[Advocate]

Stages (Sales Handoff → Onboarding → Adoption → Value Realization) are crossed once, in order, on the way to becoming a Healthy customer. Value Realization is a milestone, not an ongoing condition: "the customer has demonstrably achieved the business outcome they purchased Prism to achieve" — concretely, per PRODUCT_ONE_PAGER.md, crossing adoption milestone 3 (first client live on the Portal). Once crossed, the customer doesn't keep "doing" Value Realization; they enter the Healthy state.

Healthy is the ongoing default state a customer occupies for the rest of a successful relationship, punctuated by recurring processes and occasional excursions into At-Risk.

Expansion and Renewal are recurring processes, not states. A customer isn't "in Expansion" for a quarter the way they're "in Onboarding" for their first month — expansion is a commercial motion (trigger → qualification → proposal → close) that starts, resolves, and returns the account to Healthy, now with a larger footprint. Renewal is the same shape on a fixed cadence: the relationship doesn't end there, it's the beginning of the next contract term.

At-Risk is a state, not a stage — a customer can cycle Healthy → At-Risk → Healthy multiple times across one contract without ever changing lifecycle stage. If recovery fails, the account moves to the one terminal state: Churned.

Advocate is a non-exclusive overlay, not a final stage. Most customers renew for years and never become one; some become one almost immediately after Value Realization. A customer can be Healthy + Advocate + mid-Expansion simultaneously — the categories are independent, which is exactly why they're modeled separately instead of forced into one line.

Mapping to what's already built

  • At-Risk state → Risk Level field. The CSP's existing Risk Level (Stable, Compounding, etc., built in Brief 10) is the concrete implementation of the At-Risk state described here. This page doesn't introduce a new concept — it gives the existing field its proper place in a larger model.
  • Churned state → account status field. The "Mark as Churned" workflow (Brief 12) already models churn correctly as an exit from either Healthy or At-Risk, with an event-backed activity log entry — consistent with this model, built before the model was formally written down.
  • Expansion and Renewal processes → existing playbooks. The Expansion Opportunity playbook and Renewal Risk playbook/Renewals View are the operational machinery behind these two processes. No new account attribute needed — they're tracked via activity and playbook records, not a static field.
  • Stages and Advocate → not yet modeled in the CSP. See gap below.

Gap this page exposes (logged, not built)

The CSP has no field for lifecycle stage (Sales Handoff/Onboarding/Adoption/Value Realization) and no Advocate flag. Every account today is implicitly treated as already-Healthy — reasonable for a seeded dataset representing an established book, but it means Onboarding and Adoption as stages exist only in this document, not in the software, until a future brief adds them. Logged to BUILD_BACKLOG.md, not building now.