Six artifacts you can fill in this week: an entity starter model, a source inventory sheet, identity rules with confidence tiers, a minimum attribute dictionary, three use cases and a 60-day plan. It decides which sources enter scope, how person and account get modelled separately, and what has to be true before you widen anything.
The trap most data teams walked into: inventory all forty source systems before anyone has agreed what a customer is, treat identity resolution as a vendor feature you switch on and trust, measure progress in sources connected and attributes available, then choose the use cases at the end from whatever the table happens to contain.
What the teams whose 360 gets used do: name one decision a single team will make differently tomorrow, model person and account as separate entities with an explicit relationship, write the identity rules by hand with confidence tiers and a review queue, and make every source pay for its own connection before the next one joins.
Modelled Separately
Marketing wants to talk to a person, finance reports on an account, and support answers whoever is on the phone. Build one flat customer record and all three get a number they can disprove, then stop trusting the model inside a quarter. Model person and account as separate entities with an explicit relationship, and let each use case pick its side. B2B sinks here.
Score each system on three things before you connect it: does it carry an identifier you can match on, is its real refresh frequency fast enough for the decision, and is its consent status documented rather than assumed. Two out of three goes in scope. One goes to the backlog with the reason written down, so the same argument does not restart six weeks later.
Four criteria before the model grows: one decision measurably changed against a holdout, an unresolved rate the sponsor has seen and accepted, every merge reversible and auditable in under an hour, and consent and deletion propagating to every downstream copy. A dashboard is not evidence that a decision changed. Fail any one and you widen nothing, which is why the gate gets written first.
Decision, attributes needed, measurable outcome, named owner, and the date you read the number. Three, not ten. The entity model is agreed in the same fortnight and the source sheet scored row by row. If three owners cannot sign in an hour, you have found the real blocker and it is not the data.
Deterministic rules on two sources first: normalised email, E.164 phone, account number from the issuing system only. Household links, it never merges. Role addresses are rejected outright. Stand up the review queue and the merge audit log in the same fortnight, because a merge you cannot reverse makes one bad rule permanent.
Thirteen attributes, not four hundred. Each gets a definition, a type, a source, a refresh interval and a consent flag. Set freshness from the decision: the failure signal refreshes hourly because service recovery works in hours, and the rest can wait for the morning batch. Privacy signs off the consent joins.
Put the remaining use cases live, then read the number on the agreed date against a holdout cohort. Retained revenue, repeat purchase rate, or acquisition spend wasted on customers you already have. Take the four go/no-go criteria to the sponsor. Widen the model only once one of those numbers has moved.
No, and choosing first is the usual mistake. Every component in the kit is filled in on paper: entity grain, source scores, identity rules, attribute definitions, three decisions. Do that work and the platform question mostly answers itself, because you will know which capabilities you are actually buying and which you already own.
No, it sits above it. The warehouse holds the sources. The kit decides which of them enter the profile, at what grain, under which identity rules, and with whose consent recorded where. Most of the first fortnight is agreement rather than pipeline work, which is why the data lead runs it with three business owners.
Four things ship. Deterministic identity rules running on two sources with a live review queue, a thirteen-attribute dictionary with consent joined at query time, one use case in production, and a measured outcome against a holdout. If any of those is missing on day 60 the gate fails and you widen nothing
Because one flat record breaks in B2B. The account signs, the person clicks, and support answers whoever calls. A single row hands all three teams a number they can disprove, and trust goes inside a quarter. Separate entities with an explicit relationship let each use case pick its side and keep the profile defensible.
Unmergeable is a valid answer. A record no rule resolves stays as its own profile, flagged, and the unresolved rate goes to the sponsor as a number to accept rather than hide. Forcing matches to lift the resolution rate is how one person ends up reading another person's order history.
CDOs and CMOs who have been asked for a single customer view and know the last attempt stalled. It assumes several source systems, an unsettled argument about what a customer is, and a sponsor who now wants one decision to change inside a quarter rather than another roadmap.
Drop your details and we'll send 18 Months To A Table Nobody Queries. Sequencing Did It. straight to your inbox - no spam, unsubscribe anytime.
Book a 30-minute customer data review (logiciel.io)
Download the starter kit