Customer master data management

Customer information problems usually show up as duplicates, weak matching, fragmented service history, inconsistent reporting, or poor handoffs between channels and operational teams. MDM is useful when it helps the enterprise define one coherent customer concept and govern the key attributes and relationships that multiple parts of the enterprise need to rely on.

That means MDM is not first about tooling. It is first about identity, ownership, matching rules, stewardship, and which decisions justify the effort. G21B makes this point clearly: the guide structures customer MDM as a series of architecture decisions, not as a product-selection framework.

For a utility, customer information carries specific complications that do not appear in retail or financial services. A utility customer can be a connection applicant, an existing account holder, a site contact, a metering point, or a historical service relationship. These categories overlap but are not identical. The entity definition matters because it determines what the MDM solution is supposed to unify and what it should leave separate.

G21B identifies six architecture questions that should be settled before the enterprise evaluates any MDM product. Each question addresses a different layer of the customer-data problem.

1. Entity definition. What counts as the customer entity in this enterprise and where are its boundary cases? Some organisations conflate applicants, account holders, site contacts, and historical relationships. The entity definition matters because it determines what the MDM solution is supposed to unify. For a London distribution network, the customer entity must distinguish between connection applicants, metering-point holders, and site contacts.
2. Shared-attribute identification. Which customer attributes are genuinely shared and which are local to one process or system? Not every attribute needs master-data governance. The architecture should distinguish shared attributes (such as identity and primary contact) from local ones (such as a call-centre agent's internal notes).
3. Authority assignment. Who is authoritative for the shared attributes and how are changes validated? This is the authority question from Module 28 applied specifically to customer data. It determines who can create, correct, validate, and publish the shared representation.
4. Matching and conflict rules. How does the enterprise determine when two records refer to the same customer, and who decides when the match is wrong? Matching rules are an architecture decision because they determine the quality of the unified view. If the rules are too loose, duplicates survive. If the rules are too tight, legitimate distinct customers are merged.
5. Stewardship and governance. Who stewards the definitions, quality rules, and conflict-resolution processes? The steward is not the same as the system owner. The steward ensures that the rules work across all participating systems.
6. Decision use case. Which decisions, publications, or service outcomes improve if customer information becomes more coherent? This is the value case. Without it, the MDM effort becomes a data-quality exercise without a business anchor.

A team that skips these decisions and moves straight to platform selection will discover them later, usually as implementation blockers. The energy retailer in the opening story is a case in point: the platform worked, but the architecture underneath it was never completed.

A golden record can be useful shorthand for a trusted representation of customer information, but only if the architecture has already defined what that representation contains, who depends on it, and how conflicts are resolved.

Without that groundwork, golden-record language tends to promise a clean answer while hiding unresolved identity and authority questions. The danger is the same as with "single source of truth" (Module 28): the phrase becomes a substitute for the work rather than a description of it.

An architecture team that defines the golden record as "the enterprise-trusted view of customer identity, primary contact, and account status, stewarded by the customer-data office and refreshed nightly from three contributing systems with defined conflict rules" has made a bounded, governable claim. An architecture team that defines the golden record as "the single truth about the customer" has not yet done the work.

The golden-record concept is also sensitive to the utility context. In retail, a golden record might merge three duplicate records into one. In a utility, the challenge is different: the same person might be a connection applicant in one system and an existing account holder in another, and those are legitimately different relationships that should not always be merged.

Customer-data architecture in a utility differs from other sectors in several important ways. Understanding these differences prevents the team from applying retail-style MDM patterns without adaptation.

Connection-based relationships. A utility customer is often defined by a physical connection point rather than by a purchasing relationship. A household may have one electricity connection but multiple account holders over time. The relationship between person, property, and connection creates complexity that retail MDM rarely encounters.

Regulatory obligations. Customer data in a utility supports regulatory reporting, service-level monitoring, and publication obligations. The architecture must consider which customer attributes feed regulatory submissions and what quality thresholds apply.

Long lifecycle relationships. Utility customer relationships can span decades. Historical service records, previous connection applications, and legacy account structures all need to be accommodated in the architecture. A golden record that only handles the current state misses the historical dimension that planning and regulatory teams need.

Multi-role customers. The same entity might be a connection applicant, a service consumer, a metering-point holder, and a complaints correspondent. Each role may have different authority owners and different lifecycle stages. The architecture must decide which of these roles belong in the master-data scope and which are better managed locally.

Three outcomes should improve when customer-data architecture is working.

Service consistency. Different channels and teams should be able to identify the same customer and understand the same core relationship facts. That does not require identical data everywhere. It requires a shared reference that is trustworthy enough to anchor service interactions.

Authority clarity. The enterprise should know who can create, correct, validate, and publish the shared customer representation. That governance structure should be documented using the authority ownership model from Module 28, not assumed.

Decision confidence. Planning, reporting, service, and governance teams should know what customer information they can rely on and for which purpose. If the confidence is not there, the architecture has not yet delivered its value.

The practical test of customer-data architecture is whether the people who depend on customer information trust it enough to make decisions without privately maintaining their own shadow copies. Shadow copies are a symptom of low trust. If the architecture is working, the need for shadow copies should decrease.

The London case uses customer-data architecture to think about connection applicants, account relationships, service interactions, and published reporting. That is enough complexity to show why one clean customer view is difficult but still worth pursuing carefully.

The point is not to invent a perfect universal customer record. The point is to decide which customer facts must stay coherent across planning, service, operations, and reporting, and who is responsible for that coherence.

• London customer-data architecture is justified by service and governance outcomes, not by platform fashion.
• The stronger the decision use case, the more disciplined the MDM choices become.
• Connection applicants, existing account holders, and historical service records may each require different authority and lifecycle governance.
• The entity definition must handle the connection-based nature of utility customer relationships, not just the person-based model common in retail.
• All six G21B decisions should be answered in the London Phase C pack before any platform evaluation begins.