Customer 360: Build a Reliable Customer Data Foundation
A Customer 360 foundation should connect the evidence required for defined customer decisions. It should not copy every available field into one supposedly complete profile. The foundation becomes reliable only when it preserves who or what each record represents, how identities were matched, when events occurred, where each value came from and why the organisation may use it.
Begin with the decision, not the platform
Different decisions require different customer representations. A service team may need the account, open case and recent contact. A churn model may need the customer relationship, product holdings and prior service history. A household offer may require consent and a reliable household relationship.
Management should name the decision, population and permitted use before selecting fields. This scope determines which entities, relationships, history and quality standards matter. It also prevents the platform from accumulating information that has no valid role in the decision.
Define the customer and the relationships around it
The organisation may serve a person, household, business, account or network of related parties. One person can hold several accounts. Several people can use one household or business account. A delivery address or telephone number can connect records without proving that they belong to the same individual.
The data model should represent these entities and relationships separately. It should state which entity receives the service, owns the contract, uses the product and authorises an action. This structure prevents the ambiguous word customer from hiding material differences in authority and behaviour.
Treat identity resolution as an evidential judgement
Reliable identifiers can support deterministic matches. Incomplete or inconsistent records may require probabilistic comparison across name, contact, address and behavioural evidence. Neither method removes uncertainty.
The foundation should retain the matched records, rule or model, confidence and date of the identity decision. It should also distinguish a false match from a missed match because their consequences differ. A false match can disclose data or contaminate a model; a missed match can duplicate contact or fragment the journey. High-consequence uses should require stronger evidence or human review.
Preserve source observations and preferred values
Two systems may record different addresses, contact preferences or product states. A survivorship rule can choose the value that an application displays, but that choice does not make the other observation disappear or become false.
The foundation should retain each source value, its effective date, collection context and quality status. It can then produce a preferred value for a defined purpose while preserving the evidence needed for audit and correction. Analysts can also determine whether an apparent customer change reflects behaviour or a new source rule.
Keep event time and processing time
A transaction may occur on Monday and reach the analytical platform on Wednesday. A correction may arrive later but apply to the original event. If the platform retains only its current state, analysts cannot reconstruct what the organisation knew when it made a decision.
Customer 360 should preserve when the event occurred, when the system recorded it and when a value became effective. Models and reports can then use only the evidence available at the decision time. This discipline prevents future information from leaking into historical analysis and makes model evaluation reproducible.
Define shared measures without erasing context
Terms such as active customer, purchase, complaint, interaction, product holding and churn need explicit definitions. The definition may differ across businesses, products and decisions. A subscription lapse, inactive loyalty account and closed service contract are not interchangeable churn events.
Shared definitions should specify the entity, event, period, exclusions and source. When a channel uses a different operational meaning, the foundation should preserve that distinction instead of forcing false consistency. Management gains comparable measures without losing the context that explains them.
Govern quality, purpose and correction
For each field and derived feature, the organisation should record the source, owner, purpose, update frequency and known limitations. Quality monitoring should cover completeness, duplication, validity, timeliness and consistency by system and relevant customer group.
The organisation must also define who may access the information, how long it remains available and whether the proposed use is compatible with the basis on which it was collected. Customers and staff need a route to correct identity and source errors. A technically accessible field is not automatically suitable for analysis or action.
Connect decisions with later outcomes
A unified profile does not improve a decision by itself. The foundation must supply governed measures and features to research, models, dashboards and workflows. It must also record the action that management or a system took and the outcome that followed.
This feedback allows the organisation to evaluate a segment, prediction or intervention. It can identify whether a poor result came from the analytical method, an identity error, stale data or failed execution. Without that loop, Customer 360 can centralise information while leaving decisions unimproved.
Apply the design to conflicting household records
Consider two adults who share a telephone number and delivery address. One uses a loyalty number in store. The other orders online with a different email. A returned item arrives under the shared telephone number after a system has merged both people into one profile.
The foundation should represent two people, one possible household relationship, separate accounts and the original transactions. It should retain the evidence and confidence supporting the household link without assigning every purchase to one person. The return remains connected to the original order and authorised account.
If either adult corrects a contact detail or objects to a use, the organisation can identify the affected source, relationship and downstream feature. The example shows why a useful Customer 360 view preserves identity evidence and commercial history instead of replacing them with one convenient profile.
Specify a foundation that downstream teams can trust
Marketways begins with the customer decisions and entities that the organisation needs to represent. We define the relationship model, identity rules, match thresholds, source precedence, time logic, shared measures, quality controls and correction route.
We then test matches and non-matches, report uncertain joins and specify how downstream analytics should respond to missing or late data. The resulting foundation supports segmentation, churn, value, journeys and agentic workflows with governed evidence rather than an indiscriminate accumulation of customer data.