Separate the objects
A person, account, and opportunity can be in different states at the same time. An existing customer can open a new expansion opportunity, and a new contact can belong to that customer account. Avoid overwriting one object with another object’s meaning.Define and implement the state model
- Write each state’s meaning. Specify the object, entry evidence, owner, and allowed next actions. Use the fewest states that support distinct operational decisions.
- Explain what moves a record to the next stage. Record the event, prerequisite, responsible system, timestamp, and behavior for missing evidence. Decide whether regression is allowed and how reactivation is represented.
- Preserve history. Keep stage-change events or equivalent auditable history for cohort analysis. A current-stage field cannot reconstruct time spent in prior states by itself.
- Agree which tool or person can change the record. Document which workflows, integrations, imports, and users may change each field. Set precedence so a stale import cannot silently undo a valid customer transition.
- Test exceptional paths. Include skipped stages, duplicate merges, lost opportunities, existing customers, reopened evaluations, and deleted or suppressed contacts. Platform defaults may constrain backward movement or automation.
- Migrate with reconciliation. Map old states to new definitions, keep a recoverable export, preview affected records, and review exceptions. Do not force ambiguous historical data into a confident new label.
Worked example
A fictional company defines an accepted inquiry as one reviewed by a responsible team and suitable for a next conversation. Downloading a report alone does not enter that state. A contact at an existing customer may request a new product evaluation without changing the account back to “lead.” The new opportunity tracks the expansion process. Contact communication eligibility remains a separate property, so lifecycle status cannot override an unsubscribe request.Transition contract
Audit the result
Sample records from every transition and compare them with actual conversation or transaction evidence. Monitor unexpected reversals, missing timestamps, and competing updates. If teams disagree on what a state means, resolve the definition before adding more automation or dashboards.Try it with your own work
Choose one stage that causes disagreement. Ask both teams what must have happened before a record enters it, then compare their answers with a few actual records.Sources and scope
- HubSpot: lifecycle stages illustrates contact/company stage behavior in one CRM; design and test your own transition rules rather than assuming identical platform behavior.
What to read next
CRM data model · Routing and SLA · Lifecycle email Chapter guide · All playbooksCopyright © 2026 Ivan Xu. All rights reserved. See the copyright and reuse terms. Canonical source: github.com/weilun88313/B2B-Playbook