Lifecycle state machines for customer automation: explicit states with inferred transitions

1Context and motivation

Customers now reach a firm through many touch points across channels and media, and their journey runs through stages before, during and after a purchase rather than along a single funnel¹. A customer may browse on a phone without signing in, buy weeks later on a computer, lapse, come back after an offer, and lapse again. Marketing automation usually represents this with static segments ("new", "active", "dormant") recomputed from fixed rules such as a recency threshold. Such segments describe a snapshot. They do not say how customers move between segments, how sure the assignment is, or what an intervention is likely to change.

We describe a design for lifecycle state machines: each customer is in exactly one lifecycle state, transitions between states are explicit and modelled, and the state is passed to the systems that decide whom to contact and how. This paper describes the design and the reasons for it. It does not report effects, because we have not measured any.

2Lifecycle as a state machine

The design separates two things that segment rules usually mix.

The first is a state schema with allowed transitions, written by people. The core schema is: prospect, new, activated, steady, at risk, dormant, recovered and churned. The schema says which transitions are possible (a prospect cannot become recovered without first being a customer) and which events can cause them. Statecharts extend ordinary state diagrams with hierarchy, concurrency and communication, which keeps a large state space readable². We use hierarchy so that a business can refine a core state into substates (for example, a subscription business can split "at risk" into "renewal window" and "payment failed") without changing the states that other systems read, and concurrency so that lifecycle state and channel consent state are tracked side by side rather than multiplied together.

The second is a probabilistic model that infers which state each customer is in and how likely each transition is. Customer relationships have long been modelled as Markov chains, in which a customer moves between states with given probabilities and lifetime value follows from the chain³. When the states are not directly observed, a hidden Markov model treats them as latent and the observed events as noisy signals of them⁴.

The two parts have different owners. The schema is a contract that marketing, data science and operations share; changing it is a reviewed decision. The model is retrained as data arrive.

3Related models

Several bodies of work inform the design.

• Hidden Markov models of relationships. A nonhomogeneous hidden Markov model can capture latent relationship states, let transition probabilities depend on time-varying covariates such as customer-firm encounters, and so segment customers dynamically and estimate how interactions shift them between states⁵. A related model links usage and renewal through a common latent variable whose dynamics follow a hidden Markov model⁶. In email marketing, a hidden Markov and copula model of one retailer's customers found that customers active in opening emails were not necessarily active in purchasing, and the reverse⁷, which argues for keeping engagement and purchase signals separate in state inference.
• Customer-base analysis. The Pareto/NBD model computes, from the number and timing of past transactions, the probability that a customer is still active⁸; the BG/NBD model is a simpler alternative that is easier to estimate⁹. These models give the "alive or not" distinction a probabilistic footing, which the design uses for the boundary between dormant and churned in non-contractual settings.
• RFM and lifetime value. Recency, frequency and monetary value can be linked formally to lifetime value through iso-value curves, so that customers with different histories but similar future value are grouped together¹⁰. Reviews of lifetime value models cover their use for segmentation and for allocating resources across acquisition, retention and cross-selling¹¹.

Lifecycle state machines generalise RFM segments in one specific way: they add the transitions, and with them a model of where a customer is heading.

4Architecture

The engine has five parts.

4.1State schema

The core states are listed above. Each state has a written definition, an owner, and the decisions it may feed. Businesses can add substates through the hierarchy; they cannot remove core states, so that reports and downstream systems keep a stable vocabulary.

4.2State inference

Inputs are recency, frequency and monetary value; engagement by channel, with engagement and purchase kept as separate signals; session depth; device; category mix; and region. Two families of model are candidates: gradient-boosted trees on summary features¹², and recurrent sequence models over the event history, which can carry information across long gaps between events¹³. Where labelled states are not available, a hidden Markov model infers them as latent⁵. The output is the current state, a confidence, and the full distribution over states. Assignments below a confidence threshold are marked as uncertain, and downstream systems treat them conservatively.

4.3Transition model

The transition model estimates the probability of moving from each state to each other state in the next period, given context (region, season, recent interventions). It supports three uses: predicting a customer's likely trajectory, computing state-specific lifetime value from the chain³, and, when interventions are randomised, estimating how an intervention changes the transition probabilities⁵.

4.4Integration with decisions

The state is an input to targeting, not the targeting rule itself. A field study of retention campaigns found that customers at the highest risk of churning were not necessarily the right targets: what mattered was how sensitive a customer was to the intervention, and targeting on that sensitivity was more effective than targeting on risk¹⁴. In this design, then, "at risk" tells a decision system where to look, and a response model estimated from randomised holdouts tells it whom to contact. The engine publishes state distributions and transition matrices by region and cohort, so that operators can read the population in the same terms the models use.

