Ahead of Snowflake World Tour, Paul McCord, Alliances Director at Zeotap, and Aleksandra (Sasha) Chernykh, Co-Founder & Lead Consultant, Glassjaw, compared notes on what actually changes for activation teams when the customer data platform lives inside the warehouse and where the model still hits its limits.

There's a lot of noise about composable and native CDPs on Snowflake this year. What's actually different in the conversations you're having with customers, versus twelve months ago?

Paul McCord, Zeotap: The procurement conversation has shortened noticeably. A year ago, most customers came in evaluating a CDP as a standalone vendor decision: security review, InfoSec, the full cycle. Today, more of them arrive with Snowflake already approved internally and treat the CDP as an additional module on a platform they already trust. That shifts the buying committee, the timelines and, frankly, the objections. The question is less "can we trust this vendor" and more "how do we get this live inside our existing governance."

Aleksandra (Sasha) Chernykh, Glassjaw: The conversation has moved from access to agreement. A year ago, many CRM teams were asking data teams for exports so they could build audiences in their own tools. Now, they increasingly want to work from the definitions analytics already trusts. "Active customer", "lapsed", "high value": when those numbers disagree between the dashboard and the campaign tool, the CRM team loses the argument every time. We're seeing CRM and data teams come together much earlier, with better questions about definitions, ownership and activation.

Where do you see teams struggle when the CDP sits outside the warehouse?

Aleksandra (Sasha) Chernykh, Glassjaw: I see the same three things break. The first is timing. When data has to be copied out before anyone can act on it, the sync schedule quietly becomes the real send time. That is how a customer who bought an hour ago still gets the abandoned-cart email, discount included.

The second is definitions. Each team rebuilds its cohorts in the tool it owns, the numbers drift apart, and nobody can say which list is right.

The third is measurement. Behavioural events land in the activation tool but don't always make it back into the analytical layer cleanly, so teams can see who clicked but struggle to connect that activity to what actually changed. The result is hundreds of segments and no way to tell which ones earn their keep.

Paul McCord, Zeotap: The pattern I'd add is what happens to governance. When customer data is copied into a second environment, the row access policies, masking rules and role-based controls have to be maintained in two places. Teams get it right on day one, and then over eighteen months the two systems drift. That's not a criticism of any specific architecture — it's just what happens when the same rules live in two places and two teams own them.

When the CDP runs natively in Snowflake, what changes in practice for the activation team?

Paul McCord, Zeotap: Three things, in the order teams tend to notice them. First, no data transit at activation, which removes a class of compliance conversations. Second, inherited governance: the access rules already in the warehouse apply to the CDP automatically, not by mirroring. Third, and this is the one that matters most for activation teams: the features engineered for analytics and the features used for segmentation live in the same place. You stop rebuilding definitions of "active customer" or "high-value cohort" in two systems that don't quite agree with each other.

Aleksandra (Sasha) Chernykh, Glassjaw: The biggest change is that targeting can become much closer to the actual customer state. Imagine a customer who browsed repeatedly, purchased yesterday and has since become a high-value customer. Instead of CRM working from yesterday's exported segment while analytics has the newer picture, both can work from the same underlying data and definitions. That changes more than audience building. Suppression, prioritisation, personalisation and next-best-action decisions can all become more reliable. For the activation team, the value isn't really "the CDP is in Snowflake". It's that fewer assumptions sit between what the business knows about a customer and the experience that customer actually receives.

Where's the native model the wrong answer?

Paul McCord, Zeotap: When Snowflake isn't the strategic Data Cloud, or when a team is running multiple warehouses in parallel and wants to keep that optionality, the native route costs more than it gives back. Same story if the warehouse itself is immature, the CDP will inherit whatever governance gaps are already there. In those cases, the external Zero-Copy model is the right answer, not a fallback.

Aleksandra (Sasha) Chernykh, Glassjaw: When the problem isn't the data. If the emails go out too often or say the wrong thing, moving the CDP won't fix that, and it's one of the most common issues I find in CRM audits. I'd also be cautious where Snowflake isn't genuinely the organisation's central customer-data layer yet. Native architecture is powerful when the foundation underneath it is mature. It shouldn't become a reason to redesign an entire data estate when the actual problem is strategy, execution or operating model.

You're both at Snowflake World Tour this month. What conversation do you want to have with people who stop by?

Aleksandra (Sasha) Chernykh, Glassjaw: The question I'd love to hear is: "We have Snowflake, we have a CRM platform, and we have plenty of customer data, so why are our customer experiences still disconnected?" That's where the interesting conversation starts. The next phase isn't about collecting more data. It's about shortening the distance between what a brand knows about a customer and what it actually does with that knowledge.

Paul McCord, Zeotap: The most useful conversations I have at these events are with teams who've already made the Snowflake bet and are trying to work out what should stay in the warehouse and what shouldn't. If that's you, come and find us, the honest answer is usually more interesting than the pitch.

The handovers that go badly are rarely the ones where something is broken. They are the ones where everything works. Every journey is live, every dashboard is green, and six weeks later nobody in the building can say why the win-back programme waits ninety days rather than sixty.

The assets transfer fine. Logins, templates, segment definitions and documentation all move in an afternoon. What does not move is the reasoning, and a programme whose reasoning has been lost degrades quietly. Nobody notices for a quarter, because the campaigns keep sending.

We think an engagement should be designed to end well from the day it starts, and the test of whether it did is not whether the new team can keep the programme running. It is whether they can change it.

Design the exit before you design the first sprint

The right time to agree how an engagement ends is the week it begins. By the time somebody raises it in month eighteen, a set of dependencies has formed that nobody chose.

Three things should be settled at the start, in writing:

• Which capabilities are being built in-house and which are being bought for the duration. A team that never intends to run deliverability itself needs a different plan from one that does.
• Who on the client side shadows each workstream, by name, with time protected for it. A shadow with no allocated hours is a name on a slide.
• What the handover artefacts are, and where they live. In the client's own systems from day one, not in an agency drive to be exported later.

That third point sounds administrative and is the one that decides the rest. Documentation written in the client's environment gets read and corrected as the work happens. Documentation exported at the end is written once, by someone in a hurry, and read by nobody.

The same discipline applies in the other direction when an engagement starts, and we set out what a good brief contains in briefing an agency. A brief that names the intended end state produces a much easier handover than one that does not.

Transfer the decisions, not just the assets

Every mature programme is a pile of decisions that look arbitrary from outside. The sunset window is one hundred and eighty days. The basket journey carries no discount. Two segments are excluded from the weekly newsletter. Push goes before email on one journey and after it on another.

Each of those had a reason, usually a test result, a complaint spike, a legal review or a commercial argument. Without the reasons, the new team faces an unpleasant choice. Preserve everything, which freezes the programme, or change things and rediscover the original problems.

So the central handover artefact is a decision log. One line per decision, with the date, the person, the reason and the evidence. It does not need to be elegant. It needs to be complete enough that an incoming manager can tell a deliberate choice from an accident.

We write it continuously rather than at the end, because a decision log assembled retrospectively is a reconstruction. Two of the entries will be wrong, and they will be the two that matter.

The list of things that actually have to move

Beyond the decision log, the handover has a fixed inventory. Working through it takes longer than people budget, and skipping items is how the first quarter goes wrong.

1. Access and ownership. Every platform, with named owners and a billing contact. Every integration's credentials, with their rotation schedule. Any account still registered to an agency email address is a future outage.
2. Sending domains and DNS. Which records exist, who may change them, and how a change is requested. Deliverability fails slowly and silently when this is unclear, and it is the single most common gap we find after a transition.
3. Data models and contracts. The models behind the single customer view, their tests, and the data contract with each upstream system. What the field means, who produces it, how often, and what happens when it is late.
4. Naming and segment conventions. How campaigns, segments and journeys are named, and why. This is the convention that decays fastest after a handover, and reporting decays with it.
5. The message inventory. Every broadcast, trigger and transactional template, with its owner, trigger, audience and last review date. Including the ones marketing does not own.
6. Consent and preference handling. How the preference centre writes back, where consent is stored, and what the timestamp and source look like for each channel.
7. Measurement definitions. What each headline metric counts, in words a finance colleague can check. Where holdouts sit and how they are maintained.
8. Incident runbooks. What to do when a sync fails, a send goes to the wrong segment, a complaint rate spikes, or a template renders wrongly. Each with the first three steps and who to call.
9. The roadmap and its funding case. Not just what is next, but the argument that got it funded, which is the part that has to be repeated next year. We covered how to build that argument in a roadmap finance will fund.

Read that list as a checklist to complete before the last month, not during it.

Run it in parallel, in both directions

A handover that consists of documents and a workshop is a hope rather than a plan. The transfer has to be rehearsed while there is still someone to catch the mistakes.

We run two phases. In the first, the agency continues to ship and the in-house team reviews everything before it goes out. That surfaces the tacit rules nobody wrote down, because the reviewer asks why.

In the second, the roles reverse. The in-house team builds, schedules and sends, and the agency reviews. This phase is the one that matters, and it needs to run long enough to include a full cycle of the programme's real work. A month of business as usual, at least one peak or campaign moment, one incident, and one reporting cycle.

If the second phase produces no questions at all, something is wrong. Either the team is not really doing the work, or they are not yet confident enough to say what they do not understand.

What tends to break in the first ninety days

Some failures are predictable enough to plan for directly.

Deliverability drifts, because nobody inherited the weekly check. A key person leaves within the first two quarters and takes the undocumented query with them. A vendor renewal arrives with nobody who remembers what was negotiated. A scheduled job fails and the alert goes to a mailbox that was deactivated with the agency's accounts.

The counter to all four is the same. Name the recurring obligations explicitly, with owners and a frequency, and put them in the same calendar the team already uses. Weekly deliverability review, monthly message inventory check, quarterly consent audit, annual vendor review.

Then agree a light support arrangement for the first quarter. Not a retainer that recreates the dependency, but a defined number of hours for questions, with the expectation that the number falls each month. If it does not fall, the handover has not finished.

The honest measure comes a little later. Six months on, has the team shipped something you would not have built. If they have, the capability transferred. If the programme looks exactly as you left it, what transferred was only the operating manual.

Stack selection usually starts with a shortlist of vendor names and ends with a decision nobody can explain eighteen months later. The names are the least useful place to begin.

Start instead with the tool classes. Four of them cover almost everything a CRM programme needs, and most confusion in selection comes from two vendors in different classes being compared as if they did the same job.

We are deliberately not ranking products here. The right combination depends on your data, your volumes and the team you actually have, and the same vendor can be an excellent fit for one brand and a poor one for its competitor.

Learn the four tool classes before the demos

The engagement platform sends the messages. It holds journeys, campaigns, templates, frequency rules and channel delivery across email, push, SMS, in-app and web. Braze, Bloomreach, Insider and Maestra sit in this class, among others.

The customer data platform collects, resolves and segments customer data, then pushes audiences to downstream tools. Some engagement platforms include CDP-style capability, which is where category confusion usually starts.

The warehouse is where your customer, order, product and event data lives in queryable form. Snowflake and Databricks are common choices, alongside the cloud-native options.

The reverse-ETL tool moves data from the warehouse into operational tools, so a segment defined in SQL becomes an audience in the engagement platform. Hightouch is the best-known example of this class.

A stack can combine these in several shapes. Warehouse plus reverse-ETL plus engagement platform is common now, and so is CDP plus engagement platform with no warehouse involvement.

Both shapes work. What does not work is buying two tools that each assume they own segmentation.

Start from the warehouse question

The first real question is where the single version of your customer will live, and who controls it.

If you already have a warehouse with clean order and event data, build the stack around it. Define segments in SQL, sync them out, and keep the engagement platform focused on delivery and journey logic. You get one definition of "active customer" that marketing and finance can both point at.

If you have no warehouse and no data team, a CDP or a data-capable engagement platform will get you live much faster. The trade-off is that your segment logic now lives inside a vendor, and moving it later is real work.

Questions to ask in either case:

• Who can change a segment definition, and how long does that take?
• If we replaced the engagement platform next year, what would we have to rebuild?
• Where is the identity resolution happening, and can we inspect its rules?
• Can analytics reproduce a marketing segment independently?

