Account lifecycle design: define the company relationship

An Account can be a target before anyone at the company engages, a customer while a new deal is still open, and a former customer after the ending event its contract defines. When those facts get collapsed into a Contact's lifecycle or an Opportunity stage, reports start telling a story that isn't true. This page helps you define the company's commercial relationship with your business, including customer loss and reactivation. The result is an Account lifecycle your teams can use without overwriting the people, deals, or other facts attached to that company.

An Account lifecycle answers one question

An Account lifecycle describes the company's commercial relationship with your business over time. In HubSpot, the corresponding record is usually called a Company. It answers questions such as:

• Are we intentionally pursuing this company?
• Do we have an active customer relationship?
• Did that relationship end?
• Has the company become active again?

It does not answer every useful question about the Account. Keep these dimensions separate:

Dimension	Question it answers	Example
Account lifecycle	What is the company's commercial relationship with us?	Customer
Person lifecycle	What is this person's relationship with us?	Priya is Sales-ready
Opportunity or Deal stage	Where is one transaction in its sales process?	Expansion deal is in Discovery complete
Work status	What work is someone doing now?	Renewal review is waiting on Finance
Relationship health	How healthy is the current relationship?	Renewal risk needs review
Fit	Is the company a match for the motion?	Fits the target segment
Ownership	Who is accountable for the work now?	Customer Success owns the relationship
Employment	Does a person still work there?	Priya changed employers
Consent	Which communications may this person receive?	Marketing email opt-out

Acme Manufacturing can be a Customer while Priya has left the company, an expansion Opportunity is still open, and a customer-success owner has flagged renewal risk. Each statement can be true at once. None should overwrite the others.

For the record model underneath this page, start with the companion CRM entities page. The person lifecycle page covers the separate question of how an individual relationship changes.

Pick a model your business can explain

There is no universal Account lifecycle. The right model depends on what a company relationship means in your business and which evidence you can maintain reliably.

Model	How the Account state changes	Useful when	Watch for
Company-led	A documented company event changes the state	You sell to buying groups or manage customer relationships at the company level	One engaged person should not automatically promote the whole company
Person-derived	Defined signals from related people roll up to the Account	A named person relationship is the clearest early proof of account interest	The rollup rule needs a clear population, time window, and exception path
Transaction-derived	An Opportunity or Deal event changes the Account state	Customer status is best proven by a completed commercial transaction	A late-stage deal is not the same as an active customer relationship
Explicitly maintained	A named team changes the state after reviewing evidence	The relationship is complex, high-value, or hard to infer safely	A manual field without an owner or review cadence decays fast

Most teams use a mix. For example, a company can become a Prospect from a reviewed person-level signal, a Customer from the defined commercial event, and a Former customer after the customer team confirms the relationship has ended. The important part is not choosing the cleverest model. It is writing down which event changes which state, who may make that change, and what happens when the evidence conflicts.

Operating choice: Do not make "someone booked a meeting" mean both "this person is engaged" and "this company is a qualified prospect" unless your team has deliberately chosen and documented that rollup.

Write a contract for every stage

A stage label is not a lifecycle design. Customer is only useful when everyone can say what it means, how it starts, and what makes it stop being true.

Contract field	What to document
Meaning	The plain-language commercial relationship the stage describes
Entry evidence	The observable event or reviewed decision that permits entry
Owner	The person or team accountable while the Account is in the stage
Milestone date	The deliberate event date reporting will use
Valid exits	The next states or outcomes that make sense from here
Reactivation or regression	What new evidence can reopen a relationship, and what history stays intact
Reporting treatment	Included population, exclusions, and the date a report should use
Exceptions	Missing evidence, disputed status, mergers, duplicate companies, or a review path

The evidence should match the claim. A rep's interest in an Account can support a prospect motion. It does not prove that the company is a customer. A closed deal can be relevant evidence, but you still need to decide whether the business event you report is the deal closing, service beginning, a customer-team confirmation, or something else.

