Most organizations know they have a customer data problem. What they often don't know is how bad it is until they try to answer a simple question: who are our customers, and what do they buy from us?
That question, simple on the surface, recently sent us deep into the data architecture of a large membership-based organization with multiple lines of business. What we found was a pattern that repeats across industries: each business unit had built a perfectly functional customer model, optimized for its own operations. And that local success was quietly undermining the enterprise.
The Problem Looks Operational. It Isn't.
When we spoke with teams across the organization, the complaints sounded operational: reports that broke when upstream data changed, manual exports to spreadsheets that became stale overnight, revenue numbers that never matched between systems. One team described spending significant time each week reformatting data just to make it usable. Another mentioned that a system change in one department would silently break reporting in another, often discovered weeks later.
These are real pain points, and they deserve attention. But treating them as isolated operational issues misses the root cause. The spreadsheet dependency and the broken reports are symptoms. The disease is that the organization has no shared definition of who a customer is.
Three Definitions, Zero Conflicts (Until They Matter)
Across this organization, there were three distinct customer definitions in active use. One business unit defined a customer as an individual: a person with a name, contact information, professional credentials, and committee affiliations. Most other business units defined a customer as a location: a specific facility or site where products and services are delivered. A third definition treated the customer as a legal entity: the organization that holds a membership relationship and carries financial and contractual obligations.
None of these definitions were wrong. Each was built to serve a real business need. The problem is that they were built independently, maintained in separate systems, and never reconciled. When leadership needed to answer questions that crossed those boundaries, such as how much revenue is generated by a specific corporate group across all products, or which individuals at a given company hold active subscriptions, the data simply could not answer.
The Customer Journey as a Diagnostic Tool
The breakthrough came not from auditing the data, but from mapping the customer journey. When you follow a customer from first contact through product purchase, service delivery, renewal, and cross-sell, the gaps in your data model become structural problems, not configuration issues.
In this case, that exercise revealed something the existing architecture could not support: the relationship between a corporate parent, its subsidiaries, and the individual people who work within them. A large company might have dozens of locations purchasing services, but no single view existed of that company's total relationship with the organization. Cross-selling was effectively impossible to execute at scale because the data to support it didn't exist in a connected form.
The journey map also surfaced a subtler problem: identity drift. When individuals change employers, their credentials, subscriptions, and access rights may remain active long after their organizational affiliation has changed. Without a systematic way to validate that a person still belongs to the organization they represent, data quality degrades continuously and invisibly.
The Solution Is Structural, Not Technical
The architecture we proposed introduced a new layer in the customer hierarchy: a parent account that groups all related legal entities and sites under a single corporate identity. This was not a new system. It was a new concept, one that required agreement across business units before a single line of code could be written.
That distinction matters. Too often, organizations look to a technology platform, a new CRM or a Master Data Management tool, to solve what is fundamentally a governance problem. Technology can enforce rules and resolve duplicates, but it cannot decide who owns the customer record, who has authority to change a name or address, or what constitutes the difference between a site and a legal entity. Those are organizational decisions. Until they are made and written down, no system will save you.
In this engagement, we defined data ownership at a specific level: one team owns the processes for managing individual identity, another owns the account structure and site hierarchy, and ownership of the parent entity layer was deliberately debated rather than defaulted. That debate was uncomfortable. It was also the most valuable part of the project.
What This Means for Data Leaders
If your organization is preparing for a CRM migration, an MDM implementation, or a data governance initiative, consider starting with the customer journey before touching the technology. Ask who your customer is at each stage. Ask which systems hold that answer. Ask what happens when someone needs to cross a business unit boundary to find it.
The answers will be uncomfortable, because they will reveal that your data is not just fragmented, it is organized around the wrong question. Most data models are built to answer: what did this customer buy from us? The customer journey forces you to answer a harder one: who is this customer, across everything we do, and what is the full scope of that relationship?
That is the question that unlocks cross-sell, holistic reporting, and durable data quality. And it cannot be answered by any system that was never asked to hold it.