Ask what the engagement platform is actually for

Demos tend to showcase journey builders. Useful, but rarely the deciding factor. The differences that matter show up in operations.

Work through these with each vendor, using your own scenarios rather than theirs:

• Channels: which do you need on day one, and which are genuinely native rather than a partner integration?
• Volume and velocity: peak sends per hour, and how real-time the triggers are in practice.
• Deliverability controls: dedicated IP options, warm-up support, seed testing, and how sending reputation is managed. If you are starting from a new IP, our note on IP warming from zero covers what that process demands.
• Localisation: how multi-language content is handled inside one journey.
• Permissions: whether you can let a regional team build without letting them send.
• Data in and out: event ingestion limits, and whether you can export raw event data on your own schedule.

That last one matters more than it looks. If you cannot get event-level data back out cheaply, your revenue reporting is stuck inside the vendor's definitions, which is the problem we describe in CRM to revenue measurement.

Price the running cost, not the licence

Licence fees are the visible number and often not the largest one. Build a two-year cost view that includes the parts vendors do not quote.

Count implementation, which is usually three to six months of work for a mid-sized programme. Count warehouse compute if segments run frequently. Count data volume growth, since most contracts price on profiles or events and both grow faster than expected.

Count the internal cost too. A stack that needs a data engineer to change a segment has a permanent staffing requirement attached to it, and that cost outlives any discount you negotiate at signature.

Then ask about the exit. Contract length, data export format, notice period, and what happens to your journey logic if you leave.

Match the stack to the team you have

The most common selection error we see is buying for the team the company plans to hire rather than the one it has.

A warehouse-first stack rewards a team with SQL skills and analytics support. A CDP-led stack rewards a marketing team that needs to move without engineering. Neither is more advanced, and they fail in different ways.

Run a proof of concept on one real programme, not a sandbox. Build your actual onboarding journey, with your actual data, and see how long each step takes. Two weeks of that beats two months of feature comparison.

Where a selection needs an independent view, or the build needs hands, that is what our implementation team does.

What to do this week

• Write down which of the four tool classes each product in your current stack occupies, and mark any job that two tools both claim.
• Pick one segment definition and trace who can change it, where it lives, and how long a change takes to reach a send.
• Build a two-year cost view for your current stack including implementation, compute and internal time, then compare it to the licence figure you usually quote.

Almost every CRM team we meet intends to test more. Very few do, and the reason is consistent. Testing is the first thing dropped when the campaign calendar gets heavy, because it is the only item with no external deadline.

The fix is not more enthusiasm. It is a cadence: a fixed number of tests in flight, a fixed day for decisions, and a backlog that someone owns. Rhythm beats ambition here, because a small test running every week compounds and a big test planned every quarter rarely ships.

This post covers how we set that rhythm up, size tests honestly, and keep the results from evaporating the moment the person who ran them changes role.

Fix the rhythm before the roadmap

Start by deciding how many tests you can genuinely have live at once. For most teams sending a few campaigns a week, the answer is one or two. Anything more and the audiences start overlapping.

Then put two recurring slots in the calendar. A short weekly session to launch what is ready and check what is running. A longer monthly session to read completed tests and update the backlog.

Assign one owner for the backlog. Not a committee. The owner decides what goes next, and their job is to make sure the queue is never empty when the weekly slot arrives.

Keep the backlog visible and ranked. We rank on expected impact divided by effort, and we require a written hypothesis before an idea can enter the queue at all.

Size the test honestly, then set the stop rule

Most CRM tests are underpowered, which is why so many read as "no clear winner". Before launching, work out the sample you need for the effect size you care about.

A rough guide we use: detecting a one percentage point difference on a ten per cent click rate needs tens of thousands of recipients per cell. Detecting a twenty per cent difference in conversion on a small segment may be impossible at your volume, and that is useful to know before you spend two weeks on it.

Set the stop rule at launch, not during the test:

• The fixed sample size or the fixed end date, whichever you chose.
• The metric that decides the outcome, named exactly, with the measurement window.
• The guardrail metrics that would stop the test early, such as unsubscribe rate or complaint rate.

Then stop looking at it daily. Peeking at results and calling a winner when the line crosses is the most common way CRM teams convince themselves of things that are not true.

When a test does produce a winner, check that it holds against revenue rather than clicks. The reasoning behind that sits in our note on CRM to revenue measurement.

Test one variable, and make it a big one

Change one thing per test. If you change the subject line, the layout and the send time together, a win tells you nothing you can reuse.

More importantly, make the one thing substantial. Testing two near-identical subject lines wastes a slot and returns a result you cannot detect. Testing a discount-led message against a value-led message returns something you can build on.

A rough order of impact we work through with most programmes:

• Who receives it. Segment definition and eligibility rules move numbers more than copy does.
• When it arrives. Timing, frequency and the trigger delay on behavioural messages.
• What it offers. Incentive level, incentive type, and whether there is an incentive at all.
• What it says. Positioning and message angle, before subject line wording.
• How it looks. Layout, imagery and call-to-action treatment.

Most teams start at the bottom of that list because it is the easiest thing to change. Start at the top instead.

Keep a decision log

A test result that lives in a chat message has a shelf life of about six weeks. After that the team retests the same thing, usually without realising.

Keep one file with a row per completed test: hypothesis, variants, audience, sample size, result, the decision taken, and the date. Ten lines each, no slide decks.

Record the losers and the inconclusive tests too. Knowing that send-time optimisation made no measurable difference last spring is worth as much as knowing what worked, and it stops the idea coming back every planning cycle.

Review the log before each planning session. The question is simple: what have we already learned that this quarter's plan ignores?

Retire what has done its job

Tests are not permanent. Once a variant wins and you roll it out, close the test and move the slot to something new.

Some results do expire. Creative fatigue, seasonal effects and audience mix all shift, so anything that shaped a major programme decision is worth re-running roughly once a year.

Audit your live tests quarterly and kill the ones that have been running for months without reaching their sample size. They are occupying audience and attention for nothing.

If you want an outside team to run this rhythm and hold the decision log, that is a standing part of our optimisation work.

What to do this week

• Put a recurring thirty-minute testing slot in the calendar and name one person as backlog owner.
• Take the next test you had planned and calculate the sample size it needs before you build it.
• Start a decision log with the last five tests you ran, including the ones that were inconclusive.

Nearly every campaign disaster we have been asked to help with was caused by something small and checkable. A segment saved with the wrong operator. A personalisation token that rendered as raw syntax for every record with a blank name field. A link to a staging domain that nobody clicked because everyone was reading the copy.

None of them were creative failures, and none were caught by an approval process that consisted of forwarding a preview to three people and waiting for replies saying "looks good".

What follows is the checklist we run before every send. It is deliberately boring, it takes about forty minutes on a standard campaign, and it is the same list whether the send is twelve thousand people or two million. The value is in running it the same way every time, so the step that gets skipped is visible.

Count the audience twice, from two directions

Start with the audience, because it is the only error you cannot correct after the fact. Everything else can be followed by a fix; the wrong recipients cannot be un-received.

1. Pull the count in the sending platform and, separately, from the warehouse or a second query. If the two disagree by more than a rounding difference, stop and find out why before anything else happens.
2. Read the segment definition out loud, in words, to another person. Ambiguity between "and" and "or" survives every visual builder ever made but rarely survives being spoken.
3. Compare the count with the last comparable send. A change of more than a quarter in either direction needs an explanation, and "we grew" is not one unless someone can point to the growth.
4. Confirm the suppressions are attached: global unsubscribes, complaints, hard bounces, deceased and data-request suppressions, plus any campaign-specific exclusions.
5. Check the overlap with anything else going out in the same window, so that a customer is not receiving three messages within an hour from three different owners.
6. Export twenty real records from the audience and read them. Not a preview — the actual rows, with the fields the template will use.

That last step catches more than the other five combined. It is also where you notice that a segment you inherited quietly includes test accounts, internal staff or a cohort that should have aged out. Definitions drift, and the cohort work we described in cohorts that change the roadmap is only trustworthy if the underlying segments are re-read occasionally rather than reused on faith.

Render it where people actually read it

Preview panes lie. They render a simplified version of a message in a browser, and browsers are not mail clients.

Send to a seed list that covers the clients your audience genuinely uses, which you should confirm from your own data rather than from an industry summary. For most programmes that means the two dominant webmail providers, the desktop client your corporate recipients use, and iOS and Android mail apps on real devices.

Then check, on each:

• Subject line and preheader as they truncate on a phone, not as they appear in the platform field.
• Dark mode. Logos with white backgrounds and text set in near-black are the usual casualties.
• Images off. The message must still make sense and still have a clickable route through.
• Alt text present on every image that carries meaning, and absent on decorative ones.
• Plain-text version, which is still generated in many stacks by a converter that produces unreadable output nobody has looked at in two years.

For anything with dynamic content, the seed test is not enough. Build a proof list containing one real record per variant, plus the edge cases. The empty field, the very long product name, the customer in a different currency, the person whose only qualifying purchase was returned. Send to that list and read every version.

Set a default for every token and check the default renders sensibly. "Hi there" is a perfectly good fallback; the token name in curly braces is not.

Click every link with tracking switched on

Read the message as a recipient would and click everything, in the seed version rather than in the preview, so tracking parameters are present.

What this catches: staging and localhost URLs, expired campaign pages, redirects that drop the tracking parameters. Also links to a category that sold out this morning, and footer links copied from a template built for another market.

Confirm the tracking parameters match the convention your reporting expects, exactly, including case. A campaign tagged inconsistently is not merely untidy. It lands in a different bucket in every downstream model, and the channel inputs feeding work like marketing mix modelling for CRM teams are only as good as the tagging behind them.

Check the unsubscribe path last, and check it properly. Click the footer link and confirm the page loads, is legible on a phone and does not require a login. Separately, use the mailbox provider's own control to confirm one-click unsubscribe works from the headers and that the suppression reaches your platform.

The technical checks nobody enjoys

These are quick, and they are the ones that protect the programme rather than the campaign.

• From-name and from-address correct for this stream, and the reply address monitored by a human or routed to the service desk.
• Sending domain and stream correct, so a promotional campaign is not going out over the transactional path.
• Authentication passing on the seed messages, checked in the received headers rather than assumed from last month's configuration.
• Message size within the limit at which the dominant webmail provider clips the content, since a clipped message hides the footer and the unsubscribe link.
• Rate and throttling settings appropriate to the volume, particularly for a send larger than your usual pattern, because deliverability problems often start as queueing problems.
• Any test sends and internal addresses removed from the audience before scheduling.

Sign-off, timing and who is holding the switch

Sign-off should name a person per area rather than collecting general approval. In practice that is one owner for audience, one for content and offer accuracy, and one for the technical checks. Three names, recorded against the campaign, with the time they signed.

Check the schedule in the recipient's time zone, and check the day. The most common scheduling error we see is a send set for the correct clock time in the wrong zone, and the second is a campaign scheduled on a date that a public holiday has moved.

Before the send goes into the queue, confirm two things out loud: who can stop it once it starts, and whether they have the permissions to do so. Test that assumption on a quiet day rather than discovering it during a live incident.

The first half hour after you press send

The checklist does not end at the send. Someone stays with it for thirty minutes and watches the delivery rate, the bounce rate, the early complaint signals and the destination page's server response.

A landing page that falls over under the opening burst is the failure most often missed, because everyone is watching the email platform. Have the page owner watching their own dashboard at the same time, and agree in advance what the two of you do if either number looks wrong.

The hard part of all this is not writing the list. It is keeping it in use when the campaign is late and the deadline was yesterday, which is precisely when the errors happen. Put it in the workflow tool as a real gate with the three names attached, not in a document that people intend to open.

Most CRM teams can tell you their open rate to one decimal place and cannot tell you what the programme is worth. That gap is why CRM budgets get cut first in a tight quarter.

The problem is rarely a lack of data. It is that three different numbers all get called "CRM revenue", nobody has agreed which one is being discussed, and the finance team has quietly stopped believing any of them.

