Solution / Customer 360
A connected customer view. With context intact.
Customer 360 is a governed, unified view of a customer built by resolving identity across CRM, orders and support systems into one record. Quorlytic builds the identity-resolution rules, carries consent and access context into every derived view, and ties the result to one defined business action rather than a general-purpose data lake.
By QuorlyticUpdated
Bring customer interactions together without treating every source as equally reliable. Connect identity, transactions and service history into a governed view that supports a defined business action.
Problem, approach and outcome.
| Problem | An email address, device or account is not always a person. Document deterministic matching rules, confidence thresholds and manual-review cases. Preserve source identifiers and make incorrect merges reversible. |
|---|---|
| Approach | Carry consent, access and retention context into downstream models. Use purpose-specific views rather than exposing the entire customer record to every consumer. Deletion and correction need to propagate through derived stores. |
| Typical outcome | Identity and source-precedence rules |
The approach
- 01
Define identity before joining tables
An email address, device or account is not always a person. Document deterministic matching rules, confidence thresholds and manual-review cases. Preserve source identifiers and make incorrect merges reversible.
- 02
Keep permissions attached to the data
Carry consent, access and retention context into downstream models. Use purpose-specific views rather than exposing the entire customer record to every consumer. Deletion and correction need to propagate through derived stores.
- 03
Activate one useful workflow
Start with a service-history view, an agreed customer segment or a repeat-purchase analysis. Define the destination, refresh cadence and action owner. A unified table without a consumer is not yet a solution.
- 04
Test the edge cases
Measure duplicate rate, match precision on an approved sample and unresolved identities. Inspect shared emails, household accounts, returns and late-arriving transactions. These checks are acceptance criteria, not promised outcomes.
- 05
Integration decides what a profile can be
A unified profile is only as good as the sources that feed it. Inventory each system’s identifiers, update cadence and ownership before joining anything, then set the rules for precedence and survivorship when two systems disagree. Incremental updates keep the profile current without rebuilding it nightly, provided deletes and corrections propagate too.
- Source, key and cadence inventory before any join
- Precedence and survivorship rules written down
- Deletes and corrections propagated into derived views
- 06
Segmentation needs definitions the business acts on
Segments are only useful if someone changes what they do because of them. Define each segment against a decision — a service action, a campaign, a retention conversation — with its grain, refresh cadence and consent context. A segment nobody can act on, or that cannot be reproduced next month, is an analysis rather than a capability.
- 07
Freshness belongs to the use case
Service teams may need a customer view within the hour; marketing programmes often work on a daily refresh; analytical segments can rebuild weekly. Setting one freshness target for the whole profile makes the cost and complexity decisions for you. Agree a target per consumer, then design the update path that meets the tightest one that genuinely matters.
- 08
Measure the profile, not the project
Match precision on approved samples, duplicate rate, unresolved-identity count, coverage of the identifiers that matter and how quickly a correction propagates are the measures that show whether the profile is usable. Track them after launch, because identity quality drifts as sources and business rules change.
What the work produces
- Identity and source-precedence rules
- Versioned customer data model
- Purpose-specific views and permissions
- Match-quality and freshness checks
Delivery stages
- 01CRM, orders & support
- 02Resolve identity
- 03Apply access & purpose
- 04Serve customer workflows
Keep a customer address coherent when sources disagree.
Choosing the best value for each field can create a profile that never existed in any source. A street from one system and an apartment number from another may form an unusable address even when both values are individually valid. In this hypothetical Customer 360 case, a coherent address group and its provenance are the acceptance unit, alongside the identity that the group belongs to.
Scope and assumptions: This example concerns an authorised service-address view. It does not infer consent from a preferred address, select a matching threshold or claim that a platform automatically reverses downstream actions. Microsoft's Customer Insights documentation is a concrete reference for grouped-field survivorship; another implementation needs equivalent rules suited to its own data model.
| Dimension | Conflicting source condition | Expected handling and acceptance evidence |
|---|---|---|
| Partial preferred source | The preferred CRM supplies a new street and postcode but no apartment. An older order record has an apartment value. Field-by-field null filling could attach the old apartment to the new street. | Treat the agreed address fields as a group when selecting the winning source. Retain which record supplied the group and whether it is incomplete. A missing apartment can be more truthful than a fully populated address assembled from incompatible records. |
| Meaning of recency | Distinguish when the address became effective from when a connector loaded it. A replayed old source record can have a recent ingestion timestamp without representing a recent customer correction. | Record the timestamp used by the selection rule and its source. If comparable effective dates do not exist, use an explicit fallback rather than allowing arrival order to become an accidental business policy. |
| Purpose-specific precedence | Billing, shipping and service addresses can legitimately differ. A verified billing record is not automatically the right destination for a service visit, nor does its presence authorise marketing contact. | Keep address purpose and identity key with the consumer contract. Verify that a service consumer receives the selected service-address group and the applicable access context, rather than every address available in the profile. |
| Correction propagation | Change the winning address or repair an incorrect identity link in a controlled fixture. Enumerate the profile, search view, exported segment and downstream service record that may still contain the previous value. | Track the correction version and acknowledgement per consumer. Recomputing a profile does not prove that a previously exported file or an action already queued by another system has been corrected. |
| Conflict remains unresolved | Include two credible, incompatible address records with no reliable ordering signal. Keep the ambiguity visible to the authorised workflow instead of producing a single confident value from an arbitrary tie-break. | Retain the competing source references and the resolution reason. Limit access to that evidence; a broadly shared acceptance document should use synthetic addresses and identifiers rather than personal records. |
At narrow widths, scroll the worksheet to read every column. With the table focused, use the arrow keys to scroll.
Worked decision: the unified profile contains the CRM's new street and the order system's old apartment. Reject that mixed group, apply the agreed grouped selection rule and verify the correction at each consuming boundary. An incomplete group may remain the appropriate output until the permitted source resolves it. The example makes a data-quality defect observable without claiming a measured match rate or an automatic repair capability.
- Test provenance as well as field values. Two runs that happen to produce the same visible address can still differ in whether a later source correction will propagate correctly.
- Keep identity resolution, attribute survivorship and permission policy separate. A strong identity match does not establish which attribute wins or what a consumer is allowed to do with it.
For consumers that use the profile in channel reporting, continue to marketing analytics and attribution with the identity and coverage limits intact.
Official references for this example:
Questions
Questions worth asking.
Do we need a customer data platform?
Not necessarily. Assess activation requirements, identity complexity and the existing warehouse first. A dedicated platform is justified when it provides required capabilities more effectively than extending what you already operate.
How do we know the unified profile is working?
Measure match precision on an approved sample, duplicate rate, unresolved identities and how quickly a correction reaches derived views — then check that the destination workflow actually uses the profile. Coverage alone says nothing: a profile that merges the wrong records looks complete and damages service.
Your next data decision
Start with a clear problem.
Build what comes next.
Bring the business question.
We'll help shape the engineering brief.