Why lifecycle models break (and how to build one that doesn’t)

Every RevOps person I know has had the same argument at least once.

Someone insists that lifecycle stage should always show the furthest point a lead ever reached. “For funnel reporting,” they say. And you’re sat there thinking: that’s not a lifecycle, that’s a trophy cabinet.

Meanwhile, your CRM has contacts marked as “MQL” from 2019 who haven’t opened an email in three years. You’ve got churned customers still showing as customers because no one updated the field. And sales doesn’t trust any of it, so they’ve built their own spreadsheet.

This is the lifecycle problem. Not the theory — the gap between theory and what actually survives contact with real data, real tools, and real humans who forget to update things.

The core issue: lifecycle gets used for two different jobs

Here’s what trips teams up.

Lifecycle stage gets asked to do two things at once:

1. Tell me where this account is right now
2. Tell me what this account achieved historically

Those are different questions. The moment you try to answer both with one field, you’re in trouble.

If lifecycle shows “furthest reached,” you can’t segment by current state. Your nurture campaigns hit people who are already customers. Your SDRs waste time on accounts that closed six months ago.

If lifecycle shows “current state,” your funnel reports break because people move backwards and the numbers don’t add up quarter to quarter.

The answer isn’t to pick one. It’s to stop pretending one field can do both jobs.

What lifecycle should actually be

Lifecycle should answer one question:

Where is this account right now?

That’s it. Not “what did marketing want to claim.” Not “what stage did they reach once upon a time.” Just: where are they today.

Which means lifecycle has to be live. It has to change when reality changes.

Account had a deal, deal got closed-lost, no new deal opened? They’re not an opportunity anymore. They’re back in the pool.

Customer churned? They’re not a customer anymore. Doesn’t matter that they were one last year.

This feels obvious when you say it out loud, but most CRM setups don’t work this way. They set lifecycle via workflows when something happens, then never update it again.

A quick note on HubSpot’s “lifecycle can’t go backwards” rule

If you’ve worked in HubSpot, you might be thinking:

“Hang on – lifecycle stage isn’t supposed to go backwards.”

And you’d be right. Sort of.

HubSpot’s default Lifecycle Stage property isn’t designed to represent live status. It’s designed for historical attribution. It answers the question:

What’s the furthest point this record has ever reached?

That’s useful for reporting, but it’s not the same thing as understanding where an account actually sits today.

The mistake most teams make is trying to use that one field for both jobs.

In practice, you need two separate concepts:

• Lifecycle (historical) – the furthest stage ever reached, used for attribution

• Lifecycle (live) – the current state of the account, derived from real data

Once you separate those, the conflict disappears.

HubSpot is right that historical lifecycle shouldn’t move backwards.
But operational lifecycle absolutely should.

Trying to force both into the same field is where things start to break.

Derived beats set, every time

Most lifecycle logic looks like this:

• “If they submit a demo form, set lifecycle to MQL”
• “If the deal reaches Stage 2, set lifecycle to SQL”
• “If the deal closes won, set lifecycle to Customer”

That works until someone:

• Creates a deal manually and skips the form
• Closes a deal early without hitting Stage 2
• Reopens an old opportunity
• Creates a duplicate by accident
• Marks something disqualified when it should’ve been recycled

Now lifecycle is wrong, and nothing tells you it’s wrong.

The better approach is to derive lifecycle from things that already exist in the system:

• Does the company have an open deal? → Opportunity
• Does that deal have a QSO date? → Qualified
• Is there a closed-won deal with an active contract? → Customer
• Was there a deal that’s now closed-lost? → Recycled

No workflows setting fields. No humans remembering to click things. Just logic that reads the current state and reflects it.

If the underlying data changes, lifecycle changes automatically.

Why this has to live at company level

This one causes arguments, but I’ll die on this hill.

In B2B, lifecycle belongs on the company, not the contact.

Why? Because:

• People change jobs
• Multiple contacts influence one deal
• Deals belong to accounts, not individuals
• You don’t close “Sarah from Procurement” — you close the company

If lifecycle lives on contacts, you get chaos. One contact marked Customer, another at the same company marked Lead, a third marked MQL. That’s not insight. That’s noise.

The clean model:

• Lifecycle = company level (where is the account)
• Influence = contact level (who contributed to movement)

Contacts influence deals. Companies progress through stages. Keep those separate and reporting gets dramatically simpler.

What happens when someone engages but they’re already in pipeline

This is the question that breaks most lifecycle models.

Someone from an account that’s already talking to sales signs up for your webinar. Or downloads a whitepaper. Or clicks through on a campaign. They’ve done something marketing cares about — but the company is already at MQL or beyond.

Do you create another MQL? No. That would be nonsense. You can’t move them backwards through the funnel.

Do you ignore it? Also no. Marketing did something that mattered, and you want to track it.

The answer is to stop conflating lifecycle movement with marketing contribution.

Sourced means the deal came from this activity. Someone engaged, a deal got created, and there’s a direct line between the two.