Fixing this is less about analytics sophistication than about agreement. Pick a definition, write it down, instrument it once, and report the same number every month even when it moves in the wrong direction.

Separate the three numbers people confuse

There are three distinct figures, and mixing them is the root of most CRM reporting arguments.

• Attributed revenue: orders where a CRM touch appears in the customer's path, under some attribution rule.
• Influenced revenue: revenue from customers who received any CRM contact in a period, with no claim of causation.
• Incremental revenue: the difference between what happened and what would have happened without the programme.

Attributed revenue is easy to produce and easy to attack. Influenced revenue is almost always a large number and almost always meaningless. Incremental revenue is the only one that answers the budget question.

Report all three if you must, but label them clearly and tell people which one you are managing towards. We manage towards incremental revenue and use attributed revenue as an operational signal for campaign triage.

Agree an attribution rule before you build the report

An attribution rule is a business decision dressed as a technical one. Agree it with finance and analytics in a single meeting, and record it in writing.

Three choices to settle:

• Window length. Seven days after click is a common starting point for email, shorter for push, longer for considered purchases.
• Touch type. Does an open count, or only a click? Our default is click, because opens have been unreliable since privacy protections became widespread.
• Credit model. Last CRM touch within the window is the simplest defensible rule. Fractional models are fine if everyone understands them.

Then hold the rule still. Changing the window mid-year makes year-on-year comparison impossible and invites the suspicion that the number was tuned.

Use holdouts as the default, not the exception

A holdout group is the cheapest way to make a CRM number credible. Withhold the programme from a random sample, compare revenue per recipient over a fixed period, and the difference is your lift.

We run two layers. A small global holdout, typically one to five per cent of the addressable base, kept out of all marketing contact and refreshed on a fixed schedule. Then per-campaign holdouts on high-volume sends.

Some practical rules we apply:

• Randomise at the customer level, not the send level, or the same people keep getting held out.
• Keep the global holdout stable for at least a full purchase cycle before reading it.
• Exclude transactional and service messages from the holdout. You cannot withhold a delivery notification.
• Measure revenue per eligible customer, not per opened email, so the comparison is fair.

Expect the incremental number to be smaller than the attributed one. That is the point. A programme that shows attributed revenue ten times higher than measured lift is telling you it is largely claiming credit for purchases that would have happened anyway.

Instrument the data once, in the warehouse

Reporting built inside the engagement platform will always be limited to what that platform saw. Orders, returns, margin and customer history live elsewhere.

Land send, delivery, open, click and unsubscribe events in the warehouse alongside order data, and join on a stable customer identifier. Then build the revenue report there, once, and let the platform handle operational metrics only.

This also removes a familiar argument. When the platform and the finance report disagree, you want one join to inspect rather than two black boxes to compare.

If your event data is patchy or your identifiers do not join cleanly, that is an audit job before it is a measurement job. Our CRM audit checklist covers the data checks we run first.

Report in a format finance will accept

Finance cares about three things: what the programme cost, what it returned, and how confident you are. Build the monthly report around those.

Include the cost side honestly. Platform licence, data infrastructure, agency or team cost, and any incentive or discount funded by CRM. Discount cost in particular is often missing, and it is usually the largest variable.

Show confidence intervals or sample sizes on lift figures. A measured lift of four per cent with a wide interval is an honest statement. The same number presented as a point estimate will be treated as a point estimate forever.

Keep the report short. One page with revenue, cost, net contribution, lift, and a two-line commentary on what changed. Detail belongs in an appendix that nobody reads and everyone is glad exists.

Where teams want help building this end to end, that measurement work sits inside our optimisation practice.

What to do this week

• Write one sentence defining your CRM revenue number, including window, touch type and credit model, and send it to finance for agreement.
• Set up a global holdout of one to five per cent, randomised at customer level, and note the date you started it so you know when it can be read.
• Pull last month's attributed revenue and last month's discount cost into the same view, and see whether the net contribution is still positive.

Running one campaign in one language is a content problem. Running the same campaign in twelve languages on a weekly cadence is an operations problem. The copy is rarely what breaks first.

What breaks is the handover. Someone writes, someone translates, someone builds, someone presses send. Each step carries its own deadline and its own version of the truth, and by the third market the brief has quietly drifted.

We see the same failure pattern at brands with international audiences. A journey gets cloned per market, each clone picks up a small local fix, and two quarters later nobody knows which version is canonical. Correcting one broken link then means correcting it fourteen times.

Keep one journey, vary the content

Our first rule is that market is a content variable, not a journey variable. One canvas, one set of entry rules, one exit condition, and a content block that resolves by locale at send time.

Cloning feels fast on day one. It costs you every day after that. Each clone becomes a separate place where a consent rule, a suppression list or a tracking parameter can go stale without anyone noticing.

Some splits are legitimate. Different legal wording, a market with no SMS channel, a promotion that runs in two countries only. Split on those reasons, write the reason down next to the journey, and review every split once a quarter.

The same discipline applies to lifecycle programmes, which is why we set the structure up front rather than retrofitting it. We covered that groundwork earlier on this topic in onboarding journey design.

Decide where language lives in your data model

Locale should sit on the profile as a single attribute, written by a rule you can explain out loud. Most teams have three candidate signals: declared language preference, account country, and device or browser language.

Rank them once. Declared preference wins, country fills the gap, device language is the last resort. Store the source of the value too, so you can tell a guess from a choice.

Then define a fallback chain rather than a default. A profile marked fr-CA should fall back to fr before it falls back to en. Without a chain, one missing translation quietly drops the recipient into English.

Two checks we run on every new market:

• Every locale in the profile data has a matching content variant, or an explicit fallback.
• No locale value exists that the platform cannot resolve. Free-text language fields are where this goes wrong.

Give translation a window, not a chat thread

Translation requests that live in a messaging thread arrive late and undocumented. We replace that with a fixed weekly window: source strings freeze on a set day, translations return two working days later, build starts the morning after.

Send translators the full context, not a spreadsheet of fragments. That means the layout, the character limits, the audience, and the intent of the message. A subject line brief without a character limit comes back 60 characters long and gets truncated on mobile.

Keep a shared glossary for product names, tier names and anything legal. Decide once whether a brand term is translated or left in English, and record the decision. Re-litigating that every campaign is a slow tax on the team.

QA each locale before the send, not after

Locale QA is a checklist, and it is short enough to run properly. We hold ours to items that have genuinely broken sends:

• Rendering: subject line length, preheader, push truncation on the shortest supported handset.
• Personalisation tokens: every token has a fallback, and the fallback reads naturally in that language.
• Numbers and dates: currency symbol, decimal separator, date order, and time zone in the copy.
• Direction and script: right-to-left layouts and non-Latin scripts checked in a real client, not a preview pane.
• Legal and links: the correct footer, the correct unsubscribe wording, and links pointing at the right locale of the site.

Run it on live seed profiles in each locale rather than on test data. A seed list with real attribute values catches the fallback problems that clean test records never will.

Plan the calendar around local reality

A single global send time is a compromise everywhere. Schedule by local time zone, and accept that your reporting day now spans more hours than your working day.

Build a market calendar of public holidays, school terms and category-specific events. Retail peaks differ by country. Sports and entertainment schedules move weekly and force real deadlines on the content chain.

Our work on Premier Padel runs dozens of multilingual tournaments a month across more than a million unified users, and the calendar is what makes that survivable. The journeys are fixed, the content is locale-driven, and the tournament schedule feeds the timing rather than the build.

Agree in advance what happens when a translation misses the window. Our default is to send the fallback language on time rather than delay the whole campaign. Hold that rule for a month and deadlines start being met.

Measure at market level as well as in aggregate. A programme that looks flat overall often hides one market improving and another declining. The same goes for testing: a locale-specific send time or a market-specific frequency cap is usually worth more than another localised subject line test.

If you want a second pair of hands on the weekly build and QA rhythm, that is the kind of work our execution team runs day to day.

What to do this week

• Count your journeys that exist only because of language, and pick two to merge back into a single locale-driven canvas.
• Write down your locale fallback chain, then query your profile data for any locale value that has no matching content variant.
• Put a translation freeze day in the calendar, tell the team the window, and hold it for the next four campaigns.

The standard onboarding programme is a five-email tour of the product. Email one welcomes, emails two to four each explain a feature, email five asks for a review. It is easy to build, easy to approve, and it rarely changes retention.

The problem is the premise. New customers are not short of information about your product, they are short of a reason to come back tomorrow. A tour answers a question they have not asked yet.

We build onboarding journeys backwards from a single behaviour: the first action that reliably predicts whether someone is still here in ninety days. Everything in the programme either moves a person towards that action or gets cut.

Find the activation moment in your own data

Every product has a threshold behaviour. Completing a profile, making a second purchase, inviting a colleague, listening to three episodes, adding a payment method. Your version is in your data already.

Find it this way. Take everyone who signed up between six and twelve months ago, split them into retained and churned, and compare what each group did in their first fourteen days. Look for the behaviour where the gap between the two groups is widest.

Then check that the relationship holds when you control for obvious confounders such as acquisition channel and plan tier. Plenty of correlations are just a proxy for high-intent traffic, and building a programme around one of those wastes a quarter.

Write the result as a single sentence with a number and a window. Customers who complete two bookings within fourteen days retain at roughly three times the rate of those who complete one. That sentence is the brief for the whole journey.

Map the first thirty days backwards from that action

Start at the activation moment and work backwards through every step a person must take to reach it. Account created, verified, preference set, first item added, first order placed, first order received.

For each step, write down the obstacle rather than the feature. People do not fail to set a delivery preference because they never heard of delivery preferences. They fail because they were on a phone, mid-commute, and the form asked for a postcode they could not remember.

Then decide which obstacle a message can genuinely remove. Some cannot be solved by CRM at all, and naming those honestly is useful, because it sends the problem to the product team where it belongs.

The remaining obstacles become your message set. In most programmes that is four to seven messages across thirty days, not the fifteen that a feature tour produces.

Build the triggers on behaviour, not on elapsed time

A time-based drip sends message three on day five whether or not the person has already done what message three asks for. That is how customers end up being told to complete a step they finished on day one.

Use your segmentation layers here. State decides whether someone is in the onboarding programme at all, behaviour decides which message fires next, and attributes decide the content inside it. The three-layer framework keeps this manageable once the journey has branches.

Practical rules we hold to:

• Every message has an entry condition and an exit condition, both written before the copy.
• A person exits the step the moment they complete its action, even if the message is queued.
• Time-based sends exist only as a fallback when no behavioural signal is available.
• Maximum one onboarding message per person per day across all channels, enforced centrally.
• The whole programme has a hard exit at thirty days, after which people move into business as usual.

That last rule matters. Without a hard exit, people accumulate in onboarding for months and receive a strange mix of beginner guidance and promotional campaigns.

Write to the obstacle and measure the action

Onboarding copy should be short, specific and single-purpose. One message, one action, one link. The subject line names the obstacle, the body removes it, and nothing else competes for attention.

Measure each message on completion of its step, not on opens or clicks. A message with a modest open rate that moves sixty per cent of recipients through a step is doing its job better than a widely opened message that moves nobody.

Report the programme on one number: the share of new customers who reach the activation moment within the window. Track it weekly by signup cohort, since a monthly average hides the effect of every change you make.

Test one variable at a time, and give each test a full cohort before reading it. Onboarding volumes are usually smaller than broadcast volumes, so patience is the difference between a result and a coincidence. The build and iteration side of this sits in our execution work.

What to do this week

• Pull the first fourteen days of behaviour for retained and churned cohorts, and identify the action with the widest gap between them.
• Write the steps to that action in order, with the real obstacle named under each one, and mark which obstacles a message can remove.
• Add an explicit exit condition to every message in your current onboarding programme, plus a hard exit at thirty days.

Every programme we inherit has a segmentation deck somewhere. It has personas with names like Ambitious Amir, a colourful grid, and no connection at all to the audience definitions running in the platform.

The gap exists because the deck was written by strategists and the segments are built by whoever is closest to the send button. Under deadline, people build what the tool makes easy, and the framework quietly stops being used.

