---
title: Customer 360 Case
url: https://documentation.cluedin.net/solutions/use-cases/customer360
content_type: concept
section: Solutions & integrations > Use cases
---

# Customer 360 Case

> concept: Explains how something works.

# Customer 360 in CluedIn — Step-by-Step Implementation Guide

Customer 360 creates a single, trusted view of each customer across CRM, e-commerce, marketing, support, billing, and product systems. This guide walks you end-to-end: ingest → standardize → match/link → golden record → enrich → govern → publish.

---

## Outcomes

- A **golden customer record** per real-world customer (person or organization).
- Linked entities: **Customer/Person/Account ↔ Contacts/Addresses ↔ Orders/Tickets/Subscriptions/Interactions ↔ Consents/Preferences**.
- Quality, lineage, and rollback for stewardship and compliance.
- **Publish/Sync** to CRM, marketing, CS tooling, and analytics.

---

## Prerequisites

- Source access: CRM, e-commerce, marketing automation, support/ITSM, billing/subscriptions, product telemetry (optional), spreadsheets.
- Clarify the **customer model**:
  - B2C: primary entity = `Person` with optional `Household`.
  - B2B: `Account/Organization` with linked `Contact(Person)` and roles.
- **RACI**: Stewards/owners need **Accountable** access.
- Use a **dedicated server/VM** for heavy ingestion/matching/toolkit operations (avoid laptops).

---

## Reference Data Model

**Core entities**
- `Person` (B2C or contact in B2B)
- `Account` / `Organization` (B2B)
- `Customer` (canonical wrapper pointing to Person or Account)
- `Address`, `ContactPoint` (Email/Phone), `Consent`, `Preference`
- `Order`, `Subscription`, `Ticket`/`Case`, `Interaction` (events)
- Optional: `Household` (for Householding), `Segment`, `LifecycleStage`

**Key attributes (examples)**
- Person: FirstName, LastName, DOB, Email(s), Phone(s), PrimaryAddress, MarketingOptIn, Country.
- Account: LegalName, TaxID/DUNS, Domain, Industry, Size, BillingAddress.
- Customer (derived): Status, Segment, LTV, LastActivity, CompletenessScore.

**Relationships**
- Account ↔ Contacts(Person)
- Customer ↔ Orders/Subscriptions/Tickets/Interactions
- Customer ↔ Consents/Preferences
- Person ↔ Household (optional)

---

## Step 1 — Connect & Ingest Sources

**Portal**: *Data Sources → Add Source*  
1. CRM masters (leads/contacts/accounts).  
2. E-commerce platform (customers, orders).  
3. Marketing automation (lists, events, consents).  
4. Support/ITSM (tickets/cases).  
5. Billing/subscriptions (plans, invoices).  
6. Spreadsheets/CSV (legacy imports).

> Capture provenance on ingest: `SourceSystem`, `SourceRecordID`, `IngestedAt`.

---

## Step 2 — Define Entities & Mappings

**Portal**: *Entity Explorer → + Create Entity Type*  
- Create `Person`, `Account`, `Customer`, `Address`, `ContactPoint`, `Consent`, `Order`, `Subscription`, `Ticket`, `Interaction`.  
- Map source fields → canonical attributes (e.g., `crm.email` → `ContactPoint.Email`).  
- Persist **lineage** (original values + mapping metadata).

**B2B note**: Model `Customer` as the Account golden, with linked Contacts for communications.

---

## Step 3 — Standardization & Normalization (Data Part Rules)

**Portal**: *Governance → Rules (Data Part Rules)*  
Create rules to clean inputs **before** matching:

- **Names/Text**: trim, case, punctuation; strip HTML/emoji where policy requires.  
- **Emails**: lower-case; basic regex; (optional) provider-specific canonicalization.  
- **Phones**: convert to **E.164**; tag `InvalidPhone` if parse fails.  
- **Addresses**: parse components; normalize ISO-2 `Country`; optional geocoding.  
- **IDs**: normalize CustomerID, AccountID; validate TaxID/DUNS for B2B.  
- **Domains**: extract from email for B2B domain inference.  