Customer loss and reactivation need their own rules

Customer status gets stale when there is no defined exit. If the commercial relationship ends, record the event, reason, owner, and date that moved the company to its former-customer state. Do not erase its customer history or rewrite the first customer date.

Reactivation is also a separate event. A new purchase, renewed agreement, or another approved commercial signal may return a former customer to Customer. Decide whether reports need the original customer date, the latest activation date, every transition, or more than one of those. Last modified cannot answer that question because any unrelated edit can change it.

GTM Lab: Acme Manufacturing

The GTM Lab is a fictional B2B software company that sells to mid-market manufacturers through inbound, outbound, and expansion motions. Acme Manufacturing has an existing Contact, Priya Shah, a new-business Opportunity, and later an expansion Opportunity. Those records are related, but they do not share a lifecycle.

This is a worked example, not a recommended universal taxonomy.

Worked stage	Meaning and entry evidence	Owner and milestone	Valid exits
Target	Acme fits the documented market definition and is intentionally in scope. This does not claim that a person is engaged.	Revenue Operations maintains the segment logic and records targeted_at.	Prospect, a documented out-of-scope outcome, or review
Prospect	The agreed company-level evidence supports active pursuit. In this example, the evidence is a reviewed relationship signal, not any single form fill.	Sales owns active pursuit after accepting the documented handoff and records prospect_at.	Customer, Recycled, or review
Customer	The defined commercial relationship is active. The team records the agreed activation event and customer_since_at.	Customer Success owns the relationship.	Former customer, continued customer relationship, or review
Former customer	The defined commercial relationship ended, while prior customer history remains. A documented ending event and reason are required.	Customer Success records former_customer_at and the approved reason.	Customer after reactivation, or review
Recycled	The present prospecting motion ended without a current commercial relationship. This is not a customer-loss label.	The returning team records the reason and recycled_at.	Prospect after new approved evidence, or review

Priya can become Sales-ready without changing Acme from Target to Prospect. Likewise, an expansion Opportunity can move forward while Acme remains a Customer. If Priya opts out of marketing or changes employers, update consent or employment. Do not use either fact to rewrite Acme's customer relationship.

Two traces that should produce different results

Trace one: a new sales motion. Priya responds to outreach and Sales opens a new-business Opportunity. Acme becomes a Prospect only when the documented company-level entry rule is met. The Opportunity follows its own stage model. Acme does not become a Customer because a deal is open.

Trace two: a former customer returns. Acme's earlier customer relationship ended and was recorded as Former customer. Later, a new commercial event meets the reactivation rule. Acme returns to Customer, keeps the original customer history, and records the new activation event. The new Opportunity and Priya's person lifecycle retain their own history.

That separation is what makes customer counts, reactivation reporting, and account history explainable later.

What Salesforce changes, and what it does not

Salesforce provides an Account record and a standard Type field. The platform's Account fields documentation describes Type as an administrator-configured classification, with values set by the organization. It is not a Salesforce-prescribed Account lifecycle.

You can use Type, a custom field, record types, related records, or a combination to implement your model. That is an implementation choice. Before configuring it, decide which field carries the current state, which evidence creates transition history, who may change it, and how reports distinguish a current customer from a former one that may return.

Salesforce Opportunity stages are separate from Account state. Its Opportunity field documentation describes Stage as required and administrator-defined, with mappings to forecast category and probability behavior. An Opportunity moving stages does not define your company relationship unless you explicitly design a rule that uses the documented commercial event as Account-lifecycle evidence.

What HubSpot changes, and what it does not

HubSpot uses Company for the company record. Its lifecycle-stage guidance and customization documentation describe lifecycle stages that administrators can customize for Company and Contact records. The available labels do not decide what your company relationship means.

