Implementing Marketing Cloud Next without rebuilding it in year two

The rebuild conversation usually starts about eighteen months in, and it rarely starts with the platform. It starts with somebody asking why there are four journeys called Welcome, which of the three audience segments is the current one, and whether the unsubscribe recorded in March actually applied everywhere it should have.

None of those are campaign problems. They are consequences of decisions taken in the first six weeks, when the platform was new, the pressure was to show something working by the end of the quarter, and the questions that felt slow to answer were quietly deferred.

Agentforce Marketing is the current umbrella brand for what most teams still call Marketing Cloud, and Marketing Cloud Next is the platform underneath it. It sits close to the core Salesforce platform and, for audience data, to Data 360. That closeness is why a Marketing Cloud Next implementation behaves less like a marketing tool rollout and more like a data and governance project with campaigns attached, and it is why the sequence below matters more than it did on the earlier platform.

#What actually forces a rebuild

It is worth being precise about the failure, because teams tend to blame the wrong thing.

Nobody rebuilds a marketing platform because the emails looked wrong. They rebuild because the estate has become unreasonable to change. Someone asks for a small alteration to the onboarding sequence and the honest answer is that there are five candidate journeys, two of them are running, the audience definitions behind them disagree, and nobody is confident which one the customer in the complaint actually received. At that point the cost of understanding the current state exceeds the cost of starting again, and a rebuild gets proposed as though it were a technology decision.

The three ingredients are always the same. Audience definitions that cannot be traced to a single authoritative source. A consent model that was inferred rather than designed, so nobody can answer a compliance question without opening several systems. And an asset estate with no taxonomy, which grows by duplication because duplication is the safe move when you cannot tell what is live.

All three are decided early, none of them are visible in a demo, and every one of them is cheaper to settle in week one than in month eighteen. That is the whole argument, and the rest of this is the order to settle them in.

#Decision one: what the audience source of truth is

Before anything else, answer this question in one sentence: when a marketer builds a segment, which system decides who is in it.

There are only a few honest answers, and the wrong ones are wrong in recognisable ways.

The first wrong answer is the marketing platform decides, arrived at by importing lists and letting them accumulate. This works for one quarter. It fails when the same person appears in two lists with different attributes and nobody can say which is right, and it fails permanently when someone asks how a segment was constructed six months after the person who built it left.

The second wrong answer is whichever system had the data first, which is not a decision at all, just the absence of one. It produces an estate where audience membership for one campaign comes from the CRM, for another from a spreadsheet, and for a third from a warehouse extract, and the three disagree in ways that only surface when a customer receives two contradictory messages in a week.

The workable answer names one authoritative place for audience membership and one for each profile attribute the marketing team actually uses, and it treats everything else as an input to that place rather than as a parallel truth. In a Marketing Cloud Next context that authoritative place is commonly Data 360, because the platform is built to draw audience data from it, but the important part is the naming, not the product. An organisation that has genuinely settled on the CRM as authoritative and enforces it will do better than one that has nominated Data 360 on a slide and still imports lists.

Two follow-on decisions belong here, and both are frequently missed.

Attribute-level ownership. Which system wins for email address, for channel preference, for language, for lifecycle stage. Naming one system as the source of truth for everything is a slogan rather than a design, and the reasoning we set out in getting Data 360 right the first time applies here without modification.

Identity. What makes two records the same person for marketing purposes. This is a different question from what makes them the same person for billing, and answering it loosely is worse than answering it strictly, because an over-merge silently gives one person another person's preferences and consent.

#Decision two: the consent and preference model

This is the most expensive item on the list to retrofit, and the one most often deferred because it feels like a compliance task rather than an implementation task.

Consent is not a flag. A workable model answers four questions, and they need answering before any sending is configured.

Where consent is recorded. One system, authoritative, with no inheritance across merges. If a preference can be set in three places, you do not have a consent model, you have three of them, and a regulator will eventually ask which one applied on a particular date.

What a preference actually means. There is a meaningful difference between a channel opt-out, a topic opt-out, a frequency cap and a global suppression, and teams routinely implement one while describing it as another. Write the definitions in plain language and have them read by whoever answers complaints, because they are the person who will discover the gap.

How a withdrawal propagates. When someone unsubscribes, what stops, how quickly, and across which journeys. The failure mode here is specific and common: a withdrawal correctly stops new sends but does not remove the person from journeys they are already inside, so they continue receiving the remaining steps of a sequence they explicitly left.

