Every stalled CRM implementation I have been called into had a lifecycle stage model. Usually a good one. Subscriber, Lead, MQL, SQL, Opportunity, Customer — the same six words, sitting in the same dropdown, in HubSpot or Salesforce or whatever else.
The stages were never the problem. What was missing, every single time, was the boring part underneath: who decides a contact has left this stage, on what evidence, and what happens the moment they do. Without that, a lifecycle stage is a label someone types in when they remember. Reporting built on it is fiction, and everybody in the room quietly knows it.
This is the model I actually implement, and the four questions I make a team answer per stage before we touch a single property in the CRM.
Lifecycle stage and lead status answer different questions
Start here, because conflating these two fields causes more damage than any other CRM mistake I see, and it is completely free to fix.
Lifecycle stage answers: how far into the relationship is this person? It moves forward, it is owned by the business as a whole, and it is what you report the funnel on. Lead status answers: what is happening in the work right now? New, attempting contact, connected, unresponsive, unqualified. It bounces around, it is owned by whoever is working the record, and it is what a rep looks at on Monday morning.
When teams collapse the two, you get lifecycle stages like «Attempting to contact» and «Nurture» sitting in the same dropdown as MQL and Customer. The funnel report then counts a stalled call attempt as a funnel position, conversion rates between stages become uninterpretable, and nobody can answer the only question the model exists to answer: of the people who reached this point, how many reached the next one, and how long did it take?
Every stage needs four things, and most have one
Most implementations define what a stage means and stop there. A stage is only operational when all four of these exist in writing:
| What it needs | The question it answers |
|---|---|
| A definition | What is true about a person who is here? Written so two people in different teams classify the same record identically. |
| An exit criterion | What specific, observable event moves them out? Not «shows interest» — a form, a threshold, a meeting held, a stage change on a deal. |
| An owner | Who is accountable while the record sits here, and who is accountable for the transition itself? Those can be two different people. |
| A timestamp | A date property written when the record enters. Without it you cannot measure stage velocity, and velocity is where the actual diagnosis lives. |
The exit criterion is the one that does the work. «MQL means a marketing-qualified lead» is a tautology. «MQL means fit score is 60 or above and the contact has either requested a demo or hit 3 pricing-page views in 14 days» is a rule a workflow can execute and a sales director can argue with — which is exactly what you want, because the argument happens once, in a room, instead of every week in the pipeline review.
The timestamp is the one everybody skips and later wishes they had. Entry dates per stage are what let you say «MQL to SQL takes 19 days and 40% never make it» instead of «the funnel feels slow». They cost nothing to add on day one and cannot be reconstructed retroactively.
Fit and intent are two scores, not one
The single most common scoring failure: one number, built by adding points for job title to points for email opens. A CFO at a perfect-fit company who has visited twice scores the same as a student who downloaded four PDFs. The model cannot tell you which one to call, because the two inputs mean opposite things.
Fit is who they are — industry, size, role, geography, tech stack. It is slow-moving and mostly firmographic. Intent is what they are doing — pricing page, demo request, repeat sessions, reply to a sequence. It is fast-moving and it decays. Keep them as two properties and the routing logic writes itself:
Two more rules that save scoring models from themselves. Intent must decay — a pricing visit from March should not still be inflating a score in September, and a model without decay slowly promotes your entire database. And negative scoring should be structural, not behavioural: subtract for a competitor domain, a student email, a country you do not sell into. Subtracting points because someone did not open an email punishes the email, not the lead.
Three rules that keep the model clean once it is live
1. Lifecycle only moves forward. A customer who fills in a top-of-funnel form does not become a Lead again. Most CRMs will happily let a workflow demote them, and once that starts your customer count drifts down every month for reasons nobody can trace. Guard every stage-setting workflow with a condition that checks the current stage first. Movement backwards, when it is genuinely needed, is a deliberate manual act with a reason logged — not an automation side effect.
2. One owner per transition. Two workflows that can both set a contact to MQL will eventually fight, and the winner is decided by execution order rather than intent. Every transition gets exactly one mechanism: one workflow, or one manual action, never both. Write the list of transitions down; if a transition has two possible causes, one of them is a bug you have not hit yet.
3. Recycling is a defined path, not a graveyard. Roughly two-thirds of leads sales rejects are still viable later, and the default handling — mark unqualified, forget forever — is where most B2B pipeline quietly dies. Define the return route: rejection reason is mandatory, timing rejections go back to nurture with a re-entry rule, fit rejections are suppressed permanently. A rejection reason field that is optional will be empty within a month, and then you have no idea whether your leads are bad or your timing is.
The five-day pass I would run on your CRM
This is not a quarter-long project. On a normal mid-market setup it is a week, and most of the week is conversation rather than configuration.
Day 1 — Audit. Export contacts by lifecycle stage. Count how many sit in each, how long they have been there, and how many were last touched by a human. The distribution alone tells you which stages are real and which are storage. Day 2 — Definitions. Both teams in one room, one page per stage, four boxes each: definition, exit criterion, owner, timestamp. Nobody leaves until the MQL row is agreed. Day 3 — Split the scores. Fit and intent as separate properties, decay on intent, structural negatives only.
Day 4 — Build and guard. One workflow per transition, forward-only conditions, entry-date stamps on every stage, mandatory rejection reason. Day 5 — The report you could not build before. Volume, conversion rate and median days per stage, plus recycled-lead outcomes. That report is the deliverable. The configuration was just what made it possible.
One dependency worth naming: none of this survives dirty data. Duplicate contacts split a person’s history across two records and both of them score wrong — which is why the hygiene layer comes first, and why we ended up building a deduplication bot on top of the HubSpot API rather than trusting native tooling alone. Fix the records, then fix the model.
Questions that come up every time
What is the difference between lifecycle stage and lead status?
Lifecycle stage records how far a contact has progressed in the overall relationship and moves forward only — it is what funnel reporting is built on. Lead status records what is happening in the work right now (new, attempting, connected, unresponsive) and changes freely. Keep them in separate properties: mixing them makes conversion rates meaningless.
How many lifecycle stages should a B2B company have?
Five to seven. Fewer and the funnel hides its own bottlenecks; more and the extra stages are almost always work statuses or segments wearing a costume. Add a stage only when a different team owns the record after the transition.
Should lifecycle stages ever move backwards?
Not automatically. Guard every stage-setting workflow so it cannot demote a record. When a genuine reset is needed — a churned customer re-entering evaluation, for example — make it a deliberate manual action with a logged reason, so the funnel history stays interpretable.
Do we still need lead scoring if we have AI in the CRM?
Yes, and arguably more. A predictive or AI-assisted score is only as good as the definitions and outcomes it learns from — if your MQL label is applied inconsistently, the model learns the inconsistency. Get the human-legible model right first, then let automation run on top of it.
The model is an agreement, and agreements need maintenance
The reason lifecycle models decay is not technical. They decay because the agreement behind them was made once, by people who have since changed roles, about a product that has since changed shape. The definitions stay in the CRM long after they stopped describing the business.
So put a date on it. Once a quarter, take the four-box page for each stage and ask whether the exit criteria still match how deals actually happen. It is a forty-minute meeting and it is the difference between a CRM that reflects the business and one that reflects the business as it was two years ago.
And before you hand any of this to automation, make sure the rules exist in writing first — the same argument applies to giving an AI write access to your CRM. Automation is very good at executing a model consistently. It is very bad at noticing that the model was never agreed.
Want this run on your CRM?
I rebuild lifecycle and scoring models for B2B teams on HubSpot: stage audit, definitions workshop with sales and marketing in the room, split fit/intent scoring, guarded workflows, and the funnel report at the end of it. A week of work, and you keep the documentation.
