# Playbook: Lifecycle-Stage Orchestration
**School:** the HubSpot model — one canonical lifecycle-stage property (subscriber → lead → MQL → SAL → SQO → customer → evangelist), disciplined by Mark Roberge's "no automation without a stage-change contract" rule from scaling HubSpot sales 0→$100M. Stage vocabulary itself traces to the SiriusDecisions Demand Waterfall (Inquiry → MQL → SAL/SQO → Closed/Won).
**Deliverable type:** `journey-map` — this playbook produces the master journey-map that every other automation-spec in the system indexes into.
---
## When to use this
- More than one automation already exists or is planned, and you need a single spine that prevents them from firing in conflicting or overlapping ways on the same contact.
- You want a governance layer: no team member or agent can spin up a new automation without first stating which stage transition triggers it.
- You're building the foundational scaffold that lead-scoring-routing, speed-to-lead-sla, rfm-winback-engine, and plg-product-signal-crm all plug into (this is the spine, not a competing playbook — build this first, then layer the others on top).
## When NOT to use this
- You have exactly one automation and no plans for more — the overhead of a full canonical stage model may not be justified yet for a single email sequence. (Still worth sketching lightly, but don't over-engineer a one-automation shop.)
- Multiple teams insist on running their own competing "stage" definitions and won't consolidate — this playbook only works if there is genuinely ONE canonical property. Two lifecycle properties defeats the entire point (this is the HubSpot discipline's hard requirement, not a suggestion).
---
## Step-by-step build
1. **Name and order the canonical stages.** Standard spine: subscriber → lead → MQL → SAL → SQO → customer → evangelist. Adapt names to the business but keep exactly one property.
2. **Write objective entry criteria per stage.** Each stage transition must be system-verifiable — e.g., "SQO requires `lifecycle_stage = SAL` AND a discovery call logged AND a next-step field populated." Prose criteria ("when the lead seems ready") fail the gate.
3. **Inventory every automation touching the journey.** For each stage transition, list the automation-spec file that fires on it. This is the master index — nothing fires without appearing here.
4. **State the per-stage SLA where a human is involved.** The inbound stage (subscriber/lead entering) must state its SLA in minutes (this is where speed-to-lead-sla plugs in) — a missing minutes-stated SLA on the inbound stage is an explicit gate failure.
5. **Write the conflict rules.** What happens when two automations both target a contact at once (e.g., a winback sequence and a PQL nurture sequence both trigger in the same week)? State a priority order or a suppression rule — required field, not optional.
6. **Instrument a per-transition metric.** Each stage-to-stage move gets a tracked conversion rate (this feeds MANUAL §7.2's waterfall metrics and the Goodhart pairing in §7.7).
7. **Enforce "no automation without a stage-change contract."** Any new automation proposal must state which transition triggers it and get added to this journey-map's index before it ships — this is the governance mechanism, not a suggestion.
## Worked mini-example
Stages: subscriber (opted into list) → lead (submitted a form) → MQL (crossed scoring threshold, from lead-scoring-routing) → SAL (outreach-operator accepted) → SQO (discovery call logged) → customer (payment received) → evangelist (referred a new buyer or left a testimonial). Inbound stage SLA: "lead → first_touch within 5 minutes automated, 60 minutes human" (references the speed-to-lead-sla automation-spec by file). Conflict rule: "if a contact is simultaneously eligible for the rfm-winback-engine's reactivation track and a fresh PQL nurture, the PQL nurture takes priority for 14 days (fresher intent signal), then winback resumes." Per-transition metric: lead→MQL conversion tracked monthly, watched against a 3-month trailing average to catch a Goodhart-style definition drift.
## How the verify gate applies
The `journey-map` linter requires: named ordered stages with entry criteria per stage (system-verifiable, not prose); a trigger inventory listing every automation by spec-file reference; a stated minutes-based SLA on the inbound stage; explicit conflict rules for contacts targeted by more than one automation; and a per-transition instrumentation metric. Because this is the master spine document, it also indirectly enforces the "no automation without a stage-change contract" rule — any automation-spec that references a stage transition NOT present in this journey-map should be treated as a governance violation, not just a missing cross-reference.