**Recommended tags**: `Standardized`, `InvalidEmail`, `InvalidPhone`, `InvalidAddress`, `LegacySource`.

---

## Step 4 — Identity Resolution (Matching & Linking)

**Portal**: *Entity Matching*  

### Person (B2C / Contacts)
- **Blocking keys**: (Email), (Phone), (LastName + DOB), (CustomerId).  
- **High-confidence**: exact Email OR exact Phone OR exact CustomerId.  
- **Candidate**: fuzzy Name ≥ 0.92 AND Address similarity ≥ 0.9 (same Country).  
- Review in **Data Stewardship**; approve merges; **Unmerge** errors.

### Account (B2B)
- **Blocking**: (Domain), (TaxID), (Country + CleanNameSoundex).  
- **High-confidence**: exact `TaxID` OR exact `Domain`.  
- **Candidate**: fuzzy `LegalName` ≥ 0.92 AND same Country; supplement with address/phone.

### Person↔Account Linking (B2B)
- Link Contacts to Accounts by explicit AccountId; else infer by email domain + stewardship review.

**Pitfalls to avoid**
- Over-merging by name alone (married names, common surnames). Require multi-evidence.  
- Cross-country merges; guard with `Country`.

---

## Step 5 — Stewardship Workflow

**Portal**: *Data Stewardship → Match Review*  
- Triage by confidence and impact (e.g., number of linked orders).  
- Approve/Reject; tag `AmbiguousMatch` for edge cases.  
- Use **History** for traceability; **Unmerge** if needed (rollback captured).

---

## Step 6 — Golden Record Survivorship

**Portal**: *Governance → Rules (Golden Record Rules)*  
Define attribute precedence and tie-breakers:

| Attribute        | Precedence (high → low)                     | Tie-breaker                          |
|------------------|----------------------------------------------|--------------------------------------|
| Primary Email    | CRM > E-com > Support > Marketing            | Most recently verified/active        |
| Primary Phone    | CRM > Support > E-com                        | Valid E.164 + last confirmed         |
| Name             | CRM > E-com                                  | Longest non-marketing version        |
| Address          | Verified Delivery > Billing > CRM            | Most recent verified                  |
| Account Domain   | CRM > Verified from Email Domain             | Steward override                      |
| Segment/Stage    | CRM > Derived (rules)                        | Most recent                           |
| Consents         | **Most restrictive wins** (by channel)       | N/A                                   |

**Actions**
- Compute `CompletenessScore` (weight required attributes).
- Tag `MarketingReachable` when Email valid + opt-in and Phone valid (if SMS).
- Tag `CustomerLifecycleStage` (Lead/Prospect/Active/ChurnRisk) via rules.

---

## Step 7 — Consent & Preference Management

**Portal**: *Entity Explorer / Rules*  
- Model `Consent` with Purpose, Channel, Status, Timestamp, Source.  
- Enforce via rules:
  - If `Consent(Marketing.Email) != granted` → tag `DoNotContactEmail`.  
  - If `DoNotSell`/CPRA → tag and propagate to exports.  
- Aggregate consents from multiple systems; preserve source and evidence.

---

## Step 8 — Enrichment (Optional)

**Portal**: *Data Sources / Rules*  
- Append firmographics (B2B: industry, size), demographics (B2C policy-dependent), geocoding, or CLV/propensity scores.  
- Track `LastEnrichedAt`, provider, and confidence; re-check on schedule.

---

## Step 9 — Data Quality Scoring & Dashboards

**Portal**: *Data Quality → Profiling / Scorecards / Dashboards*  
- KPIs: valid email/phone %, address standardization %, duplicate rate, consent coverage, completeness by segment/source.  
- Create **alerts** on regressions (e.g., Valid Email < 98%).

---

## Step 10 — Governance, Security & Lifecycle

**Portal**: *Governance → Permissions / Policies / Retention*  
- Restrict PII fields; apply least-privilege access.  
- **Retention** (e.g., inactive leads > 24 months → archive/delete).  
- Audit: merges/overrides/exports are captured in **History**; **Undo/Restore** supported for data changes and cleaning projects.

---

## Step 11 — Publish / Integrate

