GrowthKitty blog

HubSpot lifecycle stages are not deal stages, conflation can be costly

kasey@growthkitty.com (Kasey Chan) — Thu, 16 Apr 2026 12:32:51 GMT

This is the single most common structural error in HubSpot implementations. It seems minor. It isn't.

Lifecycle stages and deal stages are two different constructs that answer two different questions. When they get conflated — which happens in the majority of portals we encounter — the downstream effects ripple through your reporting, your automation, your segmentation, and your attribution.

Here's how to understand the difference, why it matters, and how to fix it.

What Lifecycle Stages Are For

Lifecycle stage is a contact and company-level property. It represents where a person or organisation sits in their relationship with your business as a whole — not in relation to a specific deal.

The progression looks something like this:

Subscriber → Lead → MQL → SQL → Opportunity → Customer → Evangelist

(With variations depending on your GTM motion — some organisations insert SAL between MQL and SQL; others collapse stages depending on their sales velocity.)

The key point: lifecycle stage is owned at the entity level. A contact can have one lifecycle stage. That stage reflects the most advanced position they've ever reached with your business — not where they are right now in a current deal.

What Deal Stages Are For

Deal stages are deal-level properties. They represent the status of a specific sales opportunity — not the contact or company behind it.

A contact who is a Customer might have a new deal in the Proposal stage. The contact's lifecycle stage is Customer. The deal's stage is Proposal. These are independent.

Deal stages answer: Where is this specific opportunity in the buying process?

Lifecycle stages answer: What is this person's overall relationship status with our business?

What Goes Wrong When You Conflate Them

Reporting breaks. If lifecycle stage is being set based on deal stage (e.g., "move to SQL when deal is created"), your lifecycle funnel report stops measuring what it's supposed to measure. You're no longer seeing the lead conversion story — you're seeing deal creation activity, which is a different metric.

MQL definition becomes meaningless. If SQL is set when a deal is created rather than when a contact hits a qualification threshold, you've lost the ability to distinguish between marketing-qualified and sales-qualified signals. Your MQL→SQL conversion rate becomes 100% (because SQL is being triggered by the same event as opportunity creation), and your marketing attribution is gone.

Automation fires incorrectly. Workflows triggered by lifecycle stage changes will fire at the wrong time, for the wrong contacts, with the wrong content. A nurture sequence designed for MQLs will enrol contacts who are already mid-deal.

Segmentation becomes unreliable. Lists and smart content based on lifecycle stage will pull in the wrong audience. Your "never been a customer" segment might include active customers whose lifecycle stage was never updated post-close.

The Correct Architecture

Here's a clean way to think about lifecycle stage design:

Lifecycle stage should be:

Set automatically, based on defined criteria
A forward-only property (contacts don't move backwards — a Customer is always a Customer, even if a deal falls through)
Owned by a specific team at each stage (Marketing owns up to MQL; Sales owns SAL/SQL; CS owns Customer and beyond)
Linked to SLA rules (e.g., an MQL must be worked within 24 hours, or it triggers an alert)

Deal stage should be:

A reflection of the sales process, not the contact relationship
Defined in terms of buyer actions, not seller actions ("Proposal sent" is a seller action; "Proposal reviewed and questions raised" reflects buyer engagement — the latter is more useful)
Independent of lifecycle stage, but connected through reporting (so you can see how deal activity maps to lifecycle progression)

The Fix: Decouple the Logic

If your HubSpot has lifecycle stages being set by deal stage changes, the first step is to audit every workflow and property-setting rule that touches lifecycle stage. Map out what's setting it and when.

Then rebuild the logic from first principles:

Define what each lifecycle stage actually means for your business
Identify the specific triggers that should move a contact from one stage to the next (form fills, score thresholds, manual sales qualification, deal creation where appropriate)
Build the workflows to enforce those triggers — and only those triggers
Set up the funnel reporting to verify the logic is working

It's a few days of work. But it unlocks clean reporting, accurate attribution, and automation that actually fires at the right time — which makes everything else you build in HubSpot dramatically more effective.

The foundation matters. Get it right, and everything stacks cleanly on top of it.

The Real Difference Between a CRM Admin and a RevOps Architect

kasey@growthkitty.com (Kasey Chan) — Thu, 16 Apr 2026 12:28:33 GMT

When a B2B company decides it needs "someone for HubSpot," there's usually a gap between what they ask for and what they actually need.

The job post goes up. The brief says something like: HubSpot experience required. Will manage workflows, maintain contact database, support marketing campaigns. A few candidates apply. Someone gets hired. Six months later, the problem that prompted the hire still hasn't been solved — it's just been better-documented.

This isn't a people problem. It's a scoping problem. And it comes from conflating two very different functions: CRM administration and RevOps architecture.

What a CRM Admin Does

A CRM admin is an operator. They work within a system that's already been designed — maintaining it, troubleshooting it, training users on it, and executing tasks that require platform knowledge.

Good CRM admins are genuinely valuable. A well-maintained HubSpot portal doesn't happen by accident. Properties need updating. Lists need pruning. Workflows drift out of spec. Someone needs to handle support tickets when a workflow breaks at 11pm before a product launch.

But admins are executing within a defined system. They're not designing the system.

What a RevOps Architect Does

A RevOps architect is working at a different altitude.

They're asking: How should revenue flow through this organisation? What does the lifecycle look like from first touch to renewal? Where is the handoff between marketing and sales, and how do we enforce it? What does attribution need to look like for the CFO to trust the marketing spend report?

Then they're building the infrastructure to answer those questions: data models, scoring logic, lifecycle automation, integration architecture, pipeline design, and the reporting layer that sits on top.

The practical difference shows up fast. When a CRM admin encounters a problem — say, MQL numbers that don't match between HubSpot and the board deck — they'll investigate the workflows and the data. When a RevOps architect encounters the same problem, they're asking whether the lifecycle stage definition is even correct, whether the attribution model is the right one for the business, and whether the reporting being pulled is measuring the right thing.

One is debugging. The other is redesigning.

Why This Distinction Matters More as You Scale

At 10 salespeople and a single product, the line between admin and architect is blurry. The system is simple enough that a competent admin can keep it working while making the occasional structural decision.

At 50 salespeople, multiple product lines, a separate SDR function, a customer success team sharing the CRM, and a CFO asking for revenue attribution by channel — the system can no longer be held together by someone who's good at HubSpot. You need someone who's good at revenue operations design, who also knows HubSpot.

That's a narrower pool, and it's a different job.

The Four Questions That Reveal Which One You Need

If you're trying to figure out what your organisation actually needs, start here:

1. Do you have a defined lifecycle architecture? Not just lifecycle stages in HubSpot — an actual documented model that specifies what triggers movement between stages, who owns each stage, and what the SLA is for follow-up. If the answer is no, you need an architect.

2. Can your current reporting answer: "Where in the funnel are we losing revenue, and why?" If the answer is "sort of" or "we pull it manually," you need someone to redesign the reporting infrastructure, not just maintain it.

3. Are your GTM tools talking to each other? If data from your ABM platform, your enrichment tool, and your CRM isn't reconciling cleanly — and someone's manually copying fields between systems — you need an integration builder, not a form manager.

4. Is your CRM being used as a system of record or a system of action? Systems of record store data. Systems of action drive behaviour — surfacing the right playbook at the right deal stage, automating the right follow-up, alerting the right person when a deal goes cold. If your HubSpot is only doing the former, you're underutilising it significantly.

The Fractional Option

Not every company needs (or can afford) a full-time VP of RevOps. But they do need the thinking — particularly during periods of rapid growth, post-Series A fundraising, or before a critical go-to-market pivot.

This is where fractional RevOps architecture makes commercial sense. Bringing in senior-level GTM engineering expertise for a defined period — to design the system, build the infrastructure, and hand it over with documentation — is often a better use of budget than hiring someone full-time who will spend most of their time maintaining a system that was never properly built.

The question isn't just "who can manage our HubSpot." It's "who can design the revenue infrastructure this business is going to need for the next 18 months."

Those are different questions. Make sure you're asking the right one.

Why Your HubSpot Is Telling You Lies (And What to Do About It).

kasey@growthkitty.com (Kasey Chan) — Thu, 16 Apr 2026 12:20:49 GMT

You've got dashboards. You've got reports. You've got a deal pipeline that looks busy.

But when your sales team sits down with leadership to review the numbers, nobody actually trusts them.

Sound familiar?

This is one of the most common patterns in B2B GTM organisations that have been using HubSpot for more than 12 months: the platform is full of data, but the data itself is unreliable. And because it's unreliable, decisions get made on gut feel — which defeats the entire point of having a CRM.

Here's what's usually going on under the hood.

The Root Cause: Architecture That Wasn't Designed for Scale

Most HubSpot implementations start the same way. A marketing manager or ops person sets up the account, creates a few pipelines, maps some basic lifecycle stages, and launches. It works well enough in the early days.

Then the business grows. A new product line. A new geography. A sales team that doubles. An ABM motion layered on top of inbound. Suddenly, the lifecycle stages that made sense for 10 deals a month are creating chaos at 100.

The problem isn't HubSpot. It's that the underlying data architecture was never designed to scale — and nobody has gone back to fix it.

The Three Most Common Data Integrity Problems

1. Lifecycle stages that don't mean anything

Lifecycle stage should represent a contact or company's relationship with your business — from subscriber to customer. But in most HubSpot portals we audit, lifecycle stages are either:

Set once and never updated, or
Being used as a proxy for deal stage (which is a different thing entirely)

The result: your MQL count is inflated, your SQL-to-close ratio is meaningless, and your attribution model is broken at the source.

2. Properties with no governance

Over time, HubSpot portals accumulate custom properties the way drawers accumulate cables. Someone needed a field for a campaign. Someone else duplicated it under a different name. Now you have three variations of "Industry" and none of them are consistently populated.

When your scoring model pulls from inconsistent data, your scores are noise. When your segmentation uses unpopulated fields, your audiences are wrong. Everything downstream suffers.

3. Duplicate records and broken associations

Duplicates aren't just a cosmetic problem. When a contact exists as two records — one from a form fill, one from a list import — your activity history is split. Your sequence enrolment logic fires incorrectly. Your revenue attribution credits the wrong touchpoint.

Deduplication isn't glamorous work. But it's foundational. Everything else you build on top of a dirty database is structurally compromised.

What Good Architecture Actually Looks Like

A well-architected HubSpot instance has a few non-negotiable properties:

Lifecycle stage is a system field, not a manual one. Transitions should be automated based on defined criteria — form fills, deal stage changes, scoring thresholds — with explicit SLA handoff rules between teams. Marketing owns MQL. Sales owns SAL and SQL. The boundary is clear, enforced by logic, and visible in reporting.

Properties have an owner and a purpose. Before a new custom property gets created, someone should be able to answer: what business question does this field answer? How will it be populated? Who is responsible for keeping it accurate? If you can't answer those questions, the field doesn't get created.

Association logic is intentional. Contact-to-company associations, deal-to-contact associations, ticket-to-deal associations — these should reflect how your business actually works, not HubSpot's default settings. In complex B2B environments with buying committees or multi-product lines, this matters more than most teams realise.

The Fix Isn't a Feature — It's a Methodology

There's no HubSpot setting you can toggle to fix a data integrity problem. It requires:

An honest audit of what you currently have
A defined data model that reflects how your GTM motion actually works
Retroactive cleanup (yes, this is tedious, but unavoidable)
Automation to enforce the rules going forward
Governance to prevent the problem from creeping back

Most teams skip steps 1–3 and jump straight to building more automations on top of bad data. That's how you end up with a very sophisticated CRM that still produces numbers nobody believes.

Before You Add Anything New to Your HubSpot, Fix What You Have

The instinct when something isn't working is to add more — more workflows, more fields, more integrations. But if your foundation is broken, adding complexity just makes the problem harder to untangle later.

The highest-leverage thing most B2B GTM teams can do right now isn't implementing a new tool. It's going back to the data model they have, cleaning it up, and building the right automation logic on top of it.

That's not the exciting answer. But it's the one that actually moves the revenue number.