HubSpot can also apply configured lifecycle automation between associated records. Its synchronization documentation describes optional primary-Company-to-Contact behavior. Documented automated behavior moves lifecycle forward; moving a record to an earlier lifecycle stage through HubSpot tools requires clearing the current value first. That is a platform behavior, not a business rule. Decide whether you want the synchronization at all, which Company relationship can affect which Contacts, and how an Account reactivation should appear in reporting.

HubSpot Deals have their own configurable pipeline stages and probabilities. The pipeline documentation keeps those stages separate from the Company lifecycle. Treat a Deal outcome as evidence your Account contract may use, not as a universal replacement for the contract.

Account lifecycle template

Use this table in your Business Truth Map before you configure a field, workflow, or report. The example values below are prompts for your team, not a taxonomy to copy.

Field	Fill in for each Account stage
Stage ID and label	Stable internal ID plus the name readers will see
Plain-language meaning	What the company's commercial relationship is now
Business purpose	Why this state exists and which decision it supports
Entry signal and evidence	The event, field, or reviewed decision required for entry
Current owner	Person or team accountable while the Account is here
Entry milestone	Event date, writer, first/latest/history behavior, and report use
Valid exits	Permitted next stage, closure, recycle, or review path
Customer-loss or reactivation rule	What changes the relationship and what history must remain
Related dimensions	Person lifecycle, deal stage, work status, health, fit, consent, and ownership fields that remain separate
Reporting treatment	Included population, exclusions, and definition used in each report
Exceptions and review	Ambiguous evidence, duplicates, mergers, disputed status, decision owner, and review date

Wrong choices that cause expensive reporting problems

Wrong choice	What breaks	Better rule
Mark an Account Customer when any associated Contact reaches a late person stage	The CRM reports customers without a commercial event and every related person appears to inherit the same relationship	Require the documented Account-level commercial evidence
Treat a late-stage or closed Opportunity as the Account lifecycle itself	Multiple transactions collapse into one status, so renewals, expansions, and reactivation become hard to explain	Keep the Opportunity or Deal stage separate and specify which event may affect the Account
Use Account Type as though Salesforce defined its meaning	A configurable classification becomes a false source of truth	Write the business definition, allowed values, writer, and reporting use before implementation
Sync every Company lifecycle update to every Contact	A company-level change overwrites person-level facts and creates bad handoffs	Choose any synchronization deliberately, with scope and exceptions
Use Last modified as the customer or reactivation date	Imports and unrelated edits distort customer-age and reactivation reporting	Store the deliberate event date and transition history your report needs
Leave former-customer status without an exit or reactivation rule	Current-customer counts drift and a returning company looks like a new logo	Define loss, reactivation, history preservation, and reporting treatment together

Account lifecycle audit

Run this review before using an Account state in automation, dashboards, or downstream context.

• The lifecycle describes the company's commercial relationship, not a person, deal, work status, health score, consent flag, fit assessment, employment fact, or owner.
• Each stage has a plain-language meaning, entry evidence, accountable owner, milestone date, valid exits, and reporting treatment.
• The model says how Customer, Former customer, and reactivation work where those states apply.
• The current state and transition history are both retained. First entry, latest entry, and every transition are chosen to answer real reporting questions.
• Every person-to-Account or Opportunity-to-Account rollup has a documented population, trigger, exceptions, and review owner.
• Salesforce Account Type, HubSpot Company lifecycle stage, and custom fields have a business definition before they feed a workflow or report.
• HubSpot lifecycle synchronization, if used, is intentional and does not stand in for a person-lifecycle or Deal-stage design.
• Customer loss, reactivation, duplicate-company handling, and mergers have a visible review path.
• Marketing, Sales, Customer Success, Finance, and Operations have reviewed the definitions they rely on.

Once this contract exists, document the fields that implement it: their meaning, writer, authority, freshness, and allowed use. The CRM AI context overview and context-layer rule schema show why a downstream system needs that information instead of inferring it from a field label. When a report or system crosses Account, Contact, and Opportunity records, keep the relationship path explicit. That is how you avoid the cross-object gaps behind many wrong CRM AI answers.