How long it is retained, and what the audit trail is. You need to be able to reconstruct what consent looked like on a date in the past. If the model only stores current state, you cannot.

Retrofitting this is painful for a reason worth stating plainly. Changing the consent model after launch means reprocessing historical records with incomplete provenance, and the parts you cannot reconstruct have to be resolved conservatively, which usually means suppressing people who were legitimately contactable. The organisation pays for the deferral in lost reachable audience, and it pays permanently.

#Decision three: naming and folder governance

This reads like housekeeping and is the single most reliable predictor of whether an estate is workable at eighteen months.

The mechanism is not subtle. Assets accumulate faster than anyone reorganises them, and no marketing platform will force a taxonomy on you. At fifty assets the lack of one is invisible. At five hundred it is the reason a marketer builds a sixth version of a welcome email rather than editing one of the five that exist, because editing the wrong one is a visible mistake and creating a new one is not.

A convention that survives contact with a real team has four properties.

It is mechanical, so two people naming the same thing independently produce the same name. Anything requiring judgement produces drift within a month.

It sorts usefully, which usually means the stable elements come first. Business unit, then programme, then asset type, then variant, then a date if a date genuinely distinguishes two things. Names that lead with a campaign nickname sort into nonsense.

It encodes lifecycle, so a reader can tell a live asset from a draft and from something retired but retained. This is the property most often omitted and the one that matters most, because the fear of editing something live is what drives duplication.

It is enforced by review rather than by hope. One person checking new assets weekly for the first quarter establishes the habit. Nothing else does, and a convention documented but not enforced is worse than none, because people trust it.

The folder structure should mirror how the team actually works rather than how the org chart is drawn, and it should be shallow. Deep hierarchies get abandoned because filing something correctly takes six clicks, and abandoned hierarchies are how three hundred assets end up in a folder called General.

#Decision four: journey design that survives change

The instinct on a new platform is to build a journey per campaign. It demonstrates well, it is quick, and it produces an estate that is impossible to maintain.

The alternative is fewer journeys, each parameterised. One onboarding journey that varies by product, region and language through parameters is harder to build than four near-identical journeys and dramatically cheaper to own. When a legal disclaimer changes, you edit one thing. When the four exist, you edit three of them and discover the fourth six months later, still sending the old wording.

The test we use before agreeing to a new journey is a single question: what varies, and is that variation structural or content. If two journeys 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 for a new journey fail this test, and the honest answer is that the requester wanted a new campaign, not new automation.

Three further rules earn their place.

Design the exit before the entry. Every journey needs stated exit criteria, including the ones nobody wants to discuss: what happens when the person converts halfway through, when they raise a complaint, when they withdraw consent, and when they qualify for a higher priority journey at the same moment. Journeys built without exit criteria do not misbehave immediately. They misbehave once there are enough of them for one person to be inside three at once.

Decide the suppression hierarchy centrally. When two journeys both want to send on a Tuesday, something has to decide. If that decision is made per journey, it is made inconsistently, and the customer experience becomes the sum of choices nobody made together. Salesforce sets out the general shape of this thinking in its marketing automation guide, and the platform mechanics matter less than having one place where the priority order is written down.

Version deliberately. Changing a running journey and changing a journey between runs are different operations with different risks, and teams that do not distinguish them end up making structural changes to something with people inside it.

#Decision five: measurement wired in from the start

Measurement added later cannot be applied backwards, which is the entire reason it belongs in the first six weeks rather than the first review.

Four things need settling before the first send.

What is counted. Sends, deliveries, opens, clicks and conversions are not interchangeable, and open rates in particular have become a weaker signal than they used to be. Decide which metrics are decision-grade for your organisation and which are diagnostic only, and write that distinction down where the people reading dashboards will see it.

Against which identifier. If marketing counts by email address and the business counts by account, the two numbers will never reconcile and the argument will recur every quarter. Pick the identifier, and pick it to match how the rest of the business reports.

Where attribution is resolved. Marketing platform, CRM, warehouse or a BI layer. Any of them can work. What does not work is resolving it in more than one, because then there are two numbers and a standing meeting to reconcile them.

What the baseline is. Capture the pre-launch position deliberately, because the first question after go-live will be whether this is better than what it replaced, and the honest answer without a baseline is that nobody knows.

