Building a Connected Customer Marketing Lifecycle with Marketing Cloud Next

#The problem, as it actually presented

The brief is almost always some version of "we want a customer lifecycle". It arrives after a leadership offsite, it is usually accompanied by a diagram with four arrows in a circle, and it is genuinely the right ambition.

What is already in place, when you look, is a campaign calendar. Twelve months of dates the business chose, hung off trading periods, product launches, stock clearance and the loyalty programme's anniversary. Each entry has an audience built by whoever was free that week, a creative, a send time and a result. It is a competent operation and it is not a lifecycle, because nothing in it is driven by anything the customer did.

Underneath, the harder problem. The retailer had four places that believed they knew the customer. Ecommerce held an account with an order history. The loyalty programme held a membership with a points balance and a tier. Service held a Contact with a case history. The email platform held a subscriber list assembled over years from sign-up forms, competition entries and one acquired file nobody wanted to discuss.

The same person existed in all four. Nothing joined them reliably.

The consequences are ordinary and they compound. A loyalty member gets a first-purchase welcome because ecommerce did not recognise them. Someone who complained about a delayed order on Tuesday receives a win-back on Friday, because the win-back audience was built from purchase recency and purchase recency does not know about complaints. A customer who unsubscribed from one brand's list keeps hearing from the other two, which is legally defensible in some readings and reputationally indefensible in all of them.

#Identity decides everything downstream

The first thing we designed was not a journey. It was the answer to a single question: what makes two records the same person for marketing purposes.

That question sounds like a data-quality task and it is a design decision with consequences that reach the customer. Resolve too loosely and you merge two people, which means one household member inherits another's preferences, consent and purchase history. Resolve too strictly and the lifecycle addresses fragments rather than people, so the same customer sits at three different stages simultaneously and receives all three.

We resolved identity in Data 360 before any journey existed. The unified profile draws from the ecommerce customer id, the loyalty membership number, the Service Cloud Contact and the email address, with a documented precedence order and a deliberate distinction between a confident match and a probable one.

The part worth stating plainly: the marketing definition of the same person is not the billing definition, and it is not the service definition. Two people sharing a delivery address are one delivery and two customers. A single email address used by a couple is one contact point and, for consent purposes, one permission. We wrote those rules down in language a non-technical person could argue with, because the people who could tell us when a rule was wrong were not the people who could read the configuration.

A broken identity graph does not fail loudly. The journey runs, the send completes, the report shows a number. What happens is that the wrong person receives a well-crafted, correctly timed message about somebody else's relationship with the business, and the only signal you get is a slow drift in complaints that nobody attributes to the graph.

#Consent as a model, not a flag

The second foundation is the one most often deferred, and the only one on this list where getting it wrong carries a regulatory cost rather than a delivery cost.

The retailer had an unsubscribe flag per channel per system. That is not a consent model. It cannot answer what a person was permitted to receive on a date in the past, it cannot distinguish a topic opt-out from a global suppression, and it has no idea where the permission came from.

We modelled consent with four properties, in this order.

Where it lives. One authoritative place, with the marketing platform reading it rather than holding its own version. Three systems each holding a preference is three consent models, and a regulator asking which one applied in March will get three answers.

What each preference means. A channel permission, a topic subscription, a frequency preference and a global suppression are four different things, and teams routinely implement one while describing it as another. We wrote the definitions in plain language and had them read by the contact centre team, because they are the people who field the complaint when the definition and the customer's understanding diverge.

How a withdrawal propagates. This is where the common failure lives. A withdrawal correctly blocks new sends and does not remove the person from journeys they are already inside, so they receive the remaining steps of a sequence they explicitly left. Exit on consent withdrawal was designed into every journey before any journey was built.

What the history is. Consent carries its capture source and timestamp, and the model stores state over time rather than current state only. Without that, an audit question about a past date is unanswerable, and unanswerable is treated as non-compliant.

#A campaign calendar is not a lifecycle

With identity and consent settled, the difference between what the retailer had and what it wanted became straightforward to describe.

A campaign calendar is organised around dates the business chose. A lifecycle is organised around states the customer is in. The calendar asks who should receive the September promotion. The lifecycle asks what should happen to somebody who has just made a first purchase, or who has not bought in two category-appropriate cycles, or whose loyalty tier is about to lapse.

Both are legitimate. A retailer that abandons the trading calendar to become purely behavioural has thrown away the thing that actually drives its revenue. The design we built runs both, with the lifecycle as the persistent layer and the calendar as an overlay, and the suppression rules deciding which wins when they collide on a Tuesday.

The reframe that lands with a marketing team is this: the calendar is what the business is doing, the lifecycle is what the customer is experiencing, and only one of those two things the customer can perceive.

#Which journeys earn their maintenance cost

The instinct on a new platform is a journey per campaign. It demonstrates well, it is quick, and it produces an estate that nobody can maintain, because near-duplicate journeys are cheap to create and can only be removed by rebuilding them.

We applied one test before agreeing to any journey. What varies, and is the variation structural or content? If two candidates have the same shape and differ only in copy, timing or audience filter, they are one journey with parameters. If they genuinely branch differently, they are two.

Most requests failed the test, and the honest answer was usually that the requester wanted a campaign rather than automation.

What survived was a small set. Onboarding, parameterised by brand, acquisition source and whether the person is a loyalty member. Post-purchase, parameterised by category, because the useful interval after a homewares purchase is not the useful interval after a consumable. Lapse and win-back, parameterised by category cycle rather than a single global recency threshold. Re-permission, for people whose consent is old enough to be doubtful.

