There is one question that predicts whether a Salesforce marketing programme will succeed: can a person in your marketing team build a segment from unified customer data without asking an engineer?
If yes, everything else is ordinary delivery work. If no, every personalisation project will disappoint and nobody will be able to say exactly why.
What this package delivers
- An identity resolution ruleset that is short enough to explain in one meeting and tested against named individuals, not counts.
- Reconciliation rules for every attribute that appears in a message — the thing behind almost every “why did the email say Dear Bob” ticket.
- A computed attribute layer: engaged, active, lapsed, high value — defined once, referenced everywhere.
- A definitions register, one page, so “what counts as active” has one answer.
- Consent modelled correctly, resolving to the restrictive value when sources disagree.
Why this is the project, not the prerequisite
Teams arrive with a personalisation wish list — next-best-product, lifecycle stage, replenishment timing — and assume the work sits in the campaign tool. It does not. Every one of those needs an attribute computed on a profile that is reliably one person.
Fix the graph and the wish list becomes ordinary work. Skip it and the wish list becomes a series of near-misses that quietly erode trust in the platform — usually blamed on the platform rather than on the model underneath it.
The failure you will not notice
Under-matching is visible: counts look low and someone complains a known customer appears twice. Over-matching is invisible in aggregate — the counts look better. You only find it by opening individual profiles and asking whether the linked records really belong to one human. That is why this package tests with ten named people before it tests with numbers.
What you get
| Deliverable | Detail |
|---|---|
| Source inventory | Every source on one page: what it is authoritative for, how often it lands, which identifier it carries |
| Identity resolution ruleset | Two to four match rules, normalised, with a written reason for each |
| Reconciliation rules | Attribute by attribute for everything message-facing: salutation, email, mobile, consent, language, country |
| Test individuals | Ten named people with their expected unified state, documented so anyone can re-check after a change |
| Computed attributes | The dozen or so definitions your campaigns and reports actually use |
| Definitions register | One page: name, plain-English meaning, refresh cadence, owner |
| Segmentation layer | Base audiences and platform-level eligibility rules that every campaign inherits automatically |
| Handover | Two sessions with your team, recorded, plus the written model |
How it runs
- Week 1 — inventory and test cases. Sources mapped, ten test individuals chosen and their expected state written down before anything is built.
- Week 2 — narrow ruleset. One or two tight match rules, run, then inspect the ten people and find out which failed and why.
- Week 3 — widen and reconcile. Rules adjusted; message-facing attributes decided deliberately.
- Weeks 4–5 — computed attributes and segments. The definitions layer, plus eligibility rules.
- Week 6 — document and hand over.
This pays back whether or not you migrate
If you are weighing a move to Marketing Cloud Next, this is the readiness gate — without it, a migration reproduces today’s problems on newer infrastructure. But the work is not wasted if you stay: a unified data foundation pays back in Account Engagement, in Sales Cloud, in Service and in reporting. It is the least regrettable investment on the roadmap.
Best for
- Teams whose personalisation “works in testing” and disappoints in production
- Organisations where the same customer exists in three systems and nobody can say which is right
- Anyone weighing a Marketing Cloud Next migration who wants to know what would need to be true first
- Marketing teams who need to ask engineering for every segment
Price and duration
From €7,900. Four to six weeks. Fixed scope, fixed price. The range reflects source count and whether Data 360 is already provisioned.
If you are not sure this is the right starting point, the Platform Health Check at €2,900 will tell you — and its findings feed straight into this if you continue.
Sound like your org?
Thirty minutes, free, no slides. Bring your questions about scope, timing or whether this package is even the right one — you will get straight answers.