So we build segmentation the other way round. Start from what the data can support, keep the number of definitions small, and give every segment a named owner and a refresh rule.

Separate the three layers before you name anything

Confusion comes from treating three different things as one. Pull them apart and most segmentation arguments resolve themselves.

The first layer is state: facts about where someone is right now. Subscribed, active, lapsed, churned, trialling, high value. State is mutually exclusive, so every contact sits in exactly one bucket, and it drives which programme they belong to.

The second layer is attribute: durable descriptive facts such as market, language, product held, acquisition channel and lifecycle start date. Attributes stack freely and drive content selection within a programme.

The third layer is behaviour: what somebody did recently, expressed as a time-bounded event. Viewed a category twice in seven days, abandoned a basket, opened four of the last five sends. Behaviour is volatile and drives triggers, not list membership.

Write each layer on a separate page. If a proposed segment mixes all three, it usually belongs in the triggers rather than the audience structure.

Keep the base set small and countable

We aim for six to ten state segments covering the whole file, with no gaps and no overlaps. Every contact must resolve into one, including the awkward ones such as unsubscribed purchasers and staff accounts.

For each state segment, record four things in a single document:

• The definition in plain English, in one sentence, with no conditionals.
• The technical definition, as the actual query or platform filter, copied verbatim.
• The current count, with the date it was counted.
• The named person who approves changes to the definition.

Count them all and add the numbers up. If the total does not match your total addressable file, the definitions have gaps or overlaps, and that is a genuinely useful thing to find before a campaign goes out.

Resist the request for a special segment for a single campaign. Those definitions live forever, drift from the base set, and are the main reason programmes end up with four hundred audiences nobody understands.

Give every segment a refresh rule and an owner

A segment without a refresh rule is a snapshot pretending to be a definition. Write down how often each one recalculates, and where the calculation happens.

Decide deliberately between warehouse and platform. Complex state logic belongs in the warehouse where it can be tested and versioned, then synced into the platform as a simple attribute. Fast behavioural logic belongs in the platform, close to the trigger.

We put the state layer in the warehouse, refreshed nightly, and let the platform own behaviour in real time. That split keeps the expensive logic in one testable place and the fast logic where latency matters.

Ownership is the part teams skip. Each segment needs one person who approves definition changes, and a changelog entry every time a definition moves. Without that, two people optimise the same audience in opposite directions and nobody can explain the drop in performance.

Decide what personalisation each segment earns

Not every segment deserves bespoke content. Personalisation costs production time, and a variant that nobody measures is pure overhead.

We grade each segment into three tiers.

Tier one gets a dedicated creative treatment and its own reporting. Tier two gets modular blocks swapped inside a shared template. Tier three gets the default, with only the greeting and the product feed varying.

Sizing decides the tier. A segment below roughly two per cent of your addressable file rarely justifies bespoke creative unless its value per customer is exceptional. Be honest about that, and put the saved time into the segments that move revenue.

Review the tiers quarterly against performance. Segments graduate and segments get demoted, and both are normal. The framework exists to be edited, not admired.

Test the framework against your existing programmes

Before you roll anything out, run the new structure against what you already send. Take the message inventory from your audit and map each message to a state segment, an attribute filter and a behavioural trigger.

Anything that will not map is telling you something. Either the framework has a gap, or the message is targeting an audience nobody can defend. Both findings are worth having before launch.

We usually find two or three messages with no home, and they are almost always legacy sends that should have been retired at the audit stage. Fixing the segmentation becomes a good excuse to switch them off. Helping teams get to that structure is a large part of what we do in CRM strategy.

What to do this week

• Write your state, attribute and behaviour layers on three separate pages, and move any mixed definitions into the layer where they belong.
• Document the six to ten state segments with plain English definitions, technical definitions, current counts and named owners.
• Add up the segment counts and reconcile the total against your addressable file, then investigate every gap and overlap you find.

Moving to a new email platform means moving to new sending infrastructure, and mailbox providers have no history with your new IP addresses. They treat an unknown sender cautiously, which is reasonable of them and inconvenient for you.

The fix is warming: a deliberate ramp in volume over two to four weeks, sending to your most engaged contacts first, so providers build a positive record before you send anything at scale. Rush it and you land in spam folders that take months to climb out of.

We have run this process on migrations of several million profiles. The plan below is the one we use, and the order of the steps matters more than the exact daily numbers.

Fix authentication before you send a single message

Warming an IP with broken authentication teaches providers that your mail is suspicious. Everything in this section must be verified before day one of the ramp.

• SPF record published for the sending domain, with the new platform's infrastructure included and the record under the ten lookup limit.
• DKIM signing enabled with a 2048-bit key, and the signing domain aligned with the visible From domain.
• DMARC published, starting at p=none with an aggregate reporting address someone actually reads.
• A dedicated sending subdomain for marketing traffic, kept separate from transactional and corporate mail.
• Reverse DNS on each new IP resolving to a hostname on your own domain.
• Feedback loops registered with the providers that offer them, routed into your suppression logic automatically.

Send a seed test to a spread of Gmail, Outlook, Yahoo and corporate addresses. Check headers, not just the inbox placement, and confirm that both SPF and DKIM pass with alignment.

Build the seed list from proven engagement

The warming audience is the most important decision in the whole exercise. You want contacts who reliably open, click and reply, because positive engagement signals are what build the reputation.

Define the seed list as people who have opened or clicked in the last thirty days, have a valid purchase or login in the last ninety, and have never complained or hard bounced. In most programmes that is between five and fifteen per cent of the file.

Sort that group by recency of engagement and mail it in descending order. Your best contacts see the first send, your merely good contacts join in week three. If your audit surfaced a data quality problem, resolve it before building this list, since the CRM audit checklist exists precisely to catch that kind of issue early.

Ramp the volume across four weeks

A common shape doubles daily volume each day for the first week, then continues doubling every second day, holding steady whenever metrics wobble. Something like this works for a file of a few hundred thousand:

• Days one to three: 200, 500, 1,000 per IP, sent to the most engaged decile only.
• Days four to seven: 2,000, 5,000, 10,000, 20,000, still inside the top engagement tier.
• Week two: 40,000 to 100,000 per day, adding the next engagement tier once complaint rates stay flat.
• Week three: 150,000 to 400,000 per day, introducing your regular campaign content rather than warming sends.
• Week four: full volume, with the least engaged segments reintroduced last, or not at all.

Send at a consistent time each day. Providers read volume spikes as a signal, and an erratic schedule during warming looks like exactly the thing they filter.

Hold the ramp, do not reverse it, if a metric breaks threshold. Reversing volume sharply is itself a signal worth avoiding.

Watch the signals that decide the outcome

Blended metrics will not tell you what is happening. Break every number down by mailbox provider, because Gmail and Microsoft respond to different things and usually fail at different points in the ramp.

Thresholds we hold to during warming:

• Complaint rate under 0.1 per cent per provider. Above 0.3 per cent, pause and cut the audience back to the previous tier.
• Hard bounce rate under 2 per cent. A spike here means the list is older than someone told you.
• Open rate materially above your historical average, because a warming list should outperform your file.
• Deferrals and throttling messages read daily from the platform logs, not weekly.

Deferrals are normal early on. Persistent 4xx responses from one provider after week two mean that provider is not convinced, and the answer is usually tighter audience selection rather than more volume.

On our Premier Padel work, careful warming took delivery past 99 per cent and supported open rates above 45 per cent once the programme reached full volume. That outcome came from patience during the ramp, not from anything clever afterwards.

Plan the hand-off to business as usual

Warming does not end when you hit full volume. Reputation decays with silence, so a dedicated IP needs a reasonably consistent weekly cadence to stay healthy.

Keep the suppression rules you built during warming. The inactivity window, the complaint routing and the bounce handling were doing real work, and quietly dropping them a month later undoes the ramp.

Document the whole exercise: dates, volumes, audiences and provider metrics. The next migration, or the next new IP, starts from evidence instead of memory. This is the same discipline we apply across our implementation projects.

What to do this week

• Verify SPF, DKIM, DMARC and reverse DNS on the new sending domain, and send a seed test that confirms alignment in the headers.
• Build and export the warming seed list, sorted by engagement recency, and check what share of your file it represents.
• Draft the daily volume schedule with named audience tiers, and agree the complaint and bounce thresholds that will pause the ramp.

Most CRM audits produce a deck and very little else. The findings are usually accurate, the recommendations are sensible, and six months later the programme is still sending the same four emails to the same undifferentiated list.

We run audits differently. The deliverable is not a document, it is a ranked backlog with owners and effort estimates, and the audit is not finished until the first three items sit in a sprint.

Below is the checklist we work through, in the order we work through it. For a mid-sized programme it takes about two weeks, longer if nobody has mapped the data before.

Start with the data layer, not the campaigns

Campaign quality is downstream of data quality, so we never begin with creative. We begin with a sample export of a thousand customer profiles and read it by hand. That hour tells us more than a week in admin screens.

The questions we answer first:

• Which system is the source of truth for customer identity, and what key joins records across systems?
• How many profiles exist, and what share are duplicates or orphaned test records?
• Which attributes update in real time, which update nightly, and which have been static since the last import?
• What behavioural events are tracked, and does the event schema match what the platform actually expects?
• Where is consent stored for each contactable address, and can you produce the timestamp and source on demand?

If two of those answers are vague, stop the audit and fix the answers. Everything downstream is guesswork until you can name the source of truth.

Inventory every message a customer can receive

Build one spreadsheet covering every broadcast, triggered message, transactional template, push notification, SMS and in-app message. One row per message, no exceptions, including the ones marketing does not own.

For each row, record the trigger, the audience definition, the owner, the date it was last edited, the volume in the last ninety days, and the headline performance. Then add a column that nobody enjoys filling in: is this message still true?

We routinely find templates that have been sending for two years, referencing a product tier that no longer exists or a support address nobody monitors. Those are not optimisation problems. They are switch-off decisions, and they can be made in an afternoon.

Check deliverability before you judge performance

A programme with a twelve per cent open rate and an authentication problem does not have a content problem. Judging creative before you have cleared the technical path wastes everyone's time.

Work through this list for every sending domain:

• SPF, DKIM and DMARC records present, aligned, and pointing at the domains you actually send from.
• Transactional, marketing and lifecycle traffic separated by subdomain or stream, so one bad campaign cannot damage receipts.
• Hard bounce and complaint rates tracked by domain group, not just as a single blended figure.
• A written inactivity policy, with a defined window after which you stop mailing a non-opener.
• List growth sources documented, with any purchased, scraped or appended data identified and quarantined.

Pull ninety days of delivery data by mailbox provider. Gmail and Microsoft frequently tell different stories, and a blended average hides both.

Score the programme, then rank the fixes

We score four dimensions from one to five: data readiness, deliverability, lifecycle coverage, and measurement. Every score needs a sentence of evidence attached, so the number is arguable rather than decorative.

Lifecycle coverage is the one that usually exposes the gap. Map your customer stages across the top of a page, then place every message from the inventory underneath its stage.

Acquisition and promotion columns tend to be crowded. Onboarding, reactivation and win-back are often empty.

Then rank the fixes. We use a simple impact against effort grid and cap the resulting backlog at twelve items, because a backlog of forty is a way of choosing nothing. Each item gets a named owner, an estimate in days, and a dependency note.

The cap matters more than the scoring method. An audit that produces twelve ranked, owned, estimated items will change the programme. One that produces a hundred observations will not.

Make the audit repeatable

Write down what you pulled, where you pulled it from, and which queries you ran. Six months later, someone will want to know whether things improved, and the answer is only credible if the second audit uses the same method.

We keep the audit workbook in the client's own environment rather than ours. If the checklist only works when an agency runs it, it is a dependency rather than a capability, and that is the wrong outcome. The same principle shapes how we approach CRM strategy engagements generally.

Set a calendar reminder for two quarters out. Re-score the four dimensions, compare, and rebuild the backlog from what you find.

What to do this week

• Export a thousand customer profiles and read them by hand, noting every field that is empty, stale or inconsistent.
• Build the message inventory in a single spreadsheet, one row per message, and flag every template nobody has edited in twelve months.
• Run an authentication check on every sending domain and confirm that transactional traffic is separated from marketing traffic.