Everything else became a single send with a clear audience. A seasonal promotion that runs once a year is not automation. Building it as a journey means maintaining it for eleven months in which it does nothing except get out of date and confuse the next person who reads the estate.

#Suppression, frequency and the customer in three journeys

This is the part that is ugly in practice and gets designed last, which is why customer experience degrades exactly as the estate matures.

Every journey, considered alone, is reasonable. The problem is the customer who qualifies for three at once: they made a first purchase, they are approaching a tier lapse, and they abandoned a cart yesterday. Three well-designed journeys each decide independently to send, and the customer receives three messages in a day from an organisation that believes it is being helpful.

We built suppression as a layer above the journeys rather than as logic inside them. It reads three things the marketing team does not own.

Service state, from the open Service Cloud Case and recent complaint history. A customer in an unresolved dispute is suppressed from promotional and win-back sends entirely. Transactional and service messages continue, because those are the ones they are waiting for.

Frequency history, per channel, across every journey and every calendar send. Capping inside a single journey is easy and worthless, because the customer counts messages across the whole organisation rather than per programme.

Journey membership and priority. Where two journeys both qualify, one order decides, and it is written down in one place. Onboarding outranks promotion. Service-triggered communication outranks both. Win-back sits at the bottom, because it is the least urgent and the most damaging when mistimed.

The design principle underneath: suppression answers a different question from targeting. Targeting asks whether this person is a good fit for this message. Suppression asks whether we should be speaking to this person at all right now. Teams that only build the first end up with a technically excellent message sent at the worst possible moment.

#The handover to service

The rule that generated the most useful conversation was the simplest one to state. A customer with an open complaint does not receive a win-back.

Implementing it meant marketing consuming service state, which meant agreeing what an open case actually means for marketing purposes. Not every case is a complaint. A delivery query resolved in an hour should not suppress a month of communication. A returns dispute escalated twice should suppress rather more than promotional email.

We settled on case type and case age rather than a simple open or closed test, with a defined quiet period after resolution rather than an immediate resumption. The quiet period was the contested part, and the argument that won it was that resuming promotion the morning after a complaint closes reads as an organisation that was waiting for permission rather than one that cared.

The reverse direction matters too. Engagement signals flow back so that service agents can see the customer is mid-onboarding, or has just received a win-back offer, before they open the conversation. An agent surprised by an offer the customer is quoting at them is an avoidable failure.

#Implementation, in order

The sequence mattered more than any individual component.

Identity first, with nothing built on top of it. Resolution rules agreed, precedence documented, ambiguous matches routed to a review queue rather than merged automatically. Confident automatic merging of near-matches is how one person inherits another's consent, and that error is far more expensive than a daily review task.

Consent second, in parallel with identity where the two teams allowed it. Definitions written, propagation rules specified, history model in place before a single send was configured.

Then naming and folder governance, which takes an afternoon and is the cheapest decision in the whole programme. Assets accumulate faster than anyone reorganises them, and the estate only needs to reach a few hundred before people build a sixth welcome email rather than risk editing one of the five that exist.

Then the journeys, smallest viable set first, with exit criteria designed before entry criteria. What happens when the person converts halfway through, complains, withdraws consent, or qualifies for a higher priority journey at the same moment.

Then suppression and frequency capping, before go-live, not after the first complaint.

Measurement definitions were settled alongside the journeys rather than after them, because a metric defined after launch cannot be applied backwards and the first period measured differently is a permanent gap in the history.

#The decisions that were contested

Not merging the brand lists. The tidier design has one subscriber base with brand as a preference. The business case against it was that the brands have genuinely different audiences with different expectations, and the consent captured on one brand's sign-up form does not honestly cover the others. We kept them separate at the permission layer and unified at the profile layer, which is more work and is the version that survives a complaint.

Suppressing win-back on open cases, despite the revenue argument. The counter-argument made in the room was that win-back is a revenue programme and suppression reduces the addressable audience. It is true. The response that carried was that the suppressed population is precisely the group most likely to react badly, so the revenue removed is largely notional and the reputational cost is not.

Not turning on assisted content generation in the first phase. There was appetite for Agentforce Marketing to be generating variants early. We argued to wait, on the grounds that anything that personalises reads the profile, and the profile was mid-reconstruction. Generating personalised content from a profile you do not yet trust produces a confident, fluent, wrong message, which is worse than a generic right one.

Keeping the trading calendar. Some of the room wanted to declare the calendar obsolete. It is the revenue engine. The design accommodates it rather than replacing it, and the suppression layer is what makes the two coexist.

#What changes

The outcomes worth claiming from this design are operational, and they follow from the decisions rather than from effort.

The second-order effect is the one leaders notice. The planning conversation changes from which campaigns are running next quarter to what should happen to a customer in a given state, and the second question has an answer that does not expire.

#What we would tell you before starting

Do not start with the journeys. Every version of this programme that goes badly goes badly because journey building started while the identity rules were still moving, and a journey built against a shifting definition does not break, it just quietly sends to a slightly different population until the reporting stops reconciling.

Settle who the customer is, settle what you are permitted to say to them, and be prepared for both of those to take longer than the build. They are unglamorous, they demonstrate badly, and they are the entire difference between a lifecycle and a calendar with better branding.

One more thing, honestly. If you sell one product, through one channel, to people who are only ever known by their email address, most of this is over-engineering. This design earns its cost when the same person is genuinely knowable through several systems and the organisation has more than one reason to contact them. That is the condition that makes the coordination real, and coordination is what the whole architecture is for.