Single Customer View: One Person, Five Records, No Agreement
The same customer bought in a store under a misspelt surname, ordered online with a work email, joined the loyalty programme with a mobile number, logged a support ticket from a personal address, and appears in the CRM twice because a rep created a lead. Every system is confident it has the right record. None of them is talking about the same person.
A single customer view is what fixes that, and it is far less about buying a platform than about deciding four things: what makes two records the same person, which system wins on each field, what happens when a match is wrong, and what the customer actually consented to. This page covers all four, with the Australian obligations that attach.
Realistic ROI
Four Decisions That Make or Break a Single Customer View
Every failed customer data project failed on one of these four, and usually on the second.
There is no reliable identifier for a consumer
Email addresses are shared between partners, changed when people leave jobs and mistyped at the counter. Mobile numbers are recycled and stored in three different formats. Names are misspelt, hyphenated, transliterated and abbreviated. Addresses are entered inconsistently, especially unit numbers. Any matching rule based on one field alone will be wrong in both directions, so real matching uses combinations with different confidence levels and accepts that a residue always needs a human.
A wrong merge is much worse than a missed one
Failing to match two records leaves you with a duplicate, which is untidy. Wrongly merging two people gives one customer sight of another’s purchase history, which is a privacy incident, and pulling the records apart afterwards is genuinely difficult once orders, loyalty points and communications have been attached to the merged identity. Bias the rules towards caution, keep the contributing source records intact, and route the uncertain cases to review rather than guessing.
Survivorship has to be decided field by field
When two records disagree about a phone number, something has to decide which one appears in the unified view. The answer differs per field: the most recently transacted address usually wins, the loyalty system may be authoritative for date of birth, finance owns the billing entity, and the support system is often the freshest source of a mobile number. Write these rules down before building, because the alternative is that whichever system synced last wins, which is not a rule at all.
Consent travels with the record and the channel
Combining data does not combine permissions. Under the Privacy Act 1988 and the Australian Privacy Principles, personal information should generally be used for the purpose it was collected for or a purpose the person would reasonably expect. Under the Spam Act 2003, commercial electronic messages need consent, accurate sender identification and a working unsubscribe. A customer who gave a service email address to arrange a delivery has not signed up to a newsletter, and a unified view must carry that distinction rather than flattening it.
How a Single Customer View Is Actually Built
Six stages. The middle two are where the entire quality of the result is determined.
Collect from every source
Point of sale, online store, CRM, loyalty, marketing platform, support desk and any spreadsheet that turns out to be operational. Each source keeps its own identifier and its records are copied rather than moved, so the unified view is built on top of the sources rather than replacing them. That means a bad matching decision is always recoverable.
Standardise before comparing
Mobile numbers into one consistent format regardless of whether they were entered with a leading zero, an international prefix or spaces. Emails lowercased and trimmed. Names split and case corrected. Addresses parsed into components with Australian conventions handled, including unit and street type variations. Most of the matching improvement people expect from clever algorithms actually comes from this unglamorous step.
Match with graded confidence
Exact agreement on a strong identifier such as a verified email plus a matching surname is a high confidence link. Agreement on mobile plus postcode is moderate. Similar names at the same address is a candidate for review, not an automatic merge. Grading the confidence lets you automate the clear cases and put a human on the rest, which is the only approach that stays accurate as the base grows.
Build the unified record
The unified view is assembled from the linked sources using the survivorship rules, and it records which source each field came from and when. That provenance is what makes the record trustworthy: when someone questions an address, you can show where it came from rather than defending an algorithm nobody can inspect.
Consent and suppression
Consent status held per channel with the evidence of when and how it was given, plus suppression for unsubscribes, complaints, bounces and deceased notifications. Suppression has to be network wide and immediate, because an unsubscribe honoured in one system and not another is exactly the failure the Spam Act is concerned with.
Publish back to the systems
The unified view is only useful if the systems that serve customers can see it: the counter knows this shopper’s online history, the support agent sees the loyalty status, the marketing platform receives a deduplicated audience with correct consent. Publishing back also needs care, since writing a merged identity into a source system can be difficult to undo.
What a Unified View Changes
| Task | Traditional | Unified View | Notes |
|---|---|---|---|
| Customer at the counter | Staff see in store purchases only | Full history across channels | The most visible improvement, and the one staff notice within a day. |
| Support enquiry | Agent searches three systems | One record with order and loyalty context | Cuts handling time noticeably because the agent stops hunting across tabs. |
| Marketing audience | Exported per system, overlapping | Deduplicated with consent applied | Stops the same person receiving three versions of the same campaign. |
| Unsubscribe request | Honoured in the sending system only | Suppressed everywhere immediately | Directly relevant to Spam Act obligations, and a common source of complaints. |
| Access or deletion request | A manual hunt across systems | One lookup, defined process | Privacy Act rights are hard to honour when you cannot find every copy of a person. |
| Measuring customer value | Per channel, always understated | Across every channel they use | Multichannel customers are usually far more valuable than either channel shows alone. |
| Duplicate loyalty accounts | Merged manually on complaint | Detected and reviewed proactively | Points balances need care on merge, and the customer should be told what happened. |
| An ambiguous match | Merged optimistically or ignored | Held in a review queue with evidence | The design choice that determines whether you ever have a privacy incident here. |
Where Customer Data Projects Cause Damage
Matching rules tuned for coverage
A rule that maximises the number of matches will merge two different people who share a common surname and a suburb, and the result is one customer seeing another’s order history. That is a privacy incident, not a data quality issue. Tune for precision instead, accept that a proportion of duplicates will survive, and give the review queue enough evidence that a person can decide quickly. A duplicate is an inconvenience; a wrong merge is a notification conversation.
Consent flattened during consolidation
Bringing five systems together tempts everyone to resolve conflicting marketing flags by taking the most permissive value. That is precisely backwards. Consent should be resolved conservatively, held per channel with its evidence, and a suppression in any source should suppress everywhere. Under the Spam Act 2003 the burden is on the sender to show consent, and a unified view that cannot produce the evidence for a given address is a liability rather than an asset.
No way to undo a merge
Merges will be wrong sometimes, and the question is whether that is a five minute correction or a week of forensic work. Keep every contributing source record intact and unmodified, treat the unified record as a derived view over them, and store the linking decisions as data. Systems that physically merge and discard the originals cannot be corrected, and the pressure to avoid ever admitting a bad match then distorts the entire operation.
Data collected because it was available
The Australian Privacy Principles direct you to collect only personal information reasonably necessary for your functions, and every additional field is something you have to secure, correct on request and delete on request. A unified view is a natural place for scope to creep, particularly with data inferred from behaviour. Decide what you actually need for the uses you have described to customers, and resist assembling a profile simply because the pipes now exist.
Deletion honoured in one place only
When a customer asks for their data to be deleted or corrected, the obligation follows their information wherever you hold it, including the marketing platform, the support desk, backups within reason, and any third party you passed it to. A unified view makes this achievable, because you can finally find every copy, but only if deletion is designed as a flow that reaches every connected system rather than a button in one of them.
Access spread wider than the role requires
Assembling a complete picture of a customer means that anyone who can open the unified record can see considerably more than they could before, including purchase history across channels and support history. Set access by role rather than by convenience, log who viewed what, use least privilege service accounts for the integrations themselves, and review the access list periodically. The concentration of data is the benefit and the risk in the same breath.
How Yes AI Approaches Customer Data Unification
We measure the duplication before proposing anything
A sample analysis across your actual systems showing how many records are duplicates, which fields are reliable enough to match on, and what the realistic match rate is. Occasionally the honest answer is that the problem is smaller than assumed and a targeted fix is enough.
Precision first, with a review queue
Matching rules tuned to avoid wrong merges rather than to maximise coverage, with graded confidence, a short review queue for the ambiguous cases, and every source record preserved so any decision can be reversed.
Built, hosted and monitored by us
Ingestion, standardisation, matching and publishing run on a managed cloud automation layer we operate, with logging of every linking decision so a merge can always be explained and, if necessary, undone.
Consent and deletion designed in
Consent held per channel with its evidence, suppression applied everywhere at once, and access, correction and deletion built as flows that reach every connected system rather than as a manual process someone has to remember.
From Five Versions of a Customer to One
Five steps. A first working unified view usually lands between weeks six and twelve.
Profile the data honestly
A sample across every system measuring duplication, field completeness and format consistency, so matching rules are designed against reality rather than against how the data is supposed to look.
Agree matching and survivorship
Which combinations constitute a confident match, which need review, and which system wins for each field. Written down, tested against real records, and approved before anything is merged.
Settle consent and access
Consent held per channel with evidence, suppression rules, who may see the unified record, and how access, correction and deletion requests will be executed across every connected system.
Build with sources preserved
Ingestion, standardisation and matching built on a managed layer with the source records left intact, linking decisions stored as data, and a review queue for anything below the confidence threshold.
Publish back and tune
The unified view exposed where it helps, at the counter, in support and in marketing, then matching thresholds tuned against real review outcomes rather than against assumptions.
Related Reading
SaaS Integration Explained
The six integration patterns and how to choose between them.
Loyalty and Gift Card Integration
Where customer identity meets a financial liability.
Franchise and Multi Entity Integration
Sharing customer data across separate legal entities.
POS to Ecommerce Integration
One stock pool and one customer across shop and web.
CRM Integrations
Connecting the CRM to the rest of the stack.
Two-Way Data Sync
Bidirectional syncing without the overwrite loops.
FAQ
One Customer, One Record, Consent Intact
Book a call. We profile your actual data, tell you how duplicated it really is, and give you a priced plan. The data profile is yours either way.
All discussions held in confidence. Australian-based consultants.