A prospect requests a proposal in March. The deal is created, the contact’s lifecycle stage becomes Opportunity, and in April the deal is lost because the budget was frozen. Nothing resets the stage. In November the same person comes back, reads three pricing pages and downloads a buying guide. Your lead scoring workflow only enrolls contacts whose stage is Lead, so it never sees them. The nurture sequence excludes opportunities. As far as the CRM is concerned, this person is still in an active deal that closed seven months ago, so no one follows up.
Every workflow in that story behaved as built. Two rules were missing: one for moving a contact back after a lost deal, and one for recognizing them when they returned.
What is CRM lifecycle strategy?
CRM lifecycle strategy is the design of customer states and the transitions between them. For every state it defines what someone in that state means to the business, what puts them there, what takes them out, and where they can go next, including backward.
It is narrower and deeper than a CRM strategy, which looks at the whole customer journey and the business goals behind it. And it comes before lifecycle automation, which builds the journeys that run inside each state. Automation built on vague states behaves vaguely. This is the work that makes the states precise.
States and transitions
Think of the lifecycle as a state machine rather than a funnel. A funnel only goes one way and only narrows. Real customers stall, slip back, go quiet, leave and return. Every one of those movements is a transition, and each needs a rule.
Entry criteria
What has to be true for someone to enter a state. “Became a lead” is not a rule. “Submitted a form that includes a work email and a company name, and is not already a customer or an open opportunity” is. Entry criteria should be written against data the system can actually see, not judgments that live in a rep’s head.
Exit criteria
What ends a state, and where the person goes. This is the half most systems skip. Without exit criteria, states only accumulate, and counts like “Qualified leads” grow forever because records never leave.
Lifecycle progression
The normal forward path, and who owns each step. We pay most attention to the handoff points. When a lead becomes qualified, who is notified, how quickly must they act, and what happens if they don’t? The answer is often a rule about time as much as about data.
Backward movement
When someone should move back a state, and what that reset changes. A lost deal, a disqualified lead, a customer whose contract ended. Some platforms make this deliberately awkward. HubSpot, for instance, moves lifecycle stage forward on its own, and moving a contact backward in a workflow means clearing the stage first and then setting the earlier value. That’s a good reason to decide the rule once, carefully, and automate it.
Re-entry
What happens when someone returns to a state they’ve been in before. Should a former customer who fills in a contact form be treated as a new lead, routed to their old account manager, or placed in a separate “returning” state? Should they re-enter the welcome sequence? Re-entry rules decide whether returning people get the right experience or a confusing repeat of the first one.
Customer states
“Customer” is rarely one state. A first-time buyer, an established client in year three and a customer in a renewal window all need different treatment. We split the customer stage only where the business genuinely acts differently, because every extra state adds rules to maintain.
Inactive states
“Inactive” usually hides several different situations, and lumping them together causes real problems.
Picture a home-goods store with one segment called “Inactive” built from all four. Its win-back email says “Welcome back, here’s 15% off your next order” and goes to thousands of people who have never placed a first one.
Reactivation
The rules for bringing someone back from an inactive state, and what counts as reactivated. Is an open enough? A click? A purchase? Where does a reactivated customer land: back in Customer, or in a watch state for a period before they’re treated as fully active again? Reactivation also needs a stopping rule. People who don’t respond to a sunset sequence should be suppressed, which protects deliverability as much as it saves effort.
Do your lifecycle stages only ever move forward?
Share how your states are set up today. We'll map the transitions that exist, the ones that are missing, and the rules each one needs.
What a state definition looks like
Each state gets a short, fixed definition your team can check any record against. Here is a typical one for a B2B services firm:
- State: At risk
- Meaning: An active client showing signs they may not renew.
- Entry: Active client and any of: no project activity for 60 days, a support ticket open longer than 10 business days, or renewal date within 90 days with no renewal conversation logged.
- Exit forward: Renewal signed, back to Customer.
- Exit backward: Contract end date passes without renewal, moves to Lapsed.
- Owner: Account manager, with the head of client services notified on entry.
- On entry: Pause promotional email and create a review task due within five business days.
Short definitions like this end a lot of arguments. When sales and customer success disagree about whether an account is at risk, they check the record against the rule instead of against their own sense of it.
Deliverables
- A state model: every state, its meaning, entry and exit criteria, owner and allowed transitions.
- A transition map showing forward, backward, re-entry and reactivation paths, and what triggers each.
- Definitions for each inactive state, with the time windows and data that decide them.
- Platform mapping: which property, list, segment or tag holds each state on your CRM or marketing platform, and which system is the source of truth when there are two.
- Reporting implications: which conversion rates and stage durations the model makes measurable, and what history needs to be recorded to measure them.
If you’re working in HubSpot, our guide to HubSpot lifecycle stages covers the platform side in detail. For a general introduction, see CRM lifecycle stages.
From definition to build
The state model is designed to be built from. Some teams implement it themselves. Others hand it to us for lifecycle automation, which designs the journeys inside each state, or CRM implementation, which configures properties, workflows and reports around it. When a build team needs formal specs with acceptance tests, the model feeds directly into requirements documentation.
Lifecycle strategy is scoped after a first conversation and quoted as a fixed price. Starting prices for related services are on our pricing page.
What’s the difference between lifecycle stages and pipeline stages?
Lifecycle stages describe a person’s or company’s overall relationship with you. Pipeline stages describe the progress of one specific deal, order or ticket. A single customer can have several deals in different pipeline stages while holding one lifecycle state. Treating them as the same thing is where a lot of unreliable reporting starts.
How many lifecycle states should we have?
As few as the business genuinely acts on. If two states trigger exactly the same treatment and aren’t reported on separately, they’re probably one state. For many businesses that ends up somewhere around five to nine.
Should contacts ever move backward?
Yes, when the business would treat them differently. A lost opportunity who stays marked as an opportunity is excluded from nurture and pollutes pipeline reporting. The key is to record the backward move and the reason, so history isn’t lost.
How do you handle a contact who belongs to two states at once?
Usually it means two different things are being tracked in one field. A person can be a customer of one product and a prospect for another. We separate account-level and contact-level states, or product-level status, so each field answers one question.
Can you redesign the lifecycle in a CRM that’s already in use?
Yes. It’s the more common situation. It needs a migration plan for existing records and a check on every workflow and report that reads the old stages. If the current system is very tangled, a CRM audit first can save time.
Does this apply to ecommerce brands?
Yes. Ecommerce lifecycles are often simpler at the top and more detailed after purchase: first-time buyer, repeat buyer, lapsed, win-back. The same state-and-transition thinking applies.