Lifecycle Stages Are Not One-Size-Fits-All

Every CRM comes with a default set of lifecycle stages. Subscriber, Lead, MQL, SQL, Opportunity, Customer. Most companies never change them. They treat them as fixed categories, tick the box during implementation, and move on.

Then six months later they wonder why their pipeline reports do not match reality, why "Customer" includes three completely different types of relationship, and why nobody trusts the data in the CRM.

The problem is not the CRM. The problem is that lifecycle stages were designed as revenue architecture, and most companies treat them as a dropdown field.

The Default Stages Work for Simple Businesses. Yours Probably Is Not Simple.

If you sell one product to one type of buyer through one motion, the default stages are fine. A contact comes in, gets qualified, enters a deal, closes, becomes a customer. Linear. Clean.

But most businesses are not that simple. Consider a SaaS company selling to both end users and channel partners. The lifecycle of a direct customer and the lifecycle of a reseller are fundamentally different journeys. A partner does not go through MQL and SQL. They go through identification, vetting, onboarding, activation, and ongoing enablement. Putting both through the same lifecycle funnel gives you a number that means nothing.

Or consider a marketplace business with multiple constituent types. You might have suppliers on one side, buyers on the other, and intermediaries facilitating the transaction. Each of those groups has a different relationship with you, a different onboarding process, and a different definition of "active." Labelling them all as "Customer" the moment they sign up tells you nothing about where they actually are.

This is not an edge case. Multi-product companies, platform businesses, franchise models, financial services firms with multiple stakeholder types, they all hit this problem. The default stages cannot represent the complexity of their actual business model.

Contacts and Companies Are Not the Same Thing

Here is something that trips up almost every CRM implementation I work on. The lifecycle stage of a contact and the lifecycle stage of the company they belong to will almost never match.

A company might be an active customer. But a new contact at that company might be completely unknown to you. They need onboarding, training, maybe even a discovery conversation. If you inherit the company's lifecycle stage onto every contact automatically, you lose visibility into who actually needs attention.

The reverse is also true. A champion contact might leave the company. The company is still a customer, but your key relationship just walked out the door. If you are only tracking lifecycle at the company level, you have no way to flag that.

In HubSpot, this is a common pitfall. The default lifecycle stage property exists on both contacts and companies, but most setups either sync them blindly or only update one. The result is that your contact-level reporting and your company-level reporting tell different stories, and neither is accurate.

The fix is to treat them as separate but related. Define what lifecycle stages mean at the contact level (this person's individual journey with us) and what they mean at the company level (this organisation's overall relationship status). Then use workflows to manage the relationship between the two, not to force them into alignment.

"Customer" Should Not Be the End of the Funnel

This is where most lifecycle stage designs fall short. They treat "Customer" as the finish line. Contact comes in at the top, progresses through the stages, closes a deal, becomes a customer. Done.

But for most businesses, what happens after the close is where the real revenue compounds. Retention, expansion, advocacy, referrals. If your lifecycle stages stop at "Customer," you have no structured way to track any of that in your CRM.

Winning by Design developed the bowtie model to address exactly this. Instead of a linear funnel that ends at closed-won, the bowtie opens back up on the right side. After the deal closes, the customer enters a new set of stages: Commit (they have signed but not yet started), Onboard (they are being set up and trained), Adopt (they are actively using the product), Expand (they are growing their usage or buying more), and Advocate (they are referring others).

This is not a theoretical framework. It maps directly to how post-sale teams actually operate. Your CS team is managing onboarding. Your account managers are driving adoption and expansion. Your marketing team wants to identify advocates for case studies and referrals. Without lifecycle stages on the right side of the bowtie, none of that is visible in the CRM.

I have worked with businesses where the post-close lifecycle is more important than the pre-close one. Think about a platform that onboards institutional partners. The deal might close in two weeks, but the onboarding, training, and activation process takes months. If "Customer" is the only stage after close, you have no way to report on where each partner actually is in that journey, no way to identify who is stuck, and no way to measure time-to-activation.

Multi-Constituent Businesses Need Multiple Lifecycle Models

Here is where it gets interesting. If your business has multiple constituent types, each with a different journey, you need to think about lifecycle stages per type, not one universal set.

Take a financial services platform as an example. You might have institutional lenders, borrowers, and intermediary partners. The lender lifecycle is about onboarding, compliance, and ongoing engagement. The borrower lifecycle is about application, underwriting, and servicing. The partner lifecycle is about activation, deal flow, and retention. These are three completely different journeys. Forcing them into the same lifecycle stage set produces data that is meaningless for decision-making.

Or consider an enterprise software company selling to end customers through a channel. Your direct customers have a lifecycle. Your channel partners have a different lifecycle. The end users who come through the channel have yet another lifecycle. Each needs its own stage definitions, its own progression logic, and its own reporting.

In HubSpot, you have a few options for handling this. You can use custom properties to create lifecycle stages per constituent type (e.g. "Partner Lifecycle Stage" alongside the default "Lifecycle Stage"). You can use the default lifecycle stage with custom values that accommodate multiple journeys. Or, if you are on Enterprise, you can use custom objects to model each constituent type as its own entity with its own pipeline and stages.

The approach depends on the complexity, but the principle is the same: do not force different journeys into one set of stages.

How to Design Lifecycle Stages That Actually Work

Start from the buyer journey, not from the CRM. Before you open HubSpot or any other tool, map out each constituent type and the stages they actually go through in their relationship with you. Not the stages you wish they went through. The real ones.

For each constituent type, answer these questions. What does "new" look like? What does "active" look like? What does "at risk" look like? What does "churned" look like? If you cannot answer those clearly, your lifecycle stages will not help you.

Then map those to your CRM. In HubSpot, some practical implementation notes.

Use workflow automation to progress lifecycle stages based on actual behaviour, not manual updates. A contact who submits a form and is assigned to a rep should automatically move from Lead to MQL. A deal that closes should automatically move the associated contact and company to the appropriate post-close stage. If your team is manually updating lifecycle stages, they will stop doing it within a month.

Build reporting around stage transitions, not just current state. The value of lifecycle stages is not just knowing where someone is. It is knowing how long they have been there, how quickly they moved through previous stages, and where they get stuck. Time-in-stage reporting is one of the most underused features in HubSpot.

Do not over-engineer it. Not every business needs 15 lifecycle stages. If a constituent type has a short, predictable journey, three or four stages might be enough: Identified, Onboarding, Active, Churned. The goal is clarity, not complexity.

The Reporting Payoff

When lifecycle stages are designed properly, your CRM becomes a genuine operating system for revenue. You can report on pipeline health by stage and constituent type. You can identify bottlenecks in onboarding. You can measure time-to-activation for new customers. You can see which partners are stuck in limbo and which are actively expanding.

When they are not designed properly, you get a CRM where "Customer" means everything and nothing, where your reports show numbers that nobody believes, and where every board meeting starts with fifteen minutes of caveats about data quality.

Lifecycle stages are not a setup task you do once during implementation. They are the foundation of how your CRM models your business. Get them wrong and every report, forecast, and automation built on top of them is working with bad inputs. Get them right and you have a system that tells you exactly where your revenue is, where it is going, and where it is stuck.