Kickoff is at ten on a Monday. The brief is a forty-slide deck about brand positioning. Three of the four platform logins do not work. The analyst who knows how the customer table is built is on leave until the following week.

By Friday the agency has produced a list of questions. By the end of the month it has produced an audit, which is a polite way of saying it has spent four weeks finding out what the client already knew. The retainer clock has been running the whole time.

This is the normal shape of a CRM engagement, and it is avoidable. Almost everything that makes the first month slow is a thing the client already has, in a form nobody thought to hand over.

The brief that costs a month

Most briefs describe ambition and omit constraint. They say the programme should be more personalised, more automated and better measured, which no agency will disagree with and none can act on.

What an agency needs on day one is the opposite: the specific shape of the situation. What exists, what it is wired to, what has already been tried, what is not allowed, and what has to be true by when.

A useful brief is short. Two pages of decisions plus a folder of artefacts beats forty slides of aspiration, because the artefacts are what the work is actually built from.

Write the objective as a sentence with a number and a date, then list what has already been attempted against it and what happened. The failed attempts are the most valuable part of the document and the part most often left out.

Access is the critical path, so start it before kickoff

Access always takes longer than anyone expects. Every week of delay is a week of the engagement spent on something other than the work.

Start the requests two weeks before kickoff, and treat the list as a project with an owner:

• The engagement platform, at a permission level that allows building, not only viewing.
• The analytics and reporting tools, including the raw data warehouse if there is one.
• The read-only database or warehouse schema behind the customer record.
• Whatever handles consent and preferences, plus the records that prove it.
• The domain registrar or DNS, or a named person who can publish a record within a day.
• Ticketing and documentation, so the agency can see what the engineering team is already committed to.

DNS is the one that reliably bites. Authentication changes need a record published, the registrar is often owned by a different department, and a two-day task becomes a three-week one.

Add a named contact per system, not a shared inbox. Access requests that go to a queue arrive after the work they were needed for.

Hand over the numbers you already argue about

Every organisation has a handful of numbers that get re-derived in different ways by different teams. An agency will walk into that argument blind in about week two.

Give them the definitions up front, along with the disagreement. Active customer. Repeat purchase rate. Contactable base. Revenue attributed to CRM. What counts as a new customer after a two-year gap.

This is the practical value of a single customer view, even an imperfect one. If a document exists that says which system owns identity and how records are joined, hand it over on day one. If it does not exist, say so plainly, because that changes the first month's plan considerably.

The same applies to field-level definitions. A data contract listing the attributes the programme depends on, their refresh frequency and their owner is worth more than any brief. Where one exists, it removes weeks of inference.

Then add the awkward numbers. Current deliverability by mailbox provider, complaint rates, the share of the list that has not opened anything in a year. Agencies find these in the first fortnight anyway, and sharing them early buys a month of honest planning.

Say what is fixed and what is negotiable

The fastest way to waste an agency's first month is to let them design against constraints that were never stated. Write the constraints down, in three groups.

Fixed: the platform contract with two years left, the legal review that every send must pass, the fortnightly release train, the brand rules that cannot move. These bound the solution space and should be stated without apology.

Negotiable: things that could change with a business case, such as a template system, an approval step or a data feed frequency. Naming these tells the agency where to spend effort arguing.

Open: everything nobody has decided yet. Being explicit that something is open is more useful than a vague answer that gets treated as settled.

Budget belongs in the fixed list. An agency that knows the annual number will propose work that fits it, and a roadmap finance will actually fund is built from the same information. Withholding the budget produces proposals nobody can approve.

Commercial constraints count too. If certain segments cannot receive discounts, or a category carries a margin the programme must protect, say so at the start. That is the same discipline we described in loyalty and margin, and it is far cheaper to apply before a mechanic is designed than after.

Name who decides, and how approval works

Engagements stall on approval more often than on capability. The work is built, then waits ten days for sign-off from someone who was not at kickoff and disagrees with a decision made in week one.

Put four names in the brief. The single person who can approve creative and mechanics. The person who owns the data side and can commit engineering time. The legal or compliance reviewer. And the person who breaks a tie when the first two disagree.

Then write the approval path as a sequence with durations. Who sees the work, in what order, and how long each step takes. If legal review takes five working days, that is a fact the plan has to be built around rather than a surprise to be discovered.

One more thing, easy to give and rarely given: the last two years of programme history. Which campaigns were tried, what the results were, and which ideas have already been rejected internally and why. Without it an agency will confidently propose something that failed in 2024.

What day thirty should look like

If the handover is done properly, the first month produces shipped work rather than a discovery document. A reasonable expectation is one journey rebuilt or launched, one measurement problem fixed, and a ranked backlog everyone has argued over.

Agree that expectation in writing before the engagement starts. An agency that knows it is judged on what shipped in the first month will ask for access in week minus two, which is the behaviour you wanted anyway. Our own CRM strategy engagements are set up on exactly that basis.

A client's marketing director asked us a fair question in a planning session this spring. The team had been shown a demonstration where an automated system built an audience, wrote the email, chose the offer and scheduled the send, all from a one-line instruction. Could we do that, and if not, why not?

The honest answer is that most of the pieces in that demonstration work. The part that does not work is the arrangement: one system making four kinds of decision, with no separation between them and no record of which decision caused which outcome.

We do use automated decisioning in the programmes we run. What we hold to is a boundary that has not moved much in two years. The system may decide who, when, and in what order. A person decides what it costs, what it claims, and whether we are allowed to contact this person at all.

Three different decisions get called "the campaign"

Untangling this is most of the work. What looks like a single decision is usually three, with very different consequences when it goes wrong.

The first is decisioning: which message a given person should receive, from a set of candidates, and when. It is reversible, it is measurable, and a mistake costs one slightly less relevant email.

The second is authorship: what the message actually says. A mistake here can be a false claim, a tone that damages the brand, or a statement the business cannot stand behind.

The third is economics: what the offer is worth, who qualifies, and what margin the business is prepared to give up. A mistake here is expensive immediately, and often at scale before anyone notices.

Most disagreements about automation in CRM are really disagreements about which of these three is being discussed. Once they are separated, the answers become much less controversial.

What we let an automated system decide

Inside a bounded set of options, ranking and timing are well suited to automation, and humans are not especially good at them.

• Ranking candidate messages. Given a person and a list of messages they are eligible for, choose the one to send. This is next best action as it has been practised for years, and the scoring underneath it is usually an ordinary propensity model rather than anything new.
• Timing within an allowed window. Choosing the hour of send for an individual, inside a window a person has defined and inside the contact policy.
• Allocating scarce contact slots. When three journeys want the same person this week and the cap allows one, deciding which one wins, according to a priority order a person has set.
• Selecting content blocks from an approved library. Choosing which dynamic content module to show from a set that has already been reviewed and signed off.
• Drafting. Producing variants, subject lines and summaries for a person to review, edit and approve before anything is scheduled.
• Operational work. Writing a first version of a segment query, reconciling two reports, flagging a journey whose volume has dropped, summarising a week of test results.

The common feature is that the system is choosing from options someone has already approved. It is picking from a menu, not writing one.

Drafting deserves its own note, because that is where teams get the fastest return and the most trouble. A model can produce forty subject lines in a minute. Whether any of them sound like your brand depends entirely on whether somebody has written the voice down first. That is the argument we made in keeping a brand voice consistent at scale. Without that, automated drafting produces volume and a slow drift towards a generic register that nobody notices until a customer mentions it.

What stays with a person

Four areas we do not automate, and the reasoning is the same in each case: the cost of being wrong is not proportional to the benefit of being right.

Offer economics. Discount depth, who qualifies, and how often. A system optimising for conversion will find that a larger discount converts better, because it does. Margin sits outside its view unless somebody models it carefully, and by the time a mispriced offer shows up in the management accounts it has been sent to a lot of people.

Brand and factual claims. Anything asserting a fact about the product, a price, a delivery promise, a regulated statement or a comparison with a competitor. These need a human who is accountable for their truth. In regulated categories that accountability is a legal requirement rather than a preference.

Consent and data use. No automated system decides who may be contacted, on what channel, on what lawful basis. Under GDPR and its equivalents, the record of consent and the logic of suppression are the things you will be asked to produce, and they must be explainable by a person who understands them. Suppression logic in particular should be deliberately dull and deliberately human.

Anything irreversible at scale. Sending to the whole file, changing a global contact policy, altering data in the source system, deleting records. A person presses that button.

Guardrails that make the rest safe

The division of labour only holds if it is built into the system rather than written in a policy document nobody reads.

1. A bounded action space. The system chooses from an enumerated set of approved actions. It cannot invent a new message type, a new audience or a new offer. Everything it can do is something a person has already said yes to.
2. Hard limits it cannot override. Frequency caps, suppression lists, send volume ceilings and market restrictions are enforced outside the decisioning layer, so no optimisation can trade them away.
3. A logged decision for every send. Which options were considered, which was chosen, on what score, under which model version. Without this you cannot debug a strange outcome, and you cannot answer a customer asking why they received something.
4. Staged exposure. New automated logic starts on a small share of the audience, with a control group held back, and grows only when the numbers justify it.
5. A stop control that works in seconds. One person, one switch, reverting to the previous behaviour without an engineering deployment.
6. A named owner. Every automated decision has a human whose job it is to defend it. If nobody can be named, the automation does not ship.

None of this is novel. It is the same discipline that applies to any automated system touching customers, applied to a newer set of tools.

Read a sample of what it did, every week

Automated decisioning fails quietly. Performance does not collapse; it drifts, and the metrics that would reveal the drift are averages that hide it.

So we sit down weekly and read actual decisions. Twenty or thirty at random, plus the ones at the extremes: the person who received the most messages, the person who received none, the offer that went to the smallest segment. You are looking for decisions that are defensible in aggregate but obviously wrong for that individual.

The accountability question is the one still waiting for a good answer. A system can hold a decision, but it cannot own one. When an automated send goes wrong in a way that reaches a customer or a regulator, the organisation needs a named person who understood the logic, agreed to it, and can explain it. Designing that person into the process from the start is much easier than appointing them afterwards.

Nearly every quarterly review deck we are shown contains a cohort chart. The triangular grid of months, shaded from dark to light, with retention decaying left to right. Everyone nods at it. Nobody has ever changed a plan because of it.

The chart is not the problem. Cohort analysis is the only routine way to see whether a programme is changing customer behaviour, as opposed to whether a good month happened. The problem is that the standard chart is built to be shown rather than to answer a question, so it answers none.

A cohort view earns its place when somebody could act differently depending on what it says. That constraint changes how you define the cohort, what you plot, and which comparisons you allow yourself to make.

Define the cohort around a decision you might take

Start from the decision, then build the cohort that informs it. The default of grouping by signup month is fine for a health check and almost useless for a roadmap choice.

Useful cohort definitions we come back to:

• First-purchase category or product. Tells you whether some entry points produce better customers, which changes merchandising and acquisition briefs.
• Acquisition channel or campaign. Tells you whether cheap traffic is expensive later, which changes the budget split.
• First-order discount depth, banded. Tells you what you are buying with the welcome offer.
• Onboarding treatment received. Tells you whether the journey you built is doing anything after the first month.
• First-week behaviour, such as completing a profile or a second session. Tells you which activation milestone is worth designing around.

Each of those maps to a decision with a budget behind it. Signup month maps to nothing you can change.

Write the decision on the chart before you build it. One line at the top: "if early-discount cohorts retain materially worse, we cut the welcome offer depth in Q3". A chart with that sentence attached gets discussed differently from one captioned "retention by cohort".

Read the curve in three parts

A retention curve is not one number, and averaging it destroys the information. Read it as three separate things, because each has a different cause and a different fix.

The first drop. From period zero to period one, usually the steepest fall on the chart. This is an onboarding and expectation problem: the product or service did not do what the purchase implied, or nobody helped the customer reach the point where it would. CRM can move this, and it is normally where the fastest wins are.

