Lead and Contact lifecycle design

A person fills out a form, takes a sales call, changes jobs, opts out of marketing, and may buy from you twice. Teams often cram all of that into one field called Lifecycle Stage or Lead Status. The field eventually means different things to Marketing, Sales, and reporting, so handoffs and funnel numbers stop agreeing.

This page gives you a way to design the person lifecycle before you automate it. By the end, you should be able to choose a Lead and Contact model, write a lifecycle contract that a team can review, and trace one person through it without losing the rest of their story.

A person lifecycle is a business relationship model

A person lifecycle answers one question: what is this person's current commercial relationship to us? It should describe a change in that relationship using evidence your business can point to.

CRM objects, marketing scores, and sales task queues can store parts of the model. Your business defines the relationship they represent.

Keep these dimensions separate:

Dimension	Question it answers	Example value
Person lifecycle	Where is this person in their relationship with us?	Sales-ready
Consent	May we send a particular type of communication?	Marketing opted out
Employment	Does this person still work at the company we recorded?	Former employee
Fit	Does the person or their company match the market you want to serve?	Outside target segment
Work status	What is someone doing right now?	Discovery call scheduled
Ownership	Who is accountable for the next action?	Assigned to Sales
Account relationship	What is the company's relationship with us?	Customer
Opportunity or Deal stage	Where is a specific potential purchase?	Evaluation

One person can be a Sales-ready contact, opted out of marketing, employed at a customer Account, and associated with an Opportunity in evaluation. Those statements do not conflict. Collapsing them into one status does.

The existing AI Context material uses lifecycle migration for a reporting population moving between CRM objects. See the Salesforce example and HubSpot example for that separate implementation problem.

Choose the person-record model on purpose

Start with the companion CRM entities page. It defines the records. This decision defines when a person lives on which record and what that movement means for identity, history, and reporting.

There is no universal Lead and Contact model. These are all legitimate when their rules are written down.

Lead-first model

Use a Lead record for an early, unqualified person. Convert or associate the person to a Contact once your business has enough evidence to manage an ongoing relationship. This model can keep low-confidence intake separate from operational people records.

The trade-off is reporting and duplicate complexity. You need a matching rule, a conversion trigger, a policy for existing Contacts, and a report design that follows the person across the boundary. A platform conversion event is record movement. It is not proof that the person progressed in the business lifecycle.

Contact-first model

Create a Contact as soon as you recognize a person, then use a lifecycle field and related activity to show the relationship. This can make identity and reporting simpler when most people remain useful records after their first interaction.

The trade-off is volume. You need rules for imports, duplicates, low-quality records, and when a Contact is eligible for Marketing or Sales work. A Contact record alone is not evidence of qualification.

Separate sales-work model

Keep the person on a Contact or Company record, then use a separate Lead record or work item to track a specific qualification effort. This fits businesses where the same person can have more than one buying motion or product interest.

The trade-off is coordination. Define how the sales-work record relates to the person lifecycle, which record supplies each report, and who closes or reopens the work.

Pick the smallest model that preserves the business questions you need to answer. If you cannot explain what happens when the same person returns six months later, the model is not ready for automation.

Write the lifecycle contract before building fields

Stage labels are not a lifecycle. Every stage needs a contract that tells a human, workflow, report, and future AI system what the label means.

This lifecycle contract becomes the person-lifecycle section of the Business Truth Map, the shared operating document for entities, lifecycles, fields, ownership, and unresolved questions.

Contract field	What to document
Meaning	The plain-language relationship the stage describes
Entry evidence	The observable event, field, or reviewed decision that permits entry
Owner	The person or team accountable while the record is in the stage
Milestone date	The deliberate event date used in reporting
Valid exits	The next stages or outcomes that make sense from here
Recycling or decay	What re-engagement or inactivity changes, and what it does not change
Exceptions	Missing evidence, duplicate identity, disputed fit, or an explicit review path
Reporting treatment	Which population the stage belongs in, which date reports use, and what is excluded

The milestone date deserves more attention than it gets. A current stage tells you where a person is now. A milestone date tells you when a defined event happened. Last modified is not a substitute. Imports and automations can change it without changing the relationship you are measuring.

Choose history behavior explicitly:

• First entry: keep the first time someone reached a stage. Use this when the question is when the relationship first became true.
• Latest entry: update the date when someone re-enters a stage. Use this when the question is how long the current pass has been open.
• Transition history: store each stage change with its evidence, writer, and time. Use this when you need to explain recycling, measure repeated attempts, or audit an automated transition.

You may need more than one of these. The right choice follows the reporting question, not a platform default.

GTM Lab: a worked person lifecycle

The stage names below are worked choices for a fictional B2B software company. They show the contract. Adapt the criteria to the relationship your business needs to track. The company sells to mid-market manufacturers. Acme Manufacturing is an Account in the CRM, and Priya Shah is a person who first appears through an inbound request.

