Lifecycle Stages

What the field records

A single current state for a contact or account. Its entire value comes from everyone reading it identically — a lifecycle field interpreted three ways by three teams is worse than no field, because it produces confident reports that disagree.

Three properties a working model has

1. Mutually exclusive. A record is in exactly one stage. Where two could apply, the entry criteria are wrong, not the record.

2. Evidence-based entry. Each stage has a criterion someone could check from the record itself. "Interested" is not a criterion; "requested a demo" is.

3. Directional by default. Stages progress one way, with reversal either forbidden or handled by a separate status field, so that time-in-stage means something.

Where stage models break

• Stages that describe internal handoffs rather than customer state. If a stage exists because a team needed a queue, it is a work state and belongs in a different field.

• Automation setting the stage on activity alone, so a record advances because it opened an email rather than because anything changed.

• The same field used for people and accounts, which produces contradictions the moment one account contains contacts at different stages.

• Stages added over years without any being retired, until nobody can state what distinguishes two adjacent ones.

Auditing yours

1. Ask three people to define each stage's entry criterion, separately. Divergence locates the problem precisely.

2. Count records that skipped a stage, and those that spent under an hour in one. Both indicate the model records data entry rather than process.

3. Check the terminal stages. Records that entered "customer" and later churned reveal whether you have a status field or a silent contradiction.

4. Compute conversion between adjacent stages on a creation cohort. Stages with near-100% conversion carry no information and are candidates for removal.