The slope. The decay across the middle periods. This is habit and relevance. Frequency, assortment, and whether your contact strategy matches the natural purchase cycle. Moves slowly, responds to programme design rather than single campaigns.

The floor. Whether the curve flattens and at what level. A curve that flattens has a loyal core, and the floor height multiplied by cohort size is roughly what your base is worth. A curve that keeps declining has no core, which is a business-model finding rather than a marketing one.

Plot the three separately over successive cohorts. A programme change that improves the first drop but leaves the slope untouched is still a real win, and it will be invisible in a blended churn rate that mixes all three together.

Compare cohorts only when one thing differs

The most common analytical error we see is comparing cohorts that differ in several ways at once and attributing the gap to the most recent change.

The January cohort was acquired during a sale, in a different channel mix, at a different discount depth, and it also got the new onboarding journey. Its retention is better. The onboarding journey gets the credit, the team invests further, and nothing improves next quarter.

Guardrails worth holding to:

1. Hold the acquisition source constant, or split the comparison by source and check the direction is consistent within each.
2. Hold the discount band constant. Promotional cohorts behave differently for at least a year.
3. Compare equal maturity windows. A three-month-old cohort read at month three against a year-old cohort read at month twelve is not a comparison.
4. Check seasonality by looking at the same month in previous years, not only at adjacent months.
5. Watch the denominator. If acquisition volume doubled, the newer cohort contains different people, and mix explains more than treatment.

When too many things differ, say so and stop. An honest "we cannot separate these effects" is a finding, and it usually justifies running an actual experiment next quarter instead of another retrospective read.

Turn the finding into work somebody owns

A cohort finding becomes a roadmap item only if it survives three questions. What would we do differently? How much is it worth? Who owns it?

Work the value question with the same arithmetic every time. Take the difference in repeat purchase rate between the cohorts, apply it to the volume of customers entering that state each month, and convert to contribution rather than revenue. Express the result as annual contribution and state the assumptions beside it.

That converts "discount-acquired customers retain worse" into something a planning meeting can act on. Shifting the welcome offer from twenty per cent to fifteen is worth roughly this much a year if the difference holds, and costs us this many first orders. Now two people can disagree about a number rather than about a chart.

Record the decision and its expected effect where the next reader will find it. The decision log exists for exactly this: cohort findings mature over months, and by the time the evidence arrives the people involved have moved on or reinterpreted what they meant.

Then set the read date. A cohort-driven change takes at least one full cohort maturity window to evaluate, so book the review at the point the data will exist, not at the end of the quarter.

What a cohort chart cannot tell you

Three limits, all worth stating out loud when the chart goes up.

Cohorts are observational. They show that a group behaved differently, never that your treatment caused it. Where a decision is expensive or reversible only at cost, the cohort view is the hypothesis and a holdout or a proper experiment is the evidence. Treating a cohort difference as causal is how a plausible finding becomes a wasted year.

Cohorts also see only the customers you already have. They cannot tell you what the brand campaign did to acquisition quality, or how much of the change came from pricing, distribution or a competitor's move. That question needs the top-down view, which is why we paired it with marketing mix modelling for CRM teams earlier this month. The two methods answer different questions and disagree productively.

The last limit is about lifetime value. A cohort's value estimate is a projection until the cohort has matured, and the projection is most confident exactly when it is least useful. Keep the horizon short, state it, and resist the temptation to extrapolate a curve you have only seen the first third of.

What to do this week

• Take your standing cohort chart and write the decision it would inform at the top. If you cannot, rebuild the cohort definition around one you actually face.
• Split your current retention curve into first drop, slope and floor, and track the three separately across the last six cohorts.
• Pick one cohort difference you already believe in, cost it in annual contribution with the assumptions written down, and take it to the next planning meeting as a proposal rather than an observation.

The finance team commissions a marketing mix model. Eight months of work later, the results land: paid search is doing well, the brand campaign is doing better than anyone expected, and CRM has a coefficient close to zero. A meeting is scheduled to discuss the CRM budget.

The CRM lead in that meeting is usually right on the substance and completely unprepared to argue it. The programme genuinely does drive revenue, the model genuinely does not see it, and explaining why requires a conversation about collinearity that nobody in the room wants to have on a Tuesday afternoon.

We have sat on the CRM side of that meeting several times. The way to win it is to be involved eight months earlier, when the variables are being specified, rather than eight months later when the coefficients are being defended. What follows is what a CRM team needs to know to do that.

What the model measures, and why CRM fits it badly

A marketing mix model is a regression on aggregated time series. Weekly or daily sales on one side, weekly or daily marketing activity on the other, plus controls for price, seasonality, distribution, competitor activity and whatever else moves the business. It estimates how much of the variation in sales each input explains.

That design has real strengths. It needs no user-level tracking, it covers offline and brand activity, and it can be pointed at the whole business rather than the trackable part of it. As privacy constraints have tightened, this is why MMM came back into fashion after a decade of user-level attribution models being the default.

The weaknesses fall disproportionately on CRM. Three of them, in order of how much damage they do.

CRM volume tracks the business rather than driving it. You send more when there is more to say and more people to say it to, and both of those move with the trading calendar. The model sees CRM activity rising and falling with sales, which is exactly what a variable with no causal effect would also look like.

CRM effects are fast and small per message. Media effects are modelled with adstock and diminishing returns over weeks. A triggered email's effect is mostly spent within days, at a magnitude that is hard to separate from noise in a weekly aggregate.

And much of what CRM does is retention, which shows up as sales that did not fall. A model fitted to explain variation struggles with a variable whose job is to reduce variation.

The collinearity problem, stated plainly

This is the part worth being able to explain in one minute, because it is the crux of the meeting.

When two inputs move together, a regression cannot reliably tell them apart. It will allocate the shared effect between them in a way that depends on small details of the data and the specification. The split can change substantially if you add a week of data or change a control.

CRM send volume is usually correlated with the promotional calendar, with paid media bursts, and with the season. It is one of the most collinear variables in the whole model. So its estimated coefficient is unstable almost by construction, and a small or negative value is weak evidence rather than a finding.

The right response is not to claim the model is wrong. It is to ask two questions of whoever built it. What is the uncertainty interval on the CRM coefficient, and how much does it move across reasonable alternative specifications.

If the interval is wide and the estimate swings across specifications, the honest conclusion is that the model cannot resolve CRM at this level of detail. That is a very different statement from "CRM does not work", and getting it stated in those words is most of the job.

Give the model variables it can actually use

Much of the problem is fixable at specification time, and the CRM team is the only group that can fix it. Bring these to the modelling team before the data is pulled.

• Split the programme into behaviourally distinct groups. Broadcast promotional sends, triggered lifecycle messages and operational messages behave nothing alike. Modelled as one line called "CRM emails", they average into meaninglessness.
• Supply reach, not sends. Messages delivered, or better, delivered to people who have engaged recently. Send counts inflated by an unengaged file add variation that carries no effect.
• Separate promotional depth from message volume. If your sends carry discounts, the model will otherwise credit the discount to CRM or the CRM to the discount. Supply discount depth as its own variable.
• Flag the calendar explicitly. Peak weeks, sale periods and any week with an unusual send pattern. Controls that absorb the seasonality stop it being attributed to whatever moved with it.
• Provide base size as a control. Active contactable file size changes slowly and matters enormously. Without it, growth in the base is invisible and its effect lands on send volume.

Each of these reduces the collinearity a little, and together they can move the CRM estimate from uninterpretable to merely uncertain.

One thing not to bring: a request that the model be adjusted until CRM looks better. That request is remembered, and it discredits the next legitimate methodological point you make.

Use holdouts to calibrate the model, not to dispute it

The strongest position a CRM team can hold in a modelling conversation is to arrive with experimental results already in hand.

Geographic or audience holdouts give a direct read on incrementality, independent of any regression. A holdout group excluded from a programme for a defined period, compared against a matched group that received it, measures the thing the model is trying to estimate.

Modern practice is to use those results as inputs rather than as rebuttals. Experiment results can inform the model directly, tightening the range the coefficient is allowed to occupy, so the regression is anchored by measured effects instead of guessing between collinear variables. Ask whether the model is being calibrated this way, and offer the experiments if it is not.

For that to be possible, the experiments have to exist before the model is built. That means running a standing holdout at the programme level, not just per campaign, and keeping it for long enough to read a retention effect rather than a promotional one. A quarter is a reasonable minimum; a full year is better for anything seasonal.

Treat this as infrastructure rather than as a project. The holdout costs a small amount of revenue every week and it is the only asset that settles these arguments quickly.

Agree what the model is allowed to settle

The failure mode we see most is not a bad model. It is a good model used to answer questions it was never designed for.

An MMM works at the level of channel budgets over months. It is reasonable to ask it whether the CRM programme as a whole is contributing, and roughly at what scale. It is not reasonable to ask it whether a particular journey should have four messages or five, or whether Tuesday beats Thursday. Those are questions for controlled tests within the programme, of the kind we described when covering send-time optimisation, where the unit of analysis matches the unit of decision.

Write the division down before the results arrive. Which decisions the model informs, which decisions experiments inform, and what happens when the two disagree. Our preference is explicit: where a well-run experiment and a model conflict on the same question, the experiment wins, and the disagreement is recorded as a prompt to examine the specification.

Recording it is the point. This is exactly what a decision log is for, and the entry should capture what was decided, on what evidence, and what would change the answer. Eight months later, when the next model run produces a different number, that entry is the difference between a calm review and the same meeting again.

Before the next run, ask the modelling team for the current CRM specification and the uncertainty intervals, and ask whether any experiment results are being used to calibrate it. Those two questions will tell you within a week how much weight the output deserves.

On a Monday morning the recommendation block in the weekly email is empty for about a fifth of recipients. Nobody deployed anything on the marketing side. The campaign ran as scheduled, the template is unchanged, and the platform reports no errors.

Three hours later someone works out that a release the previous Thursday renamed a field in the product-view event, from product_id to item_id, as part of a tidy-up. The engineer who made the change had no reason to think anyone outside the app was reading it. The pipeline accepted the new shape without complaint, because it was built to be forgiving. The transformation that fills the recommendation table quietly produced nothing.

This is the most common category of CRM incident we are called into, and it is almost never caused by carelessness. It is caused by an absent agreement. Nobody had written down which events the marketing programme depends on, what shape they must arrive in, and who to tell before changing them.

What a data contract is, in practice

A data contract is a versioned, machine-readable definition of a dataset that a producing team commits to and a consuming team builds against. Strip away the vocabulary and it contains six things:

• The schema: field names, types, whether each is required, and allowed values for anything enumerated.
• Semantics: what each field means in plain English, including the edge cases. Does order total include tax, shipping and discount, and in which currency.
• The producer, named as a team rather than a person.
• Freshness and volume expectations: how late the data may be, and the range of daily volume outside which something is wrong.
• The change policy: what counts as a breaking change, how much notice is required, and how versions coexist during a migration.
• The consumers, so a producer can see who they would affect.

It is not a document in a wiki. A contract that lives where nobody works is a record of an intention. The contract needs to sit in the repository, in a format a test can read, so that violating it fails a build rather than an email campaign.

Start with the events that have already broken something

Do not try to put the whole event stream under contract. The programme that tries this stalls within a month, because the inventory work is large and produces nothing visible until it is finished.

Start from incidents. Pull the last two or three quarters of anything that went wrong with personalisation, segmentation or reporting, and list the events involved. That list is short, specific, and already has organisational agreement that it matters.

Then add the events that feed anything automated and customer-facing. In most programmes that means the small set underneath the decision layer: the signals that drive next best action and the features behind any scoring model. These are the highest-risk data paths in the business, because failure is silent. A broken dashboard is noticed within a day. A model quietly running on a field that has been null for three weeks is not.

Ten to fifteen events is a good first scope. Covering those properly is worth more than covering everything loosely.

Put the contract where engineers already work

The contract should be a file in the producing service's repository, reviewed like code, with the schema expressed in whatever format your stack already uses.

That placement is a deliberate choice about ownership. If the contract lives in the marketing team's space, then changing it is marketing's job and engineers will not read it. If it lives beside the code that emits the event, then a developer changing that code sees the contract in the same diff, and the review conversation happens at the right moment.

