Customer 360

Combining customer, product, interaction and behavioural data

A joined view with a defined purpose

Customer 360 is an operating view that connects relevant information about a customer across systems. It can help service teams understand products, interactions and unresolved issues. It does not require putting every available record into one database, and “360” does not guarantee completeness or accuracy.

Start with a use case: helping an agent handle a disputed card transaction, maintaining contact details or identifying related business relationships. Decide which records are necessary, their authoritative sources and who can access them. Data collected for one purpose is not automatically available for every marketing, credit or partner use.

Resolve identity without inventing certainty

Use stable customer and product identifiers, with evidence for links between records. Separate a person, legal entity, account, household, authorised representative and device. A shared address, phone or device can suggest a relationship without proving the records belong to one individual.

Deterministic matches use explicit identifiers; probabilistic matches use evidence with uncertainty. Define confidence and review rules appropriate to the use. Preserve the ability to unmerge a wrong association and identify downstream effects. A false match can expose another person's financial information or influence an incorrect decision.

Sources, freshness and authority

For each important field, retain source, meaning, observation time and relevant effective time. Resolve competing addresses or contact details through a documented survivorship policy. The most recently loaded record is not always the most recently verified or appropriate value.

A joined dashboard is not necessarily the system authorised to change a balance, block an account or execute a payment. Route actions to the responsible system and check the user's authority. Label stale or unavailable information. Pending card activity, posted balance and available funds should not be collapsed into one unexplained number.

Privacy and correction

Apply access according to role and purpose, with additional protection for sensitive information. Record access and control exports, service accounts and partner interfaces. A database entitlement should not bypass customer-level restrictions or confidentiality boundaries.

Define retention and correction processes under applicable law. Correcting a source should update affected views and notify responsible consumers where needed. Preserve history that must be retained, with access and use restrictions. A deletion request does not automatically require destroying every transaction or statutory record, and retaining a record does not authorise unrestricted reuse.

Worked example: the shared contact

In this fictional bank, two family members share a phone number. A matching routine merges their profiles, and a service agent sees the wrong card history. The bank restricts the incorrect view, investigates exposure and separates the records using verified identifiers.

It then identifies decisions and communications produced from the merged profile. Merely fixing the dashboard would leave those effects unaddressed. The matching policy is changed so that a shared contact alone cannot support this consequential merge without additional evidence.

Operational assurance

Measure false matches, duplicate profiles, stale critical fields, failed updates and unauthorised access. Test conflicting sources, late-arriving events, authorised representatives, corrections and unmerge propagation. Product teams should reconcile customer counts to defined populations; one person with several accounts is not several acquired customers unless that metric explicitly counts accounts.

For a European example, the EU GDPR establishes principles including purpose limitation, data minimisation and accuracy. Bank secrecy, retention and cross-border requirements must also be assessed for the actual jurisdiction and activity.

Takeaway

A useful customer view combines evidence, purpose, freshness and correction. More joined data is only valuable when the links are reliable and the users have authority to see and act on it.

Continue to Personalisation.