# Building a Connected Customer Marketing Lifecycle with Marketing Cloud Next > A multi-brand retailer that could describe every campaign it ran and could not describe a single customer, because the same person existed four times across ecommerce, loyalty, service and email. - Source: https://synconai.com/case-studies/connected-customer-marketing-lifecycle - Publisher: SynconAI (https://synconai.com) - Type: Case study - Evidence: Illustrative scenario. This describes how SynconAI approaches the problem. It is not an account of one named customer, and no outcome is claimed as measured. - Organisation: A multi-brand retailer with an owned ecommerce channel, a loyalty programme and a shared contact centre - Industry: Consumer Goods & Retail - Products: Marketing Cloud Next, Data 360, Sales Cloud, Service Cloud - Service: Marketing Cloud Next (https://synconai.com/salesforce-marketing-cloud-next) - Reading time: 12 minutes ## In short A multi-brand retailer with four disconnected records per customer resolved identity in Data 360 first, modelled consent as an object with history rather than an unsubscribe flag, then replaced a campaign calendar with a small set of parameterised lifecycle journeys. A central suppression layer reading Service Cloud case state decides whether any message sends, so a customer with an open complaint receives no win-back. ## Key points - A lifecycle is a data problem before it is a campaign problem. Resolve identity across ecommerce, loyalty, service and email first, because every journey addresses a person rather than an address. - Consent belongs in a model with its own history, not in a flag on a contact. If you can only report the current state, you cannot answer what was permitted on a date in the past. - A campaign calendar is a list of dates the business chose. A lifecycle is a set of states the customer is in. Most teams have the first and are asking for the second. - Suppression and frequency capping have to be decided in one place. Left inside each journey, the customer experience becomes the sum of choices nobody made together. ## The lifecycle, and the data each stage depends on A customer lifecycle drawn as the data it rests on rather than as a campaign sequence. Identity resolution runs first, because every later stage addresses a person rather than an email address. Consent and preference sit alongside it as a modelled object with its own history, not as a flag on a contact. Acquisition, onboarding, engagement and retention or win-back each read those two foundations, and each writes signals back to them. Cutting across all four stages is a suppression layer that reads service state, frequency history and journey membership, so the decision about whether to send at all is made in one place rather than independently inside every journey. ### 1. Identity resolution - Data 360 unified profile - Ecommerce customer id - Loyalty membership number - Service Cloud Contact - Email address and hashed phone Decides who the person is before anything decides what to say to them. Every downstream stage inherits this answer, including the wrong one. ### 2. Consent and preference - Channel permission - Topic subscription - Frequency preference - Global suppression - Consent capture source and timestamp Modelled as its own object with a history, so the question is not only what is permitted now but what was permitted on a given date. ### 3. Acquisition - First-party sign-up - Loyalty enrolment - Guest checkout with marketing permission - Sales Cloud Lead for trade accounts Where a permission is created. If the permission is not captured with its source at this moment, it cannot be reconstructed later. ### 4. Onboarding - Welcome sequence - Preference centre prompt - First purchase confirmation - Loyalty benefit explainer The only stage where the customer is genuinely new, so it is the one stage where a parameterised journey clearly earns its maintenance cost. ### 5. Engagement - Browse and cart signals - Purchase history - Category affinity - Loyalty tier and points balance - Agentforce Marketing assisted content Runs continuously rather than as a campaign. Reads the unified profile; does not build a private copy of it. ### 6. Retention or win-back - Lapse threshold by category - Tier downgrade risk - Reactivation offer - Sunset and re-permission The stage most likely to embarrass the organisation, because it targets people the business has recently disappointed. ### 7. Suppression, cutting across every stage - Open Service Cloud Case - Recent complaint or returns dispute - Frequency cap by channel - Journey priority order - Post-purchase quiet period Reads state the marketing team does not own. This is the layer that decides whether a permitted, well-targeted message should still not be sent. ## 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. ::: warn The tell for this problem is not a marketing metric. It is that nobody in the organisation can say how many customers there are. Four systems produce four numbers, all defensible, and the gap between the largest and the smallest is where the lifecycle would have to live. ::: 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. ::: note Retrofitting a consent model after sending has begun means reprocessing records whose provenance is incomplete. The parts you cannot reconstruct have to be resolved conservatively, which means suppressing people who were legitimately contactable. The organisation pays for the deferral in reachable audience, permanently. ::: ## 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. ::: tip Before agreeing to a new journey, ask what happens to it in eighteen months if nobody touches it. If the honest answer is that it keeps sending something slightly wrong, it should have been a send. ::: ## 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. | Before | After | What made the difference | | --- | --- | --- | | Four systems each holding a partial customer | One resolved profile the lifecycle addresses | Identity resolved in Data 360 before any journey was built | | Unsubscribe flag per system | Consent modelled with meaning, propagation and history | Consent treated as an object with its own audit trail, not a field | | Journeys decide independently whether to send | One suppression layer decides, reading service and frequency state | Suppression built above the journeys rather than inside each one | | Win-back audience built from purchase recency alone | Win-back reads case state and honours a post-resolution quiet period | Marketing consuming service data it does not own | | A journey per campaign, growing without limit | A small parameterised set, plus single sends for one-off activity | The structural-versus-content test applied before anything was built | | Nobody could say how many customers there were | One number, with the resolution rules written down | Match precedence agreed in plain language, ambiguous cases reviewed | 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. ## Questions ### Do we need Data 360, or can Marketing Cloud Next hold the audience data itself? It depends on how many systems know the customer. With one source of customer data and one channel, importing audience data into the marketing platform is honest and cheap. With ecommerce, loyalty, service and email each holding a partial record, you need somewhere that resolves them into one profile, and Marketing Cloud Next is built to draw audience data from Data 360 rather than to be that resolution layer itself. The question to ask is not which product, it is which system is authoritative for audience membership. Answer that first and the product follows. ### How many journeys should a retail lifecycle actually have? Fewer than the team expects, and each one parameterised. The test we apply is whether two candidate journeys differ structurally or only in copy, timing and audience filter. If the difference is content, they are one journey with parameters. Most of what gets requested as a new journey is a new campaign, and a campaign that runs once does not need automation that has to be maintained forever. A single send with a clear audience is often the correct and cheaper answer. ### Why should marketing care about an open service case? Because the customer does not experience marketing and service as separate departments. A reactivation offer sent to somebody waiting on a returns resolution reads as an organisation that is not listening, and it converts a recoverable service failure into a reason to leave. Suppression that reads case state is one of the least expensive things in this design and one of the most visible when it is missing. --- SynconAI. https://synconai.com/case-studies/connected-customer-marketing-lifecycle