There is a further point that has grown in importance as more of the platform becomes AI-assisted. Anything that personalises or recommends is only as good as the data it reads, and the failure looks like a model problem while being a data problem. The grounding argument we make for agents in grounding Agentforce in Data 360 transfers directly: if the attribute driving a personalisation decision is stale, contradicted or unowned, no amount of tuning at the campaign layer fixes it.

#Decision six: the handover

An implementation ends when a team who did not build it can operate it. That is a different milestone from go-live, and it is the one that determines whether the estate degrades.

Three things constitute a real handover.

A named owner per area. Someone owns the audience definitions, someone owns the consent model, someone owns the naming convention. Shared ownership of any of these means nobody notices the drift, and drift in a marketing estate is silent by nature.

A stated change boundary. What can a marketer change without review, and what requires one. Draw this line generously on content and strictly on structure. Copy, images, subject lines and send times should not need governance. Audience definitions, consent handling, journey structure and naming should.

A review with a date in the calendar. Once a quarter is enough: read the asset list for things that should have been retired, check that audience definitions still reconcile with their source, and confirm the naming convention is still being followed. An hour, four times a year, is most of the operating model.

The commercial framing helps here. Marketing Cloud Next Growth Edition is published at US$1,500 per org per month, billed annually, with Marketing Cloud Next Advanced Edition listed without a published price. Because Growth Edition is priced per org rather than per seat, the licence cost does not rise as the team grows, which means the real ongoing cost of the platform is the operating effort. That is an argument for spending on governance early rather than treating it as overhead.

#The phase table

This is the sequence, and the last column is why the order is what it is.

Read the last column downwards and the ordering justifies itself. The phases are not sequenced by dependency alone, they are sequenced by irreversibility.

#Where Marketing Cloud Engagement habits mislead

Most teams implementing Marketing Cloud Next have people who know Marketing Cloud Engagement, and that experience is valuable in specific ways and misleading in others.

It is valuable on campaign craft. Segmentation logic, journey shape, testing discipline and deliverability hygiene all transfer, and a team that has run a mature Engagement estate knows things a new team will otherwise learn slowly and expensively.

It misleads on architecture. Marketing Cloud Engagement grew up as a comparatively self-contained system, and a great deal of accumulated practice exists to manage audience data inside it. Marketing Cloud Next is built to sit close to the core platform and to draw audience data from it, so patterns designed to compensate for distance from the CRM can end up recreating a separation the newer platform exists to remove. We set out the differences that actually matter in Marketing Cloud Next versus Marketing Cloud Engagement.

The practical consequence for a migration is that content and audience logic should be reused and structure should be rebuilt. Lifting an Engagement structure across is fast and produces exactly the estate this article is about, eighteen months earlier than usual.

#The first six weeks, in order

If the licence is signed and nothing has been configured, this is the sequence.

Weeks one and two are the audience foundation and the consent model, in parallel, with the process owners in the room rather than consulted afterwards. The output is written down: the authoritative source for audience membership, the attribute ownership table, the definition of each preference, and the propagation rule for a withdrawal. Nothing is configured yet, and that is the point.

Week two also settles the naming convention and the folder structure, which takes an afternoon and is the cheapest item on this list by a wide margin.

Weeks three to six are the journey architecture and the measurement definitions, built together because they constrain each other. Design the smallest set of parameterised journeys that covers the committed programmes, state the exit criteria and the suppression hierarchy, and define the metrics and the identifier before the first send rather than after the first dashboard argument.

From week six, name the owners and put the quarterly review in the calendar while the programme still has the attention to make it stick.

#What is cheap to change, and what is not

Treating every change as dangerous is its own failure mode, so it is worth being explicit about which of these decisions are genuinely load-bearing.

Cheap: adding an audience attribute, adding a journey that fits the existing architecture, changing copy, changing send timing, adding a metric to a dashboard, tightening a naming convention before many assets exist. None of these need governance, and governing them teaches the team to route around governance.

Expensive: changing the authoritative source for audience membership after segments depend on it, changing the consent model after sending has occurred, renaming assets that journeys and reports reference, merging near-duplicate journeys, and changing the counted identifier after a period has been reported.

The pattern is the same one that governs data platform work generally. A decision costs what it costs to reverse in proportion to how far its output has already travelled, and in a marketing estate the output travels to customers, which is the furthest it can go.

That is why this sequence puts the unglamorous work first. The organisations still comfortably running the estate they built are not the ones that launched fastest. They are the ones that spent the first six weeks answering questions nobody could demonstrate.