**Portal**: *Exports*  
- **CRM**: push Golden Customer + key attributes; keep GUID mapping (old→new).  
- **Marketing**: export reachable audiences with consent flags and suppression lists.  
- **Support/CS**: sync authoritative contact details and lifecycle stage.  
- **Analytics/DW**: publish wide `DimCustomer` + relationship tables (Orders, Tickets, Interactions).  
- **APIs/Eventing**: emit customer-changed events.

> Start **read-only** to validate mappings, then make CluedIn authoritative where appropriate.

---

## Step 12 — Scheduling & Operations

- Schedule ingestion, matching, golden updates, enrichment, and exports (run heavy jobs off-peak on a **dedicated VM/server** to avoid timeouts).  
- Monitor job runtimes and queue depth; investigate spikes (often source drift).

---

## Step 13 — Validate & UAT

- Sample 100–200 customers across sources/segments.  
- Verify no cross-person conflation; confirm B2B Person↔Account links.  
- Validate survivorship outcomes and consent enforcement end-to-end.  
- Business sign-off from CRM/Marketing/Support/Compliance.

---

## Go-Live Checklist

- [ ] All in-scope sources ingested with provenance.  
- [ ] Matching thresholds tuned; **Unmerge** tested; false-positive rate low.  
- [ ] Golden survivorship rules approved; `CompletenessScore` thresholds set.  
- [ ] Consent model enforced; suppression feeds validated.  
- [ ] Exports mapped and tested in CRM/MA/CS and DW.  
- [ ] Permissions & retention configured; audit/rollback verified.  
- [ ] Product Toolkit package built and promoted (run on **dedicated box** with **Accountable** access).

---

## Example Rules (Snippets)

**Normalize Email (Data Part Rule)**
- Condition: `Email present`  
- Actions: lower-case; regex validation; tag `InvalidEmail` on fail.

**Phone to E.164**
- Condition: `Phone present`  
- Actions: parse/format; tag `InvalidPhone` on failure.

**Customer Identity (Person Auto-merge)**
- If `Email exact` OR `Phone exact` OR `CustomerId exact` → Confidence = 1.0 (auto).  
- Else if `FuzzyName ≥ 0.92` AND `AddressSim ≥ 0.9` AND `Country equal` → Confidence = 0.95 (steward).

**Golden Survivorship (Primary Email)**
- Precedence: CRM > E-com > Support > Marketing; tie-break = most recently verified + reachable consent.

**MarketingReachable Flag**
- If `ValidEmail` AND `Consent(Email)=granted` → `MarketingReachable=true`; else false.

**Lifecycle Stage (Derived)**
- If `Orders>0 AND LastOrder < 365d` → `Active`;  
- If `Orders>0 AND LastOrder ≥ 365d` → `ChurnRisk`;  
- If `Orders=0 AND LastInteraction < 90d` → `Prospect`.

---

## Common Pitfalls & How to Avoid Them

- **Over-fuzzy merges** → require high-confidence evidence (email/phone/ID); steward candidates.  
- **Channel overrides pollute golden** → keep Golden canonical; apply channel transforms in exports.  
- **Ignoring consent in exports** → wire suppression flags into all downstream feeds.  
- **Address issues cause duplicates** → standardize and geocode before matching.  
- **Running heavy jobs on laptops** → use dedicated compute to prevent timeouts.

---

## Success Metrics

- Duplicate rate (Person/Account) **< 1–2%** with high precision auto-merge.  
- Valid Email ≥ **98%**, Valid Phone ≥ **95%**; Address standardized ≥ **97%**.  
- Consent coverage for marketable customers ≥ **99%** accurate.  
- Time-to-resolve stewardship queue ↓; `MarketingReachable` growth ↑.  
- Downstream CRM/MA/CS exception rate ↓ after go-live.

---

## Summary

Customer 360 in CluedIn unifies identities, standardizes attributes, enforces consent, and publishes a governed, audit-ready customer truth to every system. Start with clean identifiers and solid survivorship, validate merges with real samples, and keep Golden canonical while handling channel-specific needs in your exports.

Up: [Use cases](https://documentation.cluedin.net/solutions/use-cases.md)