A Customer-360 Data-Model Starter You Can Actually Reuse

Almost every Customer-360 data model gets invented from scratch, on the clock, by whoever happens to be in the room when ingestion starts. Someone connects the CRM, someone else maps a marketing feed, and the "model" emerges as a side effect of which sources arrived first. Six months later it has eighty objects, three things that all sort of mean "account," and nobody can say which field is the source of truth for a phone number. That isn't a model. It's sediment.

This piece hands you the opposite: a small, deliberate starter schema you can copy, argue with, and adapt. Not a 200-object enterprise data model — those are real, but you don't start there. A good Customer-360 model is the smallest set of entities that lets you resolve one customer and answer the questions your first agent will actually ask. Everything else is an extension you add on evidence, not on spec.

Model backward from the first question

Fix the design rule before any entities, because it decides what survives. A data model is not a faithful transcription of your source systems — if it were, you'd just query the sources. The model exists to answer questions a human or an agent will ask, fast and unambiguously. So you don't begin with "what data do we have?" You begin with "what is the first question that has to be answerable?"

For most teams that question is some flavor of: who is this person, what are they worth to us, what did they last do, and is anything on fire? Write it down literally. It tells you which entities are load-bearing and which are decoration. A starter model that answers it cleanly beats a comprehensive one that answers it slowly — three joins deep, with two candidate values for every field.

“

Your data model should be the shortest path from a raw event to a confident answer about one customer. If a question takes a meeting to answer, the model failed, not the analyst.

The seven entities that earn their place

Here is the starter. Seven canonical entities cover the vast majority of B2B and B2C cases before you customize. Map your real sources into these rather than cloning each source table — the convergence of many sources into one entity is exactly what makes a 360 a 360 instead of a pile of copies.

• Party — the unified person or organization. The center of gravity; everything else points back here. In Salesforce Data Cloud terms this is the Unified Individual. Keep it deliberately thin — identity, name, type — not a junk drawer for every attribute that has nowhere else to live.
• Contact Point — the channels you can reach a Party on: email, phone, address, handle. Separate from Party on purpose, because one person has many, and each carries its own validity and consent state.
• Account / Membership — the organization a Party belongs to, or the household, plan, or relationship that groups people. This is what turns individuals into the unit you actually sell to or serve.
• Interaction — a touch: a web session, an email open, a call, a chat, an ad click. High-volume, append-only, timestamped. Your behavioral spine, and the entity freshness lives or dies on.
• Transaction — an order, payment, subscription, claim, or contract. The money entity. What a Party is worth is computed from here, not guessed.
• Case / Engagement — an open thread of work: a support case, an onboarding, an opportunity. State that has a status and an owner and can be 'on fire.'
• Consent / Preference — what the Party has and hasn't agreed to, per channel and purpose. Not optional, not a footnote: an agent that messages someone who opted out is a liability, not a feature.

Notice what's not here: no separate object per source system, no "Salesforce Contact" and "Marketing Contact" and "Support Contact" living side by side. Those are inputs that map into Party and Contact Point. If your model has three things that all mean "the same human," you have a mapping problem wearing a modeling costume.

Keys and time: the two decisions that quietly decide everything

An architect's real work in a 360 isn't drawing the boxes — it's two unglamorous decisions inside them that nothing downstream can recover from: the key and the timestamp.

On keys: every entity needs a stable, unique key, and the interesting one is the match key on Party — the attributes identity resolution uses to decide that two source records are the same human. Email is the usual anchor; it is also shared (team inboxes), reused (recycled addresses), and entered wrong. Pick your match rules deliberately and write down the tradeoff. Over-merge and you fuse two real people into one ghost; under-merge and your '360' is three partial views of the same customer. There is no neutral setting — only a choice you made on purpose, or one that got made for you.

On time: Interaction and Transaction are useless without a correct event-time field — the moment the thing actually happened, not the moment it loaded into your warehouse. Mix those up and 'last activity' silently becomes 'last sync,' your recency logic lies, and every agent grounded on it confidently cites stale behavior. Decide, per entity, which timestamp is canonical, and treat it as load-bearing rather than metadata.

Relationships are the model — don't skip them

Seven entities in a list are not a model. The model is the edges between them: a Party has many Contact Points, belongs to an Account, generates Interactions and Transactions, and owns open Cases. Those relationships are what let one query walk from a person to what they bought to what's currently broken for them — which is the entire point of a 360.

Teams skip relationships because each entity looks fine in isolation and the data is 'all there.' Then the first real question — 'show me high-value customers with an open complaint' — needs Transaction joined to Case joined to Party, and the joins don't exist because nobody wired the foreign keys. The data was present and practically siloed. Present is not connected, and connected is the whole job.

The agent is the acceptance test

Here's what makes this starter different from the one you'd have drawn three years ago. The most demanding consumer of the model isn't a dashboard — it's an agent that reads the resolved data and takes an action on it. A human silently corrects ambiguity: shown two phone numbers, they infer the current one and move on. An agent grounded on the model quotes whatever value it's handed, with full confidence, and acts on it.

That gives you a clean acceptance test for the whole schema: would you let an agent answer your first question off this model, unsupervised? If the answer is no because there are two candidate emails, an ambiguous 'latest' interaction, or a consent state you can't say out loud — that's not a prompt to patch later. It's a modeling gap, surfaced early by the most honest reviewer you have. This is what 'data before agents' means in practice: the agent doesn't forgive a sloppy model, it amplifies it. Say one Party in twenty resolves wrong — a 5% error a human eyeballs past becomes one in twenty agent actions taken against the wrong customer, at machine speed, while you sleep.

“

A model a human can squint at and a model an agent can act on are different bars. Build to the second one and the first comes free.

Extend without sliding back into sediment

The starter is the floor, not the ceiling — you will outgrow seven entities, and you should. The discipline is in how you grow. Add an entity when a real question needs it, not because a source system has a table you haven't mapped yet. Industry specifics — a Policy, a Loyalty Member, a Work Order, a Shipment — are legitimate additions. Reach for the standard object your platform already ships before you invent a custom one, because standard objects come pre-wired into identity resolution and the unified profile, and you inherit that wiring for free.

• Extend on a question, not on a source. A new entity needs a named decision it unblocks, or it doesn't ship.
• Prefer standard objects to custom clones — you keep the downstream wiring instead of rebuilding it.
• Keep Party thin. Every attribute you're tempted to bolt onto it probably belongs on Contact Point, Transaction, or a calculated insight.
• Re-run the agent acceptance test after each addition. A new entity that reintroduces ambiguity is a regression, not a feature.

Done this way, the model stays legible at fifty entities the same way it was at seven, because each one entered through the same gate. Done the other way — mapping whatever arrived, deferring the keys, skipping the edges — you get the eighty-object swamp, and no amount of agent cleverness fishes a clean answer out of it. A reusable Customer-360 model isn't a diagram you download; it's a small set of decisions made in a fixed order: start from the first question, stand up the seven entities, get the match key and event time right, wire the relationships, and let the agent be the consumer that won't let you fake it. This is the front half of how we run Data-to-Agent — the model is the Agent Ready stage, and every agent we build, run, and tie our fee to afterward is only ever as good as the seven entities underneath it. Get the starter right and the rest of the program has something solid to stand on; skip it, and you'll spend the agent budget paying for the model you didn't build.