Marketing's contribution is the semantic layer, not the schema syntax. The plain-English meaning of each field, the business rules, the list of things that have gone wrong before. Write that section yourself and keep it specific. "Revenue excludes VAT, excludes shipping, and is recorded at the point of dispatch rather than order placement" prevents more incidents than any type declaration.

Version the contract properly. A breaking change means a new version with a stated overlap period during which both shapes are produced, not a rename on a Thursday afternoon.

Enforce at three points, because one is not enough

A contract that is not tested is a description of how things used to work.

At the producer. A test in the producing service's build asserts that emitted events match the contract. This is the cheapest place to catch a problem, because it happens before the change reaches anything else.

In the pipeline. Validate on arrival. Events that violate the contract go to a quarantine table rather than into the main stream, and the count of quarantined events is alerted on. Be careful with the default here: many ELT setups are deliberately permissive, loading whatever arrives so that nothing is lost, which is a sensible default for storage and a poor one for decisions.

At the consumer. Tests on the transformation layer assert the properties the programme actually relies on. In a dbt project this is straightforward: not-null, uniqueness, accepted values, and relationships between tables. Add freshness checks, because stale data passes every schema test ever written.

Alert on all three to a channel the CRM team reads. The failure mode we see most often is an alert that fires correctly into a channel only the data team watches. There it competes with every other alert and gets triaged as low priority, because nobody in that channel knows a campaign depends on it.

Marketing's side of the bargain

Contracts fail when they are treated as a demand rather than an agreement. If marketing asks for guarantees and offers nothing, engineering will treat the process as overhead and comply minimally.

What the marketing side has to bring:

• A named owner for each consuming dataset, who answers questions and approves changes.
• Deprecation. If a field was requested for a campaign two years ago and nothing reads it now, say so and let it be removed. Unused fields under contract are a tax on every future change.
• Fewer one-off requests. A new field added for a single campaign, outside the schema, is how the drift starts.
• Realistic freshness requirements. Asking for real-time on a dataset that a weekly email reads makes every other requirement look negotiable.
• Attendance at the review when a breaking change is proposed, including the ones that arrive at an inconvenient time.

This is also the moment to be honest about the single customer view. Contracts govern the inputs; they do not resolve identity. If two systems disagree about who a person is, well-specified events will simply deliver that disagreement more reliably. Identity resolution is a separate piece of work and should not be smuggled into this one.

What changes once the contracts exist

The immediate effect is fewer silent failures, which is hard to celebrate because it shows up as an absence.

The more interesting effect is on what becomes buildable. Models are only as stable as their features, and the practical constraint on the kind of scoring described in propensity models you can run is rarely the algorithm. It is that the inputs change shape without warning, so a model that validated well in March is making decisions on different data by June.

Contracts also change how event tracking requests get handled. Once there is a defined process for adding an event, marketing stops asking for tags to be added ad hoc and starts specifying properly, which is faster for both sides after the first month.

The part that stays hard is that a contract makes ownership disputes visible without settling them. When an event has three producers and no clear owner, writing the contract is the moment everyone discovers it. That discovery is valuable, and it is also a conversation that a schema file cannot have for you. Expect to spend the first few weeks on ownership rather than syntax, and budget for it openly.

Two years ago this month, the first of the large mailbox providers began applying published requirements to bulk senders. A great many marketing teams spent that February in a DNS panel for the first time. Microsoft followed with its own set last May. The requirements now cover the majority of most brands' addressable inboxes.

What has changed since is not mainly technical. When we audit a programme today, the authentication records are almost always present and usually correct. Two years ago that was the finding. Today it is the starting position, and the interesting failures sit somewhere else entirely.

That shift is worth naming plainly, because plenty of teams still describe their authentication set-up as an achievement. It is not. It is the entry fee, and the things that separate a healthy programme from a struggling one are now downstream of it.

What the current baseline actually looks like

If you want a single description of where a competent programme sits at the start of this year, it is roughly this.

• SPF, DKIM and DMARC published for every domain and subdomain that sends, with alignment confirmed by inspection rather than assumed from a dashboard.
• A DMARC policy at enforcement, meaning quarantine or reject, not monitoring only.
• Aggregate DMARC reports parsed into something a person reads weekly, with an alert when an unrecognised source appears.
• Transactional, marketing and lifecycle traffic separated onto different subdomains so that one bad campaign cannot damage receipts.
• One-click unsubscribe present on every marketing stream, including the ones sent from systems marketing does not own, and honoured across all systems within the required window.
• Complaint rates monitored per mailbox provider, weekly, with a named owner.
• A written inactivity policy that actually stops mail going to people who have not engaged.

Every item on that list applies across the major providers. The specifics differ, and the Microsoft requirements brought their own details, which we went through in the Outlook sender requirements. Building one baseline that satisfies all of them is far easier than maintaining three variants.

The failures have moved from DNS to process

A record that was correct when it was published stays correct until somebody changes something. In practice, somebody always does.

The recurring causes of a broken set-up now are organisational rather than technical:

• A new tool starts sending as the company domain because a team bought it with a card and nobody was asked.
• A rebrand or domain migration moves the From address, and the authentication work follows six weeks later than the first send.
• An email platform rotates DKIM keys and the corresponding DNS record is never updated, because the person who owned that relationship has changed role.
• DMARC reports arrive at a mailbox nobody has opened since the project that created it ended.
• A subdomain created for a one-off campaign in a regional market inherits nothing and is never decommissioned.

The remedy for all five is the same, and it is dull. Somebody owns sender authentication as a named responsibility, there is a change process for anything that sends mail as the company, and the reports feed an alert rather than a folder.

We have started treating that ownership question as part of the audit rather than a recommendation from it. A programme where nobody can answer who is allowed to edit a DNS record will regress, whatever its records say today.

Enforcement is the step most teams still have not taken

Publishing a DMARC record in monitoring mode satisfies a compliance checkbox and protects nobody. It observes, and it instructs receiving servers to do nothing differently.

Moving to enforcement is what stops other people sending as you, and it remains the most common gap we find. The reason is usually a reasonable fear of blocking legitimate mail, and the answer is a staged path rather than a single change.

1. Complete the sender inventory from the aggregate reports, and keep reading them until a fortnight passes with no unidentified source.
2. Authenticate or relocate every legitimate source. Anything that cannot be authenticated moves to a subdomain of its own or stops.
3. Move to quarantine with a small percentage applied, raise it in steps, and watch the reports between steps.
4. Move to reject once quarantine has run clean for several weeks.
5. Set a policy for subdomains explicitly rather than relying on inheritance you have not checked.

The whole sequence takes a couple of months of mostly waiting. It is not difficult work and it is almost never scheduled, because nothing visibly breaks while it is left undone.

BIMI is a consequence, not a strategy

Every few months a brand team asks about getting the logo into the inbox. BIMI is a reasonable thing to want, and a poor thing to lead with.

It requires DMARC at enforcement, a logo in the right format, and for the major providers a certificate proving you own the mark. In other words, it requires you to have already finished the work above, plus a trademark process and an annual cost.

That is why we treat it as a reward rather than a goal. If a brand team's request for BIMI is what finally funds the move to enforcement, that is a good outcome. If it becomes the project, teams end up buying a certificate for a domain whose complaint rate is the actual problem.

Be realistic about the benefit too. Display varies by client and by context, and the sender name and subject line still do most of the work in deciding whether a message is opened. Recognition is worth something. It is not worth reordering the roadmap for.

Complaint rate and list hygiene are where the work now lives

With authentication settled, the deliverability problems we are called into trace back to who is on the list and how often they are mailed.

The complaint rate is the only requirement that cannot be configured. It is a behavioural measure, reported per provider, and it responds to a short list of things. The quality of the acquisition source, the frequency of sending, how easy the unsubscribe is to find, and whether dormant addresses are still being mailed.

Good list hygiene at this point means four habits, held to consistently:

• Every acquisition source is documented, measured separately, and can be switched off on its own.
• A sunset policy runs automatically, with a defined inactivity window and a final re-permission attempt before the stop.
• The preference centre offers a real choice of frequency and topic, because the alternative to a useful option is the spam button.
• Engagement is measured on clicks and site behaviour rather than opens, since machine-fetched opens make the open signal unreliable for this purpose.

That last point has grown more important as inbox clients have changed how mail is presented and categorised, something we looked at when Apple Mail introduced categories. Where a message lands and how it is grouped now affects engagement metrics in ways that have nothing to do with your sending set-up.

What to check this quarter

Pull the DMARC policy for every sending domain and subdomain, and write down which are at enforcement and which are not. If the answer to any is monitoring only, schedule the staged move now rather than after the next incident.

Then find the last six weeks of aggregate reports and look for a sender you cannot name. There is usually one, and it is usually a tool somebody bought in good faith. Finding it is a better use of a morning than any campaign optimisation available to you.

The brief comes down from someone senior after a bad month. List growth has flattened, unsubscribes are up, and the instruction is to reduce them. Within a week a designer has been asked to make the footer link smaller, lighter and further down the page.

It works, in the narrow sense. Unsubscribes fall. Complaints rise, and complaints are the expensive currency. A person who cannot find the opt-out uses the report button instead, and providers read that button as evidence about your sending rather than about one email.

The useful framing is that an unsubscribe is not the problem. It is the receipt for a decision that was made several messages earlier. The work is reducing how many people arrive at that decision, not obstructing the last step.

Hiding the link only changes the exit route

Start with the arithmetic that makes the design instinct wrong. An unsubscribe removes one address from your list. A spam complaint removes that address and also contributes to a provider-level signal that affects delivery to everybody else on that domain.

The published complaint rate thresholds the major providers work to are low — measured in tenths of a per cent — and sustained sending above them costs placement across the whole programme. Trading an unsubscribe for a complaint is a bad trade at almost any exchange rate.

There is also a compliance floor that is not negotiable. Bulk senders are expected to carry a working one-click unsubscribe in the message headers and to action the request within a couple of days. Test yours this week rather than assuming it works. Send a message to a real mailbox, use the provider's own unsubscribe control rather than the footer link, and confirm the suppression landed in your platform. We find broken header unsubscribes in a surprising number of otherwise well-run programmes, usually after a template migration.

Make the footer link plain, legible and where people expect it. The goal is that nobody who wants to leave ever has to think about how.

Reduce the pressure before you touch anything else

The most reliable cause of unsubscribes is volume, and the second is volume disguised as relevance. If a programme has increased send frequency over the last year without changing its cap structure, that is where the answer is.

What we look at first:

• Messages per person per week, by engagement tier, over the last quarter — not average sends, which hides the tail.
• The share of people receiving the maximum allowed, which tells you whether the cap is a limit or a target.
• Whether triggered and automated messages count against the cap or sit outside it.
• Which campaigns were added in the last six months, and what was removed to make room. Usually nothing was.

Then set frequency capping by tier rather than by campaign. Highly engaged customers tolerate more; people who last opened four months ago do not, and sending them the same weekly cadence produces unsubscribes and complaints in roughly equal measure.

A reduction in volume for the least engaged tier almost always improves the programme's total revenue as well, because the sends that were generating the opt-outs were generating very little else.

Offer a smaller decision than all or nothing

Most unsubscribe pages present one option: leave. A good preference centre presents several, and the one that recovers the most people is the simplest.

Give people a pause. Four weeks, three months, until after a season. Say the date it ends, honour it exactly, and send a single message when it does. In our experience a meaningful share of people who take a pause remain contactable afterwards, and they would otherwise have been gone permanently.

Then offer the other reductions:

• Fewer messages, as a stated number rather than a vague promise of "less often".
• Topic choices that map to things people actually recognise — new arrivals, sale, order updates, the specific brand or category they buy.
• Channel choices, so someone who dislikes email but reads push can say so.
• A single clear route to full unsubscribe, on the same page, not buried behind the alternatives.

Two design rules make the difference between a preference centre that works and one that annoys. It must be reachable without logging in, because the person reading is on a phone and will not retrieve a password to do you a favour. And every option must take effect immediately, including in journeys already in flight, or you will have promised something you do not deliver.

