Customer Lifecycle Mapping: Plan States, Triggers and Messages Before You Automate

What is customer lifecycle mapping?

Customer lifecycle mapping is the process of writing down every state a customer can be in, the events that move them between states, and what your business does at each point, in enough detail that it can be built in a CRM and measured. The result is a lifecycle map: a table or diagram that marketing, sales, customer success and whoever builds your automation can all work from.

It sits between strategy and setup. Strategy says “we want more repeat purchases”. A lifecycle map says “a first-time buyer becomes a repeat buyer when a second order is placed; between day 7 and day 45 after the first order we send three emails based on what they bought; if there’s no second order by day 60 they move to an at-risk segment and get a different message; we measure second-order rate by cohort.” That second version can be built and tested. The first one can’t.

How is a lifecycle map different from a customer journey map?

A customer journey map describes the experience from the customer’s side: what they’re thinking, feeling and trying to do at each step. A lifecycle map describes the operation from the business side: what data you hold, what state the record is in, what triggers a change, and what the system or a person does next.

Both are useful. Journey maps are good for spotting where the experience is frustrating. Lifecycle maps are what you need when you’re about to build automation, because automation can only act on things the system can detect. “Customer feels unsure about the product” is a journey insight. “Customer hasn’t logged in for 14 days since signup” is something a CRM can act on.

In practice, start from what the journey work tells you, then translate each insight into states and events you can actually observe.

Who should be involved

Lifecycle maps fail when one team writes them alone. Marketing maps the pre-purchase stages in detail and leaves onboarding and renewal as a single box. Sales maps the pipeline and ignores what happens after the deal closes.

Get at least one person from each team that touches customers into the same session: marketing, sales, customer success or support, and someone who knows the data, often a CRM admin or ops person. That last role matters. They’re the one who’ll say “we don’t actually capture that” before you build a plan around it.

Step 1: List the states

Write down every state a customer can be in, from first contact to after they leave. Don’t start from your CRM’s current stages; start from the business, then compare later.

A B2B example: Subscriber, Lead, Qualified lead, Opportunity, New customer (first 90 days), Active customer, Renewal due, At risk, Former customer.

An ecommerce example: Subscriber, First-time buyer, Repeat buyer, VIP, Lapsing, Lapsed, Win-back.

Notice that both include states after the first purchase. Most lifecycle maps we’re asked to review are detailed up to the sale and almost empty after it, which is usually where the easiest revenue is.

For each state, write one sentence describing who is in it. If you need more than one sentence, you may have two states. Our guide to CRM lifecycle stages goes deeper on defining them.

Step 2: Identify the events that move people

For every move between states, name the event that causes it and where the data comes from:

• Subscriber to Lead: submits a form other than newsletter signup. Source: website forms.
• Opportunity to New customer: deal closed won. Source: CRM deal record.
• First-time buyer to Repeat buyer: places a second order. Source: ecommerce platform order data.
• Active customer to At risk: no login in 30 days, or support tickets marked negative. Source: product usage data and helpdesk.

This step tells you quickly which parts of the map you can automate and which you can’t. If “At risk” depends on product usage and that data never reaches your CRM, the state exists on paper only. Either you get the data in, through a native integration, an integration platform or the API, or you change the definition to something you can detect.

Include backward and sideways moves too. Lost deals, canceled orders, refunds and downgrades all change a customer’s state, and they’re usually the moves that were never planned.

Step 3: Write the business rules

Events alone don’t decide what happens. Rules do. For each transition, write the conditions and exceptions in plain language:

Rules like these are where most automation goes wrong when they’re skipped. The welcome flow that tells existing customers about a first-order discount, or the post-purchase email sent after a refund, both come from missing exceptions.

Step 4: Decide the actions at each state

For each state, list what should happen and who or what does it:

• Messages: which emails, SMS or in-app messages, in what order and timing
• Sales or success actions: calls, tasks, check-ins, reviews
• Data actions: fields to update, segments to join or leave, owners to assign
• Suppressions: what this state should stop receiving

Suppression is easy to overlook. Someone who becomes a customer should leave acquisition nurture. Someone in an open support escalation probably shouldn’t get a review request this week.

Keep the actions short at this stage. A row like “New customer: onboarding email series (5 emails over 21 days), CSM call at day 14, exit acquisition flows” is enough. Detailed copy and settings come later.

Step 5: Choose a measure for each state

Every state should have one number that tells you whether the actions are working. Usually it’s the conversion to the next state, or the time it takes.

• First-time buyer: percentage placing a second order within 90 days
• Lead: percentage reaching Qualified within 30 days
• New customer: percentage completing onboarding milestones
• Lapsed: percentage re-purchasing after win-back

Measure by cohort where you can (everyone who became a first-time buyer in March), not just in total. Cohorts show whether a change you made actually improved things.

Step 6: Mark the gaps

Now go through the map and mark each row:

• Covered: rule defined, automation built, measure in place
• Partial: something happens, but rules or measurement are missing
• Gap: nothing happens
• Blocked: can’t be built because the data doesn’t exist yet

This is the most useful view the map produces. It turns a document into a backlog. The gaps we see most often are second-purchase follow-up in ecommerce, onboarding in B2B, a path for lost deals, and anything to do with former customers.

If you want a quicker first pass, the Lifecycle Coverage Check uses a simpler version of this: it asks whether each stage for your business model is defined and automated, defined but handled manually, or not clearly defined, then gives a coverage score and lists the stages that need work.

An example row, fully filled in

Here’s a single row from an ecommerce map, written so someone could build it:

• State: First-time buyer
• Who’s in it: placed exactly one non-refunded order in the last 60 days
• Entry event: order placed (ecommerce platform)
• Exit events: second order (to Repeat buyer); 60 days with no second order (to Lapsing); full refund (back to Subscriber)
• Rules: exclude gift orders and wholesale customers; sample-only orders go to a separate path
• Actions: order confirmation and shipping updates (transactional); product-care email at delivery; cross-sell based on category at day 14; review request at day 21 if no open support ticket; exit any welcome or browse abandonment flows
• Owner: ecommerce marketing
• Measure: second-order rate within 90 days, by monthly cohort
• Status: Partial (cross-sell not built, no refund exit)

In Klaviyo, most of this becomes a post-purchase flow with conditional splits and flow filters. Our Klaviyo post-purchase flow guide covers that build.

From map to automation

With gaps marked, prioritize. We usually suggest this order: fix anything currently sending the wrong message, then fill gaps in states with the most people or the most revenue at stake, then build the rest.

For each item, write a short requirement before anyone opens the automation builder: trigger, conditions, actions, fields written, exits and measure. The CRM automation requirements template is set up for this. It keeps builds consistent and gives you something to test against.

Keeping the map alive

A lifecycle map goes stale the moment the business changes and the map doesn’t. Give it an owner, store it where all teams can see it, and review it whenever you launch a product, change pricing, add a channel or rebuild an automation. A quick quarterly check that the “Status” column is still accurate is usually enough.

You can build your first version in our customer lifecycle map template, which has a row structure like the example above.

If you’d like help building the map and turning it into working automation, our Lifecycle Automation and CRM Lifecycle Strategy services start from exactly this exercise.