HubSpot lifecycle stages look simple. One dropdown. Eight options. How hard can it be?
Hard enough that it's the single most misconfigured property in most HubSpot portals.
When your funnel reports don't match reality, when your "Customers" list is full of people who never bought anything, when leads vanish into the gap between marketing and sales, the cause traces back to this one field almost every time.
This guide fixes that.
You'll get the eight default stages and what each one actually means. The real difference between Lifecycle Stage, Lead Status, and Deal Stage. How the company-to-contact sync behaves (and where it bites). Why the MQL exists at all. And how to automate the whole thing without corrupting a single report.
Let's start with the basics.
A HubSpot lifecycle stage is a native CRM property that shows where a contact or company sits in your overall funnel, from first touch to closed customer.
It lives on both the Contact object and the Company object. And HubSpot's own framing says it best: it shows "where a specific contact or company is in your processes, and understand how leads are handed off between marketing and sales."
That last part is the whole point. Lifecycle Stage is a macro property, shared across marketing, sales, and service.
It should change only when someone crosses a real milestone.
Not when a rep leaves a voicemail. Not when someone opens an email. Real milestones.
Keep that in your head, because nearly every mistake in this guide comes from asking this property to do a job it was never built for.
There are eight default stages. Not seven. Eight.
And they run in this exact sequential order:
The order matters more than you'd think. Funnel reporting depends on sequential progression, so skipping or reordering stages breaks things downstream.
One housekeeping rule: these are a system property. You can't delete the defaults, but a Super Admin can add custom stages, rename them, and reorder them under Settings → Objects → Contacts → Lifecycle Stage.
And if you've ever built your own custom property to track "lifecycle"? Migrate off it. HubSpot recommends moving back onto the default property, because only the native one powers reports, automation, and the date stamps custom fields can't replicate.
Because the property sits on two objects, you have to decide how they talk to each other.
This is where teams get burned. So let's be precise.
The sync is one-directional: company to contact. Turn on "Sync lifecycle stages" and the primary company's stage pushes down to its associated contacts. It fires when a company is first associated as primary, and again whenever that primary company's stage changes.
Contact to company never happens automatically. In HubSpot's words: "updates to a company's Lifecycle stage value will update its associated contacts, but updates to a contact's lifecycle stage will not affect its primary company.
In other words, moving a contact will never change the associated company's lifecycle stage.
Only the primary company triggers the sync. A classic support ticket is a contact that won't inherit its company's stage. The usual cause? The company isn't set as primary.
And the sync still only moves forward. Set a company to Lead, and only contacts at a lesser stage (Subscriber) update. Anyone already at Opportunity stays put. Set the company to Customer, and every associated contact jumps to Customer.
That last behavior is the ABM landmine.
One company routinely holds Subscribers, Leads, MQLs, and SQLs at the same time. Auto-syncing the account's most advanced stage down to every contact is usually the last thing you want. Suddenly your reports think a dozen tire-kickers are Customers.
The fix most experienced practitioners use (Karsten Köhler in the HubSpot Community among them): leave company-to-contact sync off. Drive contact stages with contact-based workflows that include a filter layer, so only the right contacts ever influence the account.
More on how to build that in the automation section.
If your portal already feels shaky here, you're not alone. The company/contact sync is one of the first things we audit. Superwork untangles HubSpot lifecycle architecture for B2B teams every week. If your funnel data doesn't add up, get in touch with Superwork for a lifecycle and reporting audit.
Yes, but not the way you'd expect. By default, lifecycle stage only moves forward. To move it backward, you have to clear the value first, then set the lower stage.
Here's why that matters.
HubSpot's tools (imports, form submissions, the API, the Salesforce integration, workflows) will advance a stage but never regress it. HubSpot states it directly: "the default Lifecycle stage property can only be moved forward... You must clear the value manually or via a workflow before using these tools to set an earlier value."
So to drop an Opportunity back to Lead, you can't just set the lower value. You need two steps.
In a workflow, that's an "Edit record" action with "Clear existing property value" checked, followed by a second "Edit record" action setting the new, lower stage.
Manually? Clear the field. Then set it.
The mechanics are annoying. The damage to your reports is the real problem.
HubSpot maintains two generations of timestamp properties tied to lifecycle stage. Know the difference, and you'll save yourself a brutal afternoon.
Legacy "Became a [stage] date" properties. Became a Lead Date, Became an MQL Date, and so on. These are what your funnel reports actually read.
Newer calculated properties (Pro and Enterprise). "Date entered [stage]," "Date exited [stage]," "Latest time in [stage]," and "Cumulative time in [stage]" for every default and custom stage, on both contacts and companies. These power velocity analysis, like triggering a task when "Date entered Sales Qualified Lead" is more than five days ago.
Now the trap.
Set a stage to an earlier value manually, and the legacy "Became a [stage] date" for the higher stage gets wiped, while the lower stage's date gets populated. Clear the stage instead, and the most recent "Became a" date stays, but the calculated properties are not cleared on backward movement.
You cannot manually edit the "Became a" dates. At all.
That's exactly why regressions and skipped stages corrupt funnel reports in ways that are nearly impossible to fix later. Mistakenly bump someone from Opportunity to Customer, and they'll keep showing in the Customer stage of legacy funnel reports even after you "correct" it, because those reports read property history, not the current value.
Bottom line: decide your regression policy on purpose, write it down, and keep manual stage edits to a minimum.
This is the distinction that trips up the most teams. So memorize it.
These three properties answer three different questions:
Conflate any two of those three and you've got the most common HubSpot misconfiguration there is.
As one RevOps guide puts the trap bluntly: "Long story short: Lifecycle Stages = Lead Status. Except, of course, that's far from true."
So why do you need both Lifecycle Stage and Lead Status?
Picture a contact who's an SQL on Lifecycle Stage but "Attempted to Contact" on Lead Status. Lifecycle says "qualified." Lead Status reveals the truth: nobody's actually reached them yet.
One field gives you the funnel position. The other gives you the operational reality inside it. (Salesforce splits Lead Stage and Lead Status for the same reason.)
HubSpot officially calls Lead Status "the sub-stages within a Sales Qualified Lead lifecycle stage." Its defaults: New, Open, In Progress, Open Deal, Unqualified, Attempted to Contact, Connected, Bad Timing. Unlike Lifecycle Stage's locked defaults, Lead Status is fully customizable.
A quick honesty note: senior community contributors argue the "sub-stage" label is subtly wrong. The two properties differ in kind, not in nesting. In practice, Lead Status runs alongside lifecycle across the Lead, MQL, and SQL stages. You don't need to settle that debate to use them well. Just give each property one job.
The mistakes we see most:
Modern B2B buying is a committee sport. Lifecycle Stage is stubbornly individual.
That mismatch is real, and HubSpot has two features to model the committee. But here's the honest caveat first: no official HubSpot documentation reconciles either feature with Lifecycle Stage. What follows is practitioner guidance, not HubSpot doctrine.
Buying roles live on the hs_buying_role contact property. It's a multiple-checkbox default field with nine values you can't delete (you can add custom ones): Blocker, Budget Holder, Champion, Decision Maker, End User, Executive Sponsor, Influencer, Legal & Compliance, and Other.
Worth noting: HubSpot's KB only names three examples (Decision Maker, Budget Holder, Blocker). The full nine-item list comes from partners quoting the in-app text, so confirm the live list in your own portal before you promise it to anyone.
The catch? The native buying role property is flat and contact-level. It applies to that contact globally, across every deal they touch. To assign a role on one specific deal, you use a custom Contact-to-Deal association label, which is a separate feature. A HubSpot employee confirmed association labels are "an improvement on the ABM functionality for Buyer Roles, which applies to that Contact on all Deals," and that HubSpot is "working on bringing this functionality together in the future."
Buying Groups (Sales Hub Enterprise / Service Hub Enterprise, beta) is the native successor to OrgChartHub, which HubSpot acquired along with GeoMapper. It adds a Buying Group card to the company record with an org-chart visualization, committee blueprints, an AI auto-builder (for companies with fewer than 100 associated contacts), relationship mapping, an activity heatmap, and the ability to set a contact's buying role right inside the chart. Editing requires an assigned Sales or Service seat.
Availability, per a HubSpot employee: currently a Public Beta "available to all Sales Hub and Service Hub Enterprise customers," plus a Private Beta for Sales and Service Hub Pro customers. It's still beta and moving, so confirm tier availability in-app before building a client process on it.
So how do you reconcile committee buying with individual lifecycle stage when HubSpot gives you no native answer?
The practitioner playbook:
Almost none of the top-ranking articles on lifecycle stages cover this. If you run real ABM motions, it's also where the most expensive mistakes hide.
An MQL isn't a number. It's a handover mechanism.
It's the formal signal that says: "Marketing has done its job. Now a human in sales should engage."
HubSpot's own definition matches exactly: an MQL is "a contact or company that your marketing team has qualified as ready for the sales team."
An SQL goes a step further. It requires one-to-one human verification, where a rep has actually had a conversation and qualified fit and need against criteria like BANT.
See the MQL as a handover, and the obvious next question becomes: handed over to where?
Not in the deal pipeline. An MQL should land in an SDR-owned lead-management process, specifically HubSpot's Leads object and prospecting workspace.
Here's why the old way failed.
Historically, teams worked MQLs off the Lead Status property and filtered list views. Busy reps ignored those views. Data went stale. The handoff quietly broke.
HubSpot's answer is the Leads object and the prospecting workspace (Sales Workspace), available in Sales Hub Pro and Enterprise.
A Lead is a "pre-deal object." It's a many-to-one record tied to a contact or company that represents a single prospecting attempt. One contact can have several Lead records over time: cold for budget last year, re-engaged now. Each attempt keeps its own history instead of overwriting it.
It keeps the deal pipeline clean. Before the Leads object, reps created premature "pre-deals" just to track prospecting, which inflated the pipeline and wrecked forecasts. The Leads object handles the messy "will they, won't they" phase separately.
It automates the transitions reps always forget. The default lead pipeline runs New → Attempting → Connected → Qualified → Disqualified. HubSpot automatically moves a lead to "Attempting" on outreach (email, call, LinkedIn, meeting) and to "Connected" on a reply, booked meeting, or connected call. Those two transitions are set by default and can't be modified, which is exactly why they solve the "reps don't update statuses" problem.
You can auto-create a lead when a contact reaches a chosen lifecycle stage (MQL or SQL). And auto-create a deal when a lead reaches Qualified.
Lock this mental model in:
MQL → Leads object / prospecting workspace (SDR-owned) → Qualified → deal created → Opportunity (AE-owned deal pipeline).
The MQL lands in lead management. It does not land in the deal pipeline. That separation is what makes your forecast trustworthy.
The MQL-to-SQL handoff is where pipeline reliably leaks. And the leak is measurable across the whole funnel.
A 2025 compilation by Serpsculpt (drawing on Ruler Analytics, First Page Sage, and HubSpot data) puts average B2B conversion at roughly:
That ~13% MQL-to-SQL figure gets thrown around constantly and is often misattributed to HubSpot. It actually traces to Salesforce research (cited by SmartBug Media: "A typical, across-the-board benchmark for an MQL-to-SQL conversion rate is 13 percent, according to research from Salesforce") and to First Page Sage's analysis of client data from 2019 to 2025.
As Apollo's 2026 analysis frames it: "That means 87% of your 'qualified' leads never become sales opportunities."
The fixes are operational, not motivational.
1. Write the definitions down, and have both teams sign off. A shared, mutually owned MQL definition and SQL definition (use BANT for SQL) ends the "is this an MQL?" argument for good.
2. Set speed-to-lead SLAs. The evidence here is old but devastating:
3. Build a rejection-reason feedback loop. When sales rejects an MQL, make them code why (wrong size, no authority, bad timing). Then have marketing review the trends. Without this, marketing never learns what "good" looks like.
4. Measure marketing on SQLs and sourced pipeline, not raw MQL volume. Pay a team on MQL count and you'll get more MQLs, not more revenue.
5. Enforce it with "Time in Stage" properties. Notify the owner if a lead sits in "New" more than a day. Task the manager if it's been "Attempting" for seven days with no activity.
Designing, automating, and measuring this handoff is most of what a RevOps engagement actually delivers. If your MQLs go into HubSpot and never come out the other side, talk to Superwork about a lead-management and SLA build on the Leads object. It's the single highest-leverage fix for most B2B funnels.
Automation keeps your HubSpot lifecycle stages accurate at scale. The principle is simple: automate the mechanical transitions, keep the human judgments human, and never run a workflow without forward-only protection.
The natural automation points:
Manual setting is appropriate only for genuine human calls, like a rep confirming SQL after a real conversation. (And even then, the lead pipeline handles the mechanical parts.)
HubSpot's native settings live under Settings → Objects → Contacts → Lifecycle Stage → Automate:
Two caveats hide in that same panel: "these settings will not set the lifecycle stage of contacts backwards," and when a lead is created by automation, the lifecycle stage will not auto-update.
When a deal is created and associated with a contact or company, HubSpot can auto-move them to Opportunity. When the deal is won, to Customer.
But here's the catch: if a contact is already a Customer and a new deal is created, they will not regress to Opportunity.
Usually that's what you want. But it also means the native setting won't reflect "this customer now has a fresh active deal." Best practice: trigger the Opportunity update through a deal-based workflow on deal creation, instead of relying on the native setting or manual edits.
Stages skipping. A jump like Lead → Customer with no MQL, SQL, or Opportunity breaks funnel reports, which require sequential progression. Mitigate by marking intermediary stages "optional" in the funnel report (Pro/Enterprise), or by setting stages in order via workflow.
Stages going backward. As covered, this corrupts the "Became a" dates irreversibly. Legacy funnel reports read property history, so a corrected contact still lingers in the wrong stage.
Conflicting workflows. When marketing, sales, and service each run their own stage-setting workflow, they fight, and nobody trusts the data. Fix it with a single centralized "Lifecycle Management" workflow, or a small governed set.
Forward-only suppression on every workflow. This is non-negotiable. Add an enrollment filter like "Lifecycle Stage is none of [all stages higher than the target]" so your MQL workflow never fires for an existing Opportunity or Customer. Build this into every lifecycle workflow. No exceptions.
Lifecycle Stage spans the entire journey. Deal Stage tracks one pursuit, and a single contact can have several deals at different stages at once.
The golden rule practitioners like Six & Flow cite: if an action within a stage can be skipped, it shouldn't be a deal stage. It's a step within a stage.
So keep qualification detail in Lead Status and the Leads object. Keep the deal pipeline to genuine opportunities. Let the Opportunity lifecycle stage be driven by deal creation. And only split into multiple deal pipelines when the sales process genuinely differs (self-serve vs enterprise), not just because some deals feel different.
A few things to know before you show numbers to leadership:
No. A poorly defined MQL is dead. The concept survives wherever you tighten the definition, add SLAs, and measure SQL and sourced pipeline instead of raw MQL volume.
The 2026 shift is toward "Hot MQLs" and intent-based thresholds, and, for ABM-mature teams, toward buying-group and account-level qualification.
But not every org has the data maturity for full account-based qualification. For simpler, individual-led buys, the MQL is still a perfectly good operating model. Don't kill it because a LinkedIn post told you to. Define it well, or replace it deliberately with something you can actually run.
While we're naming the lineage: the SiriusDecisions / Forrester demand waterfall runs MAL (marketing accepted, demographic fit) → MQL (behavioral threshold) → SAL (sales formally accepts and commits to follow up within an SLA) → SQL (sales verifies a real opportunity).
The SAL is the accountability layer most HubSpot setups skip. It's also the one the Leads object's "Connected" and "Qualified" stages, paired with a rejection-reason loop, can actually operationalize.
Just don't add MAL or SAL stages unless someone owns each and it changes a real action. Stages that don't change behavior are clutter.
Here's how we'd sequence the work in a real portal.
Stage 1 — Get the foundation right (week 1). Confirm you're on the default Lifecycle Stage property and migrate off any custom one. Write definitions for every stage, especially MQL and SQL (BANT for SQL), and get marketing and sales to sign off. Set the Automate panel deliberately, and default the company → contact sync to off for B2B and ABM, driving contacts through filtered workflows instead. Backfill blank and incorrect stages via bulk edit or import (closed-won to Customer, form submitters to Lead).
Stage 2 — Automate safely (weeks 2–3). Build one centralized lifecycle workflow (or a small governed set). Add forward-only suppression filters to every one. Trigger Opportunity on deal creation and Customer on deal won via deal-based workflows. Decide your regression policy in writing (furthest-reached vs clear-then-set) and document the reporting trade-off.
Stage 3 — Operationalize the handoff (weeks 3–6). Turn on the Leads object and prospecting workspace (Sales Hub Pro/Enterprise) and auto-create a lead when a contact hits MQL. Run lead stages New → Attempting → Connected → Qualified → Disqualified, with Qualified auto-creating a deal. Implement your MQL-to-SDR SLA (first touch in minutes for high-intent leads, a multi-touch cadence, mandatory rejection reasons) and enforce it with "Time in Stage" workflows. Keep the deal pipeline to real opportunities, and map (don't merge) lifecycle stage to deal stage.
Stage 4 — Report and iterate (ongoing). Build a funnel dashboard (volume and conversion by stage), a pipeline-health dashboard (time-in-stage), and an MQL-to-SQL conversion report with rejection reasons. Use journey funnel reports for accuracy and enable the stage calculated properties for velocity.
Numbers only matter if they trigger an action. These do:
Treat the benchmark figures as directional. They come from sources of varying age and rigor, so instrument your own baseline fast.
Some of this depends on your subscription. Workflow-based lifecycle automation and the calculated time-in-stage properties require Marketing or Sales Hub Professional or Enterprise. The Leads object, prospecting workspace, and Buying Groups require Sales (or Service) Hub Pro/Enterprise, with Buying Groups still in beta. On Starter accounts, you'll manage much of this manually.
Buying Groups availability is beta and evolving (currently Public Beta for Sales/Service Hub Enterprise, Private Beta for Sales/Service Hub Pro). Confirm the current tier in-app before promising it to clients.
There's also no official reconciliation of buying roles or groups with lifecycle stage, so treat that guidance as opinion, not HubSpot gospel. And the nine buying-role values are partner-verified, since HubSpot's KB names only three examples. Check the live list in your portal.
Finally, funnel reporting is genuinely fragile to skips, regressions, and merges, and legacy versus journey funnel reports can disagree. Validate your report logic before putting numbers in front of leadership.
What's the difference between lifecycle stage and lead status in HubSpot? Lifecycle Stage is the macro funnel position (where a contact sits from Subscriber to Customer), shared across teams. Lead Status is the micro working state (what a rep is doing right now, like "Attempted to Contact"). A contact can be an SQL on lifecycle stage but "Attempted to Contact" on lead status. They work together, not as alternatives.
Which property should an SDR or BDR update at handoff? Lead Status, or better, the Leads object in the prospecting workspace. Not Lifecycle Stage. Lifecycle Stage moves on real milestones; the SDR's day-to-day prospecting state belongs in Lead Status or a Lead record.
Can a HubSpot lifecycle stage move backward? Yes, but only if you clear the value first, then set the lower stage. HubSpot tools only move the stage forward by default. Beware: backward movement corrupts the legacy "Became a [stage] date" properties and your funnel reports.
Why didn't my company's lifecycle stage update when the contact changed? Because the sync is one-directional (company → contact only). Contact changes never roll up to the company automatically. To roll contacts up to the account, you need a custom workflow, and you should confirm the company is set as primary.
How many lifecycle stages does HubSpot have? Eight by default: Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer, Evangelist, and Other. Super Admins can add custom stages.
Should every contact have a lifecycle stage? Yes. Unset contacts either default to the first stage or sit at no value, which pollutes your funnel reports. Backfill blanks deliberately.
Is the MQL dead? No. A poorly defined MQL is dead. The concept works where you tighten definitions, add SLAs, and measure SQL and sourced pipeline instead of raw MQL volume.
HubSpot lifecycle stages do exactly one job: marking where a contact or company sits in your funnel.
Almost every problem teams blame on the property (broken reports, a leaky handoff, a "Customers" list full of non-customers) comes from asking it to do a second job it was never meant for.
So keep it clean:
(Illustration: a simple "one job each" graphic — three labeled lanes side by side (Lifecycle Stage / Lead Status / Deal Stage), each with a single icon and a one-word job ("Funnel position" / "Rep activity" / "One pursuit"). A clean visual summary readers can screenshot as the article's key takeaway.)
Automate the mechanical transitions with forward-only suppression and a single source of truth. Land your MQLs in an SDR-owned lead process, not the deal pipeline. Do that, and your funnel reports will finally match what's actually happening.
If you'd rather not learn the date-property traps the hard way, that's exactly the work we do. Superwork is a B2B HubSpot RevOps agency. We design lifecycle architecture, build the automation, and operationalize the marketing-to-sales handoff so your pipeline stops leaking. Book a HubSpot RevOps audit with Superwork, and we'll start with the parts of your funnel quietly costing you the most.