Fix the messages that cause it, not the ones that carry it

Unsubscribe rate is attributed to the send that carried the click, which is misleading. The message people leave on is often just the one that arrived after a run of poor ones.

Look at the sequence instead. Pull the last five messages each unsubscriber received and look for patterns. The same offer three times, a campaign for a category they have never bought, a re-send to openers that felt like a mistake.

Two sources of avoidable irritation come up repeatedly. The first is promotional content pushed into operational messages — the pattern we took apart in the transactional email audit. People expect a receipt to be a receipt, and marketing in that slot is read as a trick, which produces complaints rather than unsubscribes.

The second is contact with people who never knowingly joined. Customers acquired through a third party often do not recognise your name at all, and the answer is a properly designed introduction rather than immediate campaign pressure. We covered that handover in journeys for marketplace customers, and it remains the highest-unsubscribe cohort in most retail programmes.

Measure it per person, and let people leave quietly

Per-send unsubscribe rate is a weak metric. It rewards mailing a smaller, better audience and punishes reaching new people, and it tells you nothing about cumulative fatigue.

Report two numbers instead. The share of the active list that unsubscribed in the quarter, and the share of new subscribers who left within their first ninety days. The first measures pressure on the programme. The second measures whether your acquisition promise and your sending behaviour match.

Finally, accept that some of the list should go without being asked. A sunset policy that stops mailing people after a defined period of no engagement removes the addresses most likely to complain, before they do. Done properly it lowers both your unsubscribe rate and your complaint rate, and it improves placement for everyone still receiving you.

What to change this month

• Send yourself a campaign and complete an unsubscribe using the mailbox provider's own control, then confirm the suppression arrived.
• Add a pause option to the unsubscribe page with three stated durations, and make it work without a login.
• Pull the last five messages received by everyone who unsubscribed last month, and read fifty of those sequences yourself.

Every platform migration plan we are shown has the same shape. Eight weeks of build, a cut-over weekend, then a few weeks described as stabilisation. Somewhere in that period, usually without anyone writing it down, the programme stops sending.

The gap gets called a quiet phase. In practice it is a month in which nobody receives a welcome journey, no baskets are recovered, and the reactivation series does not run. The revenue does not come back later, because the customers it would have reached moved on.

A dark month is a planning decision rather than a technical requirement. Nothing about replacing an engagement platform requires you to stop talking to customers, provided the old system stays switched on while the new one earns its traffic.

The dark month comes from cutting over all at once

Big-bang cut-over is attractive because it is simple to describe and easy to put on a plan. One date, one switch, one set of approvals.

It also concentrates every risk on a single weekend. Templates, data feeds, journey logic, sending reputation, integrations and reporting all change at once, and when something misbehaves on the Monday there is no way to tell which change caused it.

The response is always the same: pause sends until it is sorted. That pause is the dark month, and it is produced by the plan, not by the platform.

The alternative is to treat migration as a traffic-shifting exercise. Both systems run. Programmes move over one at a time, in an order you choose. The old platform keeps sending everything that has not moved yet, and stays available as a rollback until the last programme is across.

Run both, and move one programme at a time

Parallel running costs a few weeks of double licensing. That is almost always cheaper than the sends you would otherwise lose, and the comparison is worth putting in the business case explicitly.

Move programmes in order of risk and volume, lowest first:

1. A single low-volume triggered message, such as a review request, to prove the end-to-end path.
2. Transactional and service messages, if they are in scope, since the content is stable and the audiences are small per send.
3. Triggered lifecycle journeys: welcome, basket, replenishment. These carry most of the value and benefit from careful attention.
4. Segmented broadcasts to engaged recipients.
5. Full-file broadcasts, last, once the sending reputation on the new platform is established.

One rule holds the whole thing together: a programme lives in exactly one platform at any moment. Never run the same journey in both, because the suppression logic in each system cannot see the other, and customers receive everything twice.

Turn the old version off at the moment the new one goes live, in the same working session, with both people in the same call.

Warm the new sending identity with traffic you already trust

New sending infrastructure has no reputation. Mailbox providers judge it on early behaviour, and the fastest way to fail is to send a large promotional broadcast to a cold list on day one.

IP warming is why the migration order above starts with triggered messages. Transactional and lifecycle traffic has excellent engagement, small daily volumes and predictable patterns, which is exactly what a new sending identity needs to establish itself.

The practice we follow:

• Start with your most engaged recipients, defined by opens and clicks in the last thirty days, and widen gradually.
• Increase daily volume in steps, holding at each step long enough to see the result rather than pushing through a schedule.
• Watch delivery by mailbox provider, not as a blended figure. Providers respond to new senders differently and at different speeds.
• Keep authentication records for the new platform published and verified before the first send, including the return-path domain.
• Stop increasing volume the moment complaint or bounce rates move, and hold until they settle.

Plan a realistic number of weeks, and do not let a launch date compress it. Reputation damage during warming takes far longer to repair than the schedule you were protecting.

The choice between a new domain and your existing sending domain deserves an explicit decision. Keeping the domain and changing the underlying infrastructure carries over some history, but it also means a problem during warming touches mail you already depend on. Whichever you choose, write down the reason, because someone will ask in six months.

Port the data model, not the campaign library

The instinct is to recreate what exists. That is how programmes arrive on a new platform carrying the same two hundred templates, forty of which nobody has sent in two years.

Migration is the one moment when deleting things is easy to approve. Inventory every message, mark each keep, rebuild or retire, and expect a third of the library to be retirable. Rebuild only what earns its place.

Data is the opposite: it needs more care than people budget for, not less. Start from the single customer view rather than from the old platform's field list, because that list encodes years of workarounds.

Write a data contract for the new platform before any field is mapped. Field name, type, allowed values, refresh frequency, owner, and the source system. Anything without an owner does not get created.

Feed it the way you feed everything else. If profile and audience data already arrives through reverse ETL from the warehouse, point that pipeline at the new destination and keep a single definition of each attribute. Migrations that let the new platform compute its own version of a segment produce two numbers for the same thing within a quarter.

Where there is no warehouse to work from, the approach in building a single customer view without a CDP still gives you one place to define identity before the mapping starts.

Decide the cut-over rules and the rollback in advance

Each programme move needs three things agreed in writing beforehand. What must be true to go live. What you will watch for the first seventy-two hours. And what would make you switch back.

Rollback is the one people skip, usually because the old platform is still running and everyone assumes reverting is obvious. It is not obvious at three in the afternoon when a journey is misfiring and two teams disagree about whether it is serious.

Name the specific numbers. Delivery rate below a stated floor, complaint rate above a stated ceiling, or a volume that differs from forecast by more than an agreed margin. Name the person who calls it, and keep the old journey in a paused state rather than deleted until the new one has run for a full cycle.

Then keep the deliverability dashboard from the old platform alive for a quarter after the last programme moves. It is the only baseline you will have when someone asks whether things got better or worse.

A new lifecycle manager joined a client in October and asked a reasonable question in her second week. Do we put a discount in the welcome series or not?

Nobody could answer. The test had been run, everyone agreed on that much. It was roughly eighteen months ago, the person who ran it had left, the platform's reporting only retained a year of campaign data, and the deck was in somebody's personal drive. What survived was a sentence in a strategy document saying the welcome offer had been "validated", with no number, no date and no definition of what it had been validated against.

So the team ran it again. Two months of a programme's testing capacity spent rediscovering something the company already knew. This is the most common form of waste we see in mature CRM programmes, and it has nothing to do with test design.

A decision log is not a test archive

The distinction matters, because most teams already have something that looks like a log and it does not solve this problem.

A test archive is a folder of results. It is organised by campaign, it grows without limit, and nobody reads it because finding the relevant entry takes longer than rerunning the test.

A decision log is organised by question. One row per question the business has settled, holding what was decided, on what evidence, and when it expires. A test that produced no decision does not get a row of its own. A decision made without a test does, because those are exactly the ones that get relitigated.

The test is evidence. The decision is the asset. Keeping only the evidence is how you end up with a shelf full of results and a team that cannot say what it believes.

The fields that make an entry useful two years later

Keep it short enough that people actually fill it in. We use nine fields, and the discipline is that an entry with an empty field is not finished.

1. The question, in plain language. "Does a first-order discount in the welcome series increase ninety-day revenue per new subscriber?" Not "welcome series test v3".
2. The date the decision was taken, and the period the evidence covers. Seasonality is the most common reason an old result stops holding.
3. What was actually compared. Both variants described well enough to rebuild them, including the audience definition and any exclusions.
4. The population and the volume. How many people in each arm, and which audience they were drawn from.
5. The primary metric and its measurement window, chosen before the test ran. One metric, not five.
6. The result, as an effect size with an interval rather than a verdict. "Between minus one and plus four per cent, centred near one" is a far more useful record than "no significant difference".
7. The decision taken, which is not the same as the result. Sometimes you adopt a variant that did not win, for cost or brand reasons, and that reasoning needs to be written down or it will look like an error later.
8. Confidence, in one word. High, medium or low, judged by the person who ran it.
9. Where the raw data lives, as a query, a table name or an export path that will still resolve after the platform is replaced.

Nine fields take about fifteen minutes to fill in. The test took six weeks.

Write the entry before the test runs, not after

Open the row when you design the test. Question, comparison, population, primary metric and window all get written down before a single send goes out, and nothing in that set may be edited afterwards.

This single habit fixes several problems at once. It stops the metric being chosen after the results are in, which is the most common way an A/B test produces a conclusion it does not support. It forces an explicit decision rule: what result would make us change, and what result would make us leave things alone. And it surfaces the tests that are underpowered before you spend six weeks on them, because writing the expected volume next to the expected effect size makes the arithmetic unavoidable.

Agree the stopping rule in the same sitting. When the test will be read, and that it will not be read early because someone is impatient. Peeking at a running test and stopping when it looks good is how a programme accumulates results that never replicate, whatever the significance figure on the dashboard says.

Record the results that found nothing

Most tests do not move the metric. That is a normal property of a well-run programme, not a failure, and those entries are the ones with the highest long-term value.

A null result tells the next person that this question has been asked, at this volume, and did not produce an answer worth acting on. Without it, the same idea returns in the next planning cycle wearing a different name, and the team spends another six weeks on it.

Be careful about how you phrase it. "No difference" is almost never what you found. What you found is that any difference was smaller than the test could detect, which is a statement about your sample as much as about the variants. Recording the interval rather than the verdict keeps that honest, and lets someone later judge whether it is worth retesting at a larger volume.

The same applies to programme-level evidence. When you run a holdout group and find that a journey's incremental contribution is smaller than everyone assumed, that finding must survive the person who ran it. The incremental read on a programme is the most expensive evidence you will produce, and it is also the most likely to be quietly forgotten when it is unflattering.

Give every decision an expiry date

An entry without a review date becomes folklore. Somebody quotes it three years on, the underlying conditions have changed, and no one can remember how strong the evidence was.

Set the review date by how fast the thing decays. Our rough guidance:

• Creative and subject-line findings: six months. Audience habits and competitor behaviour move underneath them.
• Offer and discount decisions: one year, or sooner if margin structure changes.
• Timing and cadence: one year. Everything we said about send-time optimisation depends on behaviour that shifts with device mix and seasonality.
• Structural decisions such as journey architecture or contact policy: two years.

When a date passes, the entry is not deleted. It moves to a review list, and somebody decides whether to retest, to reaffirm without evidence, or to mark it unresolved. All three are legitimate outcomes. The only bad outcome is an entry nobody has looked at since it was written, still being cited as fact.

Keep it where the platform cannot take it away

Put the log outside the marketing platform. Platforms get replaced, reporting windows expire, and accounts get closed when a contract ends. A plain table in the company's own document system or warehouse will outlive all of it.

Give it one owner, and review it in the same meeting where next quarter's tests are planned. Reading the last six entries before proposing new ones takes ten minutes, and it is the single cheapest way to stop repeating work.

The hard part is not the format. It is that nobody is rewarded for writing down a null result, and everybody is busy in the week a test finishes. The only fix we have found is to make the entry part of the definition of done, so a test is not finished when the deck is presented, but when the row is complete.