Worked stage	Meaning and entry evidence	Owner and milestone	Valid exits
Known person	Priya is identifiable and her record can be matched to Acme. A form fill alone may create this record.	Marketing Operations records known_person_at.	Engaged, duplicate resolution, or a documented invalid-record outcome
Engaged	Priya requests a product walkthrough after downloading the guide. The walkthrough request is the worked entry signal.	Marketing owns the next action and records engaged_at.	Sales-ready, Recycled, or an approved disqualification reason
Sales-ready	Priya confirms an active operations project, Acme fits the worked account criteria, and Sales accepts the documented review.	Sales owns the next action and records sales_ready_at after acceptance.	Continued sales work, Recycled, or a documented disqualification reason
Recycled	The current sales or marketing motion ended without a present path forward, while the identity and prior history remain.	The agreed returning team records recycled_at and a reason.	Engaged after defined new evidence, or an approved terminal outcome

Priya can reach Sales-ready while Acme is still a prospect and an Opportunity does not yet exist. If Sales later opens an Opportunity, that deal gets its own stages and dates. If Priya opts out of marketing, her consent changes. The person lifecycle does not automatically become Recycled or disqualified.

A handoff is more than an owner-field update

For the worked Engaged to Sales-ready transition, the event is not complete when a workflow assigns Priya to a rep. The receiving team needs a usable handoff.

Handoff part	Worked choice for Priya
Trigger	The agreed qualification evidence is present
Sender	Marketing, with the evidence and recent interaction context
Receiver	The named Sales owner or queue
Acceptance	Sales accepts, rejects with a reason, or routes the record to an exception queue
Completion evidence	Acceptance timestamp plus the current accountable owner
Failure path	Missing evidence or a rejected handoff returns to the agreed review owner without erasing history

An MQL score can be useful evidence. It does not authorize a Sales handoff by itself unless the people who own the process agreed that it does and documented the rule.

Recycling and decay preserve history

Recycling means the current motion ended. It should not erase a person, pretend their earlier stage never happened, or quietly change consent and fit. Decay is one possible trigger for recycling: after an agreed period without the evidence needed to keep the current stage, a review or workflow moves the person to Recycled and records why.

Use an explicit re-engagement rule. In the GTM Lab, a new qualifying interaction can move Priya from Recycled to Engaged; it does not overwrite engaged_at from the first time unless the reporting contract says to maintain a separate latest-entry date.

Salesforce mechanics to account for

Salesforce has separate Lead, Contact, Account, and Opportunity records. Its Lead-conversion behavior creates or associates an Account and Contact, and can optionally create an Opportunity. The platform can also match existing records. Its conversion considerations cover the configuration and automation details that can change or block that path.

Treat conversion as a documented record-handling event. Decide separately whether it also changes the person lifecycle, which identity wins on a match, where history is reported, and how an unconverted Lead relates to a converted Contact. Converted Leads become read-only and can still be relevant to Lead reporting, so do not write reports that assume conversion deletes their history.

Salesforce also keeps Lead Status and Opportunity Stage separate. Lead Status is a configurable pre-sales status; Opportunity Stage describes a deal. The platform's Lead implementation guidance and picklist documentation make that distinction explicit. Neither label replaces a business-owned person lifecycle contract.

HubSpot mechanics to account for

HubSpot separates Contacts, Companies, Deals, and Leads in its object model. A Lead is a separate sales object used for qualification work associated with a Contact or Company; the current Lead documentation describes both Contact and Company leads.

HubSpot's Lifecycle stage is a Contact and Company property. It is distinct from the Lead object's pipeline stage and from Deal stage. Lead Status is also a Contact or Company property, used as a sub-status within the sales-qualified portion of the lifecycle. HubSpot documents these boundaries in its lifecycle-stage guidance and Lead-pipeline automation guidance.

HubSpot can automate lifecycle updates and synchronization among associated records. Those behaviors are configuration choices. The documented default automation moves Lifecycle stage forward; moving a record to an earlier stage through HubSpot tools requires clearing the current value first. Read the current lifecycle synchronization documentation before you depend on it. Your business still needs to decide whether a Company should change a Contact's lifecycle, how associations affect reporting, and what a reopened sales motion means.

Lifecycle design audit

Run this review before putting a lifecycle rule into a workflow, dashboard, or AI context entry.

• Each person stage has a plain-language meaning, observable entry evidence, accountable owner, milestone date, valid exits, and reporting treatment.
• Consent, employment, fit, work status, ownership, Account relationship, and Opportunity or Deal stage live in separate fields or clearly separate models.
• The Lead and Contact model documents matching, duplicate handling, conversion or association behavior, and the reporting path across record boundaries.
• Handoffs name the sender, receiver, required context, acceptance or rejection behavior, exception path, and completion evidence.
• Recycling and decay preserve identity and transition history. Re-entry behavior is stated for every reporting-significant stage.
• Each stage's first-entry, latest-entry, and transition-history choices match a real reporting question.
• Stakeholders from Marketing, Sales, Customer Success, Operations, and reporting have reviewed the definitions they rely on.
• Unresolved questions are visible with an owner and review date. They are not hiding in a picklist value or workflow branch.

Once you have this contract, capture the supporting field meaning, source, freshness, and write behavior in a field dictionary. The existing CRM AI context overview and rule schema show why downstream systems need those details. When an answer crosses Lead, Contact, Account, or Opportunity records, use a documented relationship path. Otherwise you get the same quiet reporting gaps that cause wrong CRM AI answers.