What are CRM lifecycle stages?
CRM lifecycle stages are a small set of states that describe where each person or company sits in their relationship with your business, from first contact to paying customer and beyond. Each record holds exactly one stage at a time, and the stage changes only when something meaningful happens: a purchase, a sales conversation, a cancellation.
The labels matter less than whether every part of your system can rely on them. Marketing uses the stage to decide who gets which emails. Sales uses it to know who to call. Reporting uses it to count how many leads became customers this quarter. When the stage is wrong, all three are wrong at the same time, which is why lifecycle stages are usually the first thing we look at when a CRM “doesn’t add up”.
This guide is platform-neutral. Some CRMs have a built-in lifecycle field (HubSpot’s is covered in detail in our guide to HubSpot lifecycle stages). Others, like Klaviyo, have no lifecycle field at all, and you build the same idea with profile properties and segments. The thinking is the same either way.
Lifecycle stage, pipeline stage and status are different things
Most confusion comes from using one field to answer three different questions.
Lifecycle stage answers “what kind of relationship is this?” Lead, customer, former customer. It changes rarely, maybe a handful of times over years.
Pipeline or deal stage answers “where is this particular deal?” Discovery, proposal, negotiation, closed won. It belongs to the deal or opportunity, not the person, and one company can have three deals in three different stages.
Status fields answer “what is someone doing about it right now?” Attempted to contact, waiting on reply, bad timing. They change weekly or daily and are usually owned by one team.
A common failure looks like this. Sales wants to track call attempts, so someone adds “Contacted” and “No answer” as lifecycle stages. Six months later, marketing’s nurture emails exclude anyone past “Lead”, which now includes thousands of people who were called once and never spoke to anyone. The stage became a to-do list and stopped describing the relationship.
Keep the three separate and the rules for each one get much simpler.
Example stage sets
There’s no universal list. These are starting points we’d adapt, not templates to copy.
B2B with a sales team: Subscriber, Lead, Marketing qualified, Sales qualified, Opportunity, Customer, Former customer. Some teams add “Disqualified” or use a separate field for it, so bad-fit records stop polluting the funnel.
Ecommerce: Subscriber, First-time buyer, Repeat buyer, Lapsed. Many brands also track VIP, but VIP is usually better as a segment based on spend than as a stage, because it changes constantly.
Service business or local trade: Inquiry, Quoted, Booked, Active customer, Past customer. Here the quote is the critical point. A quote that sits without follow-up is where a lot of revenue goes missing.
Subscription or SaaS: Lead, Trial, Active subscriber, At risk, Canceled. “At risk” is debatable as a stage. It works if a specific team acts on it, and becomes noise otherwise.
How many lifecycle stages should you have?
Fewer than you think, usually five to seven. Each stage should exist because something different happens to records in it: a different owner, a different message, a different report. If two stages trigger the same treatment, merge them.
A useful test is to ask, for each stage, “what would we do differently for someone here?” If the honest answer is “nothing”, the stage is decoration. Decorative stages cost real effort because every automation and report has to account for them.
The opposite problem exists too. If your sales team constantly says “these MQLs are a mix of students, competitors and real buyers”, you may need a qualification step you don’t currently have, or a disqualified state so the funnel stops counting obvious junk.
Writing entry and exit rules
Every stage needs a written rule that a person and an automation could both apply without arguing. We use the same five lines for each one:
- Entry rule. The event or condition that puts a record here. “Submitted the demo request form” is a rule. “Showed buying intent” is not.
- Exit rule. What moves it forward, and what moves it back.
- Data source. Which system or field the rule reads from, such as the form, the billing system or the deal record.
- Owner. Who is responsible for records in this stage.
- Expected action. What should happen within a set time, and who does it.
Here’s a realistic MQL rule:
Entry: lead score reaches 40, or the contact requests a demo or pricing. Excludes personal email domains and existing customers. Exit forward: sales accepts within two business days and sets the record to Sales qualified. Exit back: sales rejects with a reason, record returns to Lead and re-enters nurture. Owner: SDR team. Expected action: first contact within one business day.
Notice that it says what happens when sales rejects the lead. Most stage definitions only describe forward movement, which is why so many CRMs fill up with MQLs that no one is working.
Write the rules down somewhere both teams can find them. A shared doc is fine. Our customer lifecycle map template has columns for exactly these fields.
Should lifecycle stages move backward?
Yes, when the old stage would trigger the wrong action. A record should reflect the current relationship, not the furthest point it ever reached.
The usual cases:
- Lost deals. A contact whose only deal was lost is no longer an opportunity. Leaving them there keeps them out of nurture and inflates pipeline counts.
- Rejected leads. If sales disqualifies an MQL for bad timing, they belong back in nurture, not stuck in a stage sales has already decided to ignore.
- Churned customers. Someone who canceled two years ago shouldn’t receive “thanks for being a customer” messages or count in your customer total.
Backward movement needs care because some platforms only move stages forward automatically. HubSpot is the best-known example, and you have to clear the field before setting an earlier value. Whatever the platform, decide what you’ll lose. If a churned customer moves back to “Lead”, they’ll look like a new prospect in acquisition reports. A separate “Former customer” stage often works better, because it keeps the history visible and gives you a clean audience for win-back.
Keep the transition dates. Reports about conversion and time-in-stage depend on knowing when each record entered and left each stage, so don’t overwrite those dates when someone moves back.
Why lifecycle stages go wrong
When we find inaccurate stages, the cause is rarely a single bad workflow. More often it’s some combination of these:
Too many writers. Forms set a default stage, imports set another, an integration syncs one from the ecommerce platform, and three workflows update it on different conditions. There’s no full list anywhere.
Definitions that were never agreed. Marketing counts an MQL by score. Sales thinks an MQL means someone asked for a call. Both are reasonable, and the funnel report will cause an argument every month until they pick one.
Bulk imports. An event attendee list is imported with everyone set to Lead, or a migration from an old CRM marks every record as Customer because that’s what the old field said.
No backward path. Stages only ever go up, so the “Opportunity” count grows forever and the “Customer” count includes people who left years ago.
Company-level sync. Some platforms copy the company’s stage to every contact at that company. That’s how an accounts-payable clerk ends up in your customer advocacy campaign.
The fix starts with a list of everything that writes to the stage field, compared against your written rules. If you want the wider method for that, our guide to auditing your CRM covers it step by step.
How lifecycle stages work on different platforms
The concept travels. The mechanics don’t.
- HubSpot has a default Lifecycle stage property on contacts and companies, with automatic forward movement from forms, deals and company sync. See HubSpot lifecycle stages.
- Salesforce and Zoho separate leads from contacts at the object level. A lead is converted into a contact, account and (optionally) an opportunity, so part of your lifecycle lives in which object a record is in, and part lives in fields you define.
- Pipedrive centers on deals and pipelines, with a separate Leads Inbox for unqualified leads. Person-level lifecycle usually needs a custom field.
- Klaviyo has no lifecycle field. You model stages with segments built on order history and profile properties, for example “placed exactly one order, last order within 90 days”. That works well, but the definition lives inside each segment, so it has to be documented elsewhere.
When two systems both hold a lifecycle idea, say HubSpot for sales and Klaviyo for ecommerce email, decide which system owns the stage and which one only reads it. Two systems that both calculate “customer” will disagree within a month.
Reporting on lifecycle stages
Three reports tell you most of what you need.
Stage counts over time. How many records are in each stage at the end of each month. Big unexplained jumps usually mean an import or a misfiring workflow.
Conversion between stages. Of the records that entered MQL in March, how many reached Opportunity, and how many went back to Lead? This needs entry dates per stage, which is why keeping transition dates matters.
Time in stage. How long records sit before moving. A long average in one stage points to a handoff problem, often between marketing and sales, or between quote and booking.
If these reports look wrong, check the stage definitions before rebuilding the reports. A report can only be as accurate as the field it counts.
Are your stages ready? A quick check
- Each stage has a written entry rule, exit rule, owner and expected action.
- Sales, marketing and whoever owns customer success have agreed the definitions.
- Lifecycle stage, deal stage and status are separate fields with separate jobs.
- Every form, import, integration and workflow that writes to the stage is listed.
- Lost deals, rejected leads and churned customers have a defined path.
- Transition dates are kept and used by reports.
What’s the difference between a lifecycle stage and a lead status?
A lifecycle stage describes the overall relationship, such as lead or customer, and changes rarely. A lead status describes what sales is doing right now, such as attempted to contact, and changes often. Mixing them in one field breaks both.
Should every contact have a lifecycle stage?
Every contact you market or sell to should. Partners, suppliers, job applicants and internal staff are better kept in a separate “other” value or excluded entirely, so they don’t distort funnel numbers.
Can a company and its contacts have different stages?
Yes, and often they should. A company can be a customer while a newly added contact there is still a lead who has never used your product. Decide deliberately whether contact stages inherit from the company or are set individually.
How often should we review our lifecycle definitions?
Look at them whenever the business changes how it sells, such as a new product, a new sales motion or a pricing change, and at least once a year otherwise. Definitions drift quietly when they have no owner.
If you’re designing stages from scratch or reworking ones that have drifted, the CRM Lifecycle Strategy service covers the definitions, the rules and how they connect to automation.