Customer Data Model
Prism Customer Success Handbook — Section 1.3
Why this page exists
Most CS documentation quietly assumes everyone means the same thing by "customer," "user," or "risk." This page removes that assumption. Every term used elsewhere in the handbook is defined here once, and mapped to where it actually lives in the CSP.
Two ambiguities this page exists to kill:
- "Customer" is ambiguous for this product. Prism's accounts have their own clients, and those clients appear inside Prism as workspaces. Without discipline, "customer" could mean the firm that pays us or the firm they serve.
- "Risk" means three different things — a health band, a lifecycle state, and a playbook name.
Core rule on terminology
"Account" is the only term for the entity that pays us. "End client" is the only term for their clients. The word "customer" is avoided as a standalone term throughout this handbook.
Applied to a worked example: Fountain is an Account. Bojangles is one of Fountain's end clients, represented in Prism as a client workspace. Bojangles is not our customer, is never a Contact, and is never engaged by the CSM.
Entities
Commercial
| Term | Definition | Lives in CSP as |
|---|---|---|
| Account | The company that holds the contract with Prism. The unit everything else hangs off. | accounts table |
| Segment | SMB / Mid-Market / Enterprise. Assigned by ARR band with a support-and-motion overlay (see 1.2 CS Operating Model). Determines coverage motion and health weighting. | accounts.segment |
| ARR | Annual recurring revenue for the account. | accounts.arr |
| Renewal date | Contract anniversary. All contracts are annual. | accounts.renewal_date |
| Seats | Commercial entitlement — how many logins the account purchased. Distinct from Users (how many actually exist). The gap between them is itself an adoption signal. | Not yet modeled |
| Forecast category | Commit / Likely / At Risk / Unknown. A CSM judgment call, deliberately not derived from health — it folds in things the data model can't compute (competitive pressure, sentiment, procurement friction). See 2.6 Renewal Forecasting. | accounts.forecast_category |
| Expansion opportunity | A recurring commercial process, not a state or a stored flag. Tracked via the Expansion Opportunity playbook and activity records. | Playbook record |
People
Three distinct person-type entities. Conflating them causes real errors in playbook language.
| Term | Definition | How we know | Lives in CSP as |
|---|---|---|---|
| User | A provisioned login at the Account. Someone who actually uses Prism. May be someone the CSM has never spoken to. | Product data: email, role, last active | Not yet modeled |
| Contact | A CS relationship record — a person we have or want a relationship with. May not be a User at all (an executive sponsor who never logs in is a Contact, not a User). | CRM / CS work | contacts table |
| End-client viewer | Someone at an end client with portal access. Not our customer, never a Contact, never engaged by the CSM. Counted, never contacted. | Portal telemetry | Portal access records (not yet modeled) |
Contact roles:
| Role | Definition |
|---|---|
| Champion | The internal advocate who drives Prism forward and defends it internally. Loss of a champion triggers the Champion Departure playbook. |
| Executive sponsor | The budget-holder or senior leader whose support secures renewal. Frequently not a User. |
| Stakeholder | Any Contact with influence over the relationship. Champions and executive sponsors are stakeholder subtypes. |
Multi-threading — the number of distinct Contacts we have live relationships with, judged relative to segment. Single-threaded accounts are a known churn risk and score poorly in Stakeholder Engagement.
Product-side
| Term | Definition | Lives in CSP as |
|---|---|---|
| Client workspace | A container inside Prism for one end client's dashboards and reports. Created by the Account. | Not yet modeled |
| Adoption milestone | One of four standardized checkpoints on the path to value: Connected → Built → Live → Recurring. See 1.7 Success Plans. | Not yet modeled |
| Module | Connect, Studio, Portal, Scheduler, Insights. See PRODUCT_ONE_PAGER.md. |
Not modeled |
Data visibility norm: the CSM sees workspace metadata — count, activity, portal logins, delivery success — never report contents. An Account's end-client data is not ours to browse. This is a deliberate practice boundary, not a technical limitation.
What we cannot see: an Account's total client book. We know the end clients that exist in Prism; we are blind to the ones that don't. This is why adoption "breadth" was rejected as a health component (see 1.6 Health Scoring Methodology).
Health & state
This is where the "risk" collision gets resolved. Three different things share the word.
| Term | What it is | Values | Lives in CSP as |
|---|---|---|---|
| Health score (composite) | A 0–100 number: category scores × segment weights. Answers "how is this account doing?" | 0–100 | health_snapshots.composite_score |
| Health band | A named range of the composite score. "At Risk" here is a score range (20–39), nothing more. | Healthy / Stable / Watch List / At Risk / Critical | Derived from composite |
| Health category | One of four scored inputs: Product Adoption, Support Experience, Stakeholder Engagement, Success Plan Progress. | 0–100 each | health_snapshots.* |
| Lifecycle stage | Where the account is in its journey. Linear, traversed once. | Sales Handoff / Onboarding / Adoption / Value Realization | Not yet modeled |
| Lifecycle state | The account's current condition. "At-Risk" here is a condition, not a score range. | Healthy / At-Risk / Churned (terminal) / Advocate (overlay) | Partially — see below |
| Risk Level | A deliberately separate signal answering "how many risk playbooks are compounding, and has one been escalated?" Not a health input. | Stable / Elevated / Compounding / Critical | Computed via riskRollup.ts |
| Account status | Active or churned. The concrete implementation of the Churned terminal state. | active / churned | accounts.status |
Disambiguating "risk" in one line each:
- At Risk (health band) = a score between 20 and 39.
- At-Risk (lifecycle state) = a condition an account enters when composite falls below Stable or any risk playbook is active.
- Risk Level = how many risk playbooks are stacking up right now.
- Renewal Risk = the name of one specific playbook.
An account can be in the At-Risk state without being in the At Risk band — Brightpath is exactly this: composite 63 (Stable band) but At-Risk state because a Low Adoption playbook is active.
Work records
| Term | Definition | Lives in CSP as |
|---|---|---|
| Activity | A logged interaction or event: call, email, meeting, note, stakeholder change, escalation opened/resolved, status change. Append-only. | activities table |
| Playbook | A structured response to a trigger, instantiated on an account with a fixed set of tasks. | playbooks table |
| Playbook task | One step within an active playbook, individually completable. | playbook_tasks table |
| Escalation | An explicit CSM judgment that an account needs elevated attention. Event-backed — sets a flag and writes an activity. Always overrides computed Risk Level to Critical. | playbooks.escalated + activity |
| Success plan | A per-account document of customer-stated goals, owners, and target dates. Mid-Market and Enterprise only — SMB follows the standardized milestone path instead. See 1.7 Success Plans. | Not yet modeled |
| Health snapshot | A weekly point-in-time record of an account's category and composite scores. Append-only history, so trend (not just current value) can drive triggers. | health_snapshots table |
Not yet modeled — v2 scope
Terms defined above that the CSP has no field for today. All logged in BUILD_BACKLOG.md:
- Lifecycle stage (enum) and Advocate flag
- Users, Seats, and the seats-vs-users gap
- Client workspaces and end-client portal access
- Adoption milestones as tracked records
- Success plans as structured records
- Raw signal storage (currently signals exist only as computed values on health snapshots)
The handbook deliberately runs ahead of the software here. See the working rules in HANDBOOK_SKELETON.md.
Related pages
- 1.2 CS Operating Model — segment definitions
- 1.4 Customer Lifecycle — stages, states, and processes
- 1.6 Health Scoring Methodology — categories, bands, transition rules
- 1.7 Success Plans — milestones and plan structure