Influenced means the deal already existed, but this activity contributed to pipeline movement. Someone from an open opportunity came to your event. They didn’t create a new MQL — they reinforced an existing one.

Both matter. But they’re not the same thing, and they shouldn’t be reported the same way.

The practical way to do this is with association labels on deals — or better, by using objects to represent activities. If you have an Events object, you can associate contacts who attended and deals that were open at the time. Then you can report: “Last quarter, events sourced £2m in new pipeline and influenced £5m in existing pipeline.”

That’s a much more honest picture than pretending every form fill is a net-new MQL.

Objects beat fields, every time

This is related, and it’s worth saying explicitly.

The instinct when tracking something new — events, content downloads, MQLs, whatever — is to add a field. “MQL date.” “Last event attended.” “Content piece downloaded.”

That works until you need to track more than one. Or until you need to report on the thing itself, not just the contact’s relationship to it.

Fields are flat. Objects are relational.

If you create an Events object, you can:

• Associate multiple contacts to one event
• Associate deals to that event
• Track sourced vs influenced pipeline per event
• Report on which events drive the most qualified pipeline
• See which contacts attend the most events

If you just have a “last event attended” field on the contact, you can’t do any of that. You’ve got a single data point with no context.

Same logic applies to MQLs. If MQL is just a lifecycle stage on a contact, you can track when they first became one. But if MQL is an object — a record that gets created when someone qualifies — you can track every time it happens, tie it back to source, associate it with deals, and report on conversion rates properly.

The upfront effort is higher. The long-term payoff is enormous.

The model that actually survives

Here’s what holds up in practice.

Lifecycle stages (live state):

• Lead — ICP, no meaningful engagement, no deal
• Engaged — Real intent signals, but no deal yet
• MQL — Has a deal that’s reached MQL criteria
• QSO — Deal has hit qualification milestone
• Customer — Active customer relationship
• Recycled — Had a deal, now closed-lost, no active opportunity
• Churned — Was a customer, isn’t anymore

How each stage is derived:

The key thing: all of this is based on live list membership. Change the criteria, the segments update. No workflow archaeology required.

Recycled and churned aren’t steps — they’re parallel states

This is where most lifecycle models get the shape wrong.

People assume lifecycle is a straight line:

Lead → MQL → QSO → Customer → done

But that’s not how it works in practice. Lifecycle is more like a spine with multiple entry points.

Lead, Recycled, and Churned all sit at the same level — they’re all “not currently in an active sales motion.” What’s different is the context they bring.

• Lead — someone you’ve never properly engaged
• Recycled — someone you did engage, had a real sales motion with, and lost
• Churned — someone who was a customer and no longer is

They’re not “lower” than Lead. They’re parallel states with different histories.

Visually:

All three feed into the same funnel. But they’re not the same audience.

That distinction matters because:

• You don’t message them the same way
• You don’t score them the same way
• You don’t expect the same conversion rates
• You definitely shouldn’t report on them as if they’re equivalent

A recycled account has had a sales conversation. They’ve raised objections. They’ve told you why now wasn’t the right time. Treating them like a cold inbound lead ignores all of that — and usually annoys them.

A churned customer is different again. They’ve used the product. They’ve experienced value (or lack of it). Re-engagement needs to acknowledge that history.

If you collapse all of these back into “Lead,” you erase the context that makes your follow-up relevant.

Recycled and churned aren’t failures. They’re different starting points.

The bit everyone forgets: historical timestamps

Live lifecycle solves the “where are they now” problem.

It doesn’t solve the “when did things happen” problem.

For that, you need separate fields:

• First MQL date
• First QSO date
• First customer date
• Most recent lifecycle change

These never get overwritten. They’re your reporting anchor points.

Why this matters:

• Lifecycle changes over time
• Finance cares about when things happened
• Leadership wants to compare quarters
• Without fixed timestamps, your reports drift

Live state and historical record are both necessary. They’re just not the same thing.

The uncomfortable bit: this only works if your data is clean

Everything above assumes your deal data is reasonably accurate.

In reality:

• Syncs fail silently
• Associations break
• Deals get created in the wrong place
• Fields don’t get filled consistently
• Salesforce and HubSpot disagree and nobody notices

That’s not a reason to abandon derived lifecycle. It’s a reason to:

• Build exception reports
• Monitor for mismatches
• Accept that lifecycle is only as good as the data feeding it

The goal isn’t perfection. It’s visibility. If you can see when things are wrong, you can fix them. If lifecycle is set by buried workflows, you won’t know there’s a problem until the board deck doesn’t add up.

The actual point

Lifecycle isn’t about making the CRM look neat.

It’s about being able to answer basic questions without a three-hour investigation:

• Where does this account stand?
• What moved them?
• When did it happen?
• Who gets credit?

The moment lifecycle becomes something you manually set, you’ve already lost control of it.

The moment it becomes something derived from reality, it starts telling you the truth.

Contact

To get in touch, please drop me a line at tom <at> tjmdigital <dot> com