4.5Regional and vertical calibration

The same state name can mean different things in different businesses: a gap between purchases that signals lapse for a weekly grocery buyer is normal for a buyer of furniture. The design therefore sets thresholds per vertical and region from the data, rather than copying one rule everywhere, and reviews the resulting state distributions before release. We make no claim here about how any region or vertical behaves.

Table 1 maps each component to the problem it addresses and the evidence behind it.

Component	Problem it addresses	Evidence
Hierarchical state schema with allowed transitions	Segment rules grow unreadable and inconsistent	2
Markov chain over lifecycle states	Segments say nothing about where customers are heading	3
Hidden states inferred from events	States are not directly observed	4, 5
Probability that a customer is still active	Fixed recency cut-offs misclassify slow buyers	8, 9
Separate engagement and purchase signals	Opening emails is not the same as buying	7, 6
State-specific lifetime value	Resources are allocated without a value basis	10, 11
Targeting on response, informed by state	Highest-risk customers are not always the right targets	14

Source: our design, with the works cited in the table.

5A worked transition model

Table 2 shows the kind of calculation the transition model supports, with three states and illustrative monthly transition probabilities. The inputs are illustrative, not estimates.

From state	To active (input)	To at risk (input)	To dormant (input)	Dormant after two months (computed)
Active	0.80	0.15	0.05	0.1300
At risk	0.30	0.40	0.30	0.4050
Dormant	0.05	0.05	0.90	0.8275

Source: Worked model; inputs in the table.

The last column is the two-step probability, the sum over intermediate states of the probability of reaching that state in month one times its probability of moving to dormant in month two. For a customer who starts active: 0.80 × 0.05 + 0.15 × 0.30 + 0.05 × 0.90 = 0.1300. For a customer who starts at risk: 0.30 × 0.05 + 0.40 × 0.30 + 0.30 × 0.90 = 0.4050. The table illustrates two points about the design. A customer flagged at risk this month is, under these inputs, about three times as likely to be dormant in two months as an active one, which is why the state is worth tracking. And the decision to intervene does not follow from that probability alone: it depends on how much an intervention would change the at-risk row, which only a randomised test can estimate¹⁴.

6Evaluation protocol

Before any claim about outcomes could be made, the engine would need three kinds of evidence.

• State validity. Where ground truth exists (a cancelled subscription, a closed account), compare inferred states against it. Where it does not, check that inferred states predict held-out future behaviour: purchase in the next period, unsubscribes, return to activity.
• Transition calibration. Predicted transition probabilities should match observed transition frequencies on held-out periods, by region and cohort.
• Decision value. Randomised tests compare state-informed targeting with the existing rule-based segments, on incremental purchases and contact volume, with unsubscribe and complaint rates as guardrails.

7Fairness, privacy and transparency

Lifecycle labels are not neutral. A customer labelled dormant may receive fewer offers; a region with sparse data may be labelled at risk more often simply because the model is less certain there. Where past investment in a cohort was low, its observed engagement is low too, and a model trained on that history can carry the gap forward. The design responds with three rules: labels below a confidence threshold are not used to withhold benefits, state distributions are reviewed by region and cohort before release, and features that may act as proxies for protected attributes are excluded or reviewed.

On privacy, inference uses behavioural signals the customer's consent covers, with data minimised to what state inference needs. On transparency, the state and the reason for it are visible to the merchant, and a customer-facing explanation of why they received a message refers to observable behaviour, not to a model score.

8Limitations

• No measurements. We have not measured the accuracy of state inference or the effect of state-informed automation on any outcome. The benefits implied above are hypotheses for the evaluation protocol.
• Discrete states are a simplification. Some behaviour varies continuously, and a fixed schema can hide differences within a state.
• Stationarity. Transition probabilities change with seasons, prices and the firm's own interventions, so a transition model fitted on one period may not hold in the next.
• Interventions confound transitions. Observed transitions already reflect past campaigns; separating natural transitions from campaign effects requires randomised holdouts.
• Calibration effort. Per-vertical and per-region thresholds need data that small merchants and new regions may not have.

9Conclusion

We have described a design for lifecycle state machines: a human-owned schema of states and allowed transitions, a probabilistic model that infers states and predicts transitions from events, and an interface that passes state to decision systems which target on estimated response. Each part rests on published work summarised in Table 1. The next step is to fit the engine to one business's data, test state validity and calibration on held-out periods, and only then compare state-informed and rule-based targeting in a randomised test.