A single customer view is one record per real customer that holds every relationship that customer has with every brand in the platform: which brands they buy from, what they have spent, how they were acquired, and how the business is permitted to contact them. In a multi-brand platform it is not a reporting convenience. It is the underlying asset that makes cross-sell, retention measurement, and honest acquisition cost possible, because none of those can be calculated while one household exists as four unlinked records in four systems that have never been introduced.
Most platforms discover this at the third or fourth add-on, when a sponsor asks how many customers buy from more than one brand and the honest answer is that nobody knows.
Three different projects get sold under this name and they are not interchangeable. A single customer view is an identity layer. Its only job is to decide that these records, in these systems, are the same customer, and to hold what the platform knows about that customer in one place.
It is not a CRM consolidation. That project decides which operational system the sales and service teams work in, and it is covered separately in our guide to CRM consolidation after an acquisition. It is not a reporting spine either. That project decides which system is canonical for each metric and how the commercial numbers tie to finance, which is the subject of building a single source of revenue truth. The identity layer sits underneath both. You can consolidate CRMs and still not know that the Hendersons at 14 Mill Lane are the same household in three of your brands, because a migration merges systems and identity resolution merges people.
The duplication is manufactured by the deal structure, not by carelessness. Each acquired brand arrives with its own system, its own required fields, and its own habits about what gets typed into them. One brand keys on the billing contact, another on the service address, a third on whoever answered the phone. Phone numbers are formatted five ways. In consumer services the customer is often a property rather than a person, and the person changes while the property stays.
Nothing in the normal run of business forces these records together. Each brand's system works fine for that brand's job, and the cost only appears at platform level, by which point the records have been diverging for years.
This is the decision the whole project turns on, and it is asked most often as platform versus point tools. There are three workable answers.
Inside the platform CRM. One system holds the master account record and the brands operate inside it. Right when the brands already run, or will run, on a single operational system and the customer needs to be visible to a person at the point of service. Cheapest to run, hardest to reach, because it presumes the CRM consolidation is done.
In a warehouse alongside the operational systems. Each brand keeps its system, and the platform lands the customer tables in one place and resolves identity there. Right when the brands stay operationally separate, when more acquisitions are coming, and when the questions being asked are analytical: overlap, penetration, retention, acquisition cost. This is where most mid-market platforms should start.
In a customer data platform. A purpose-built tool that resolves identity and pushes audiences back out to marketing channels. Right when the platform is running high-volume consumer marketing across brands and needs the resolved record to activate campaigns daily, not to answer questions monthly.
The rule that saves money: buy the tool last. The matching logic, the customer definition, and the survivorship rules are yours to decide whichever tool you use. A platform that has decided them can build the first version in a warehouse it already pays for; a platform that has not will pay a vendor to decide them badly.
Consumer and commercial services businesses have a specific advantage here. The strongest match key is not a customer ID or an email address. It is the service premises. Addresses are entered because a technician has to drive to them, which makes them the most reliably populated field in the entire estate.
Decide first what the record represents: the individual, the household, or the premises. In residential services the premises is usually the correct grain, with people attached to it, because the revenue follows the property. In commercial services the account is the grain, with sites beneath it. Getting this wrong is expensive, because every downstream metric inherits the choice.
Then run a deterministic waterfall before anyone reaches for probabilistic matching. Normalize first: addresses to a postal standard, phone numbers to digits, emails to lower case. Then match in order of confidence, typically exact email, then phone plus surname, then normalized address plus surname, then normalized address alone for premises-grain records. Each tier gets recorded on the link, so you can always see how confident a given match is and unwind a tier that proves noisy. Probabilistic and fuzzy matching are for the residue, and everything they produce should be reviewable rather than silently merged.
Set a target and measure against it. The match rate that matters is not a hundred percent. It is the point at which finding more overlap stops changing a decision, and most platforms reach it after the deterministic tiers.
Two systems will hold two different phone numbers for the same customer, and the merged record has to pick one. Decide this at the field level and write it down before the first merge runs.
Source precedence works where one system is structurally better informed: billing takes the billing address, the field system takes the service address, the brand that last completed a job takes the contact phone. Recency works for volatile fields such as email. Never let the merge overwrite the source records themselves. The golden record is a view assembled from intact sources, so a bad rule is corrected by rebuilding rather than by a restore.
An identity layer that only proves two records are the same person has not earned its cost. The resolved record should carry, at minimum:
Permission deserves particular care. Consent is given to a brand rather than to a holding company, and resolving identity across brands does not by itself create a right to contact a customer on behalf of a brand they have never bought from. Hold permission per brand, respect the strictest suppression across the platform, and have counsel read the consent language each brand collected before any cross-brand contact goes out.
The version of this project that fails is the one that tries to resolve every brand at once and produces nothing anyone can use for two quarters. The version that works picks the two brands with the largest suspected overlap, resolves those, and puts a real number in front of the board within a few weeks.
Order the work as: choose the grain and write the customer definition, normalize and land the customer tables from the first two brands, run the deterministic waterfall and review a sample of the matches by hand, agree survivorship rules on the fields that disagree, publish the overlap number, then add brands one at a time. Each new brand is faster than the last, and once the pattern exists new acquisitions join the identity layer during integration rather than years afterward.
The resolved record is a prerequisite rather than a benefit, so judge it by what becomes possible. Cross-sell stops being an assumption in the deal model and becomes a measurable corridor, which is the subject of our guide to building the cross-sell engine in a multi-brand platform. Retention and acquisition cost can be calculated at platform level instead of brand level, which usually reveals that the platform has been paying twice to acquire customers it already had.
It also tends to surface demand nobody was counting. In one five-brand consumer services platform we diagnosed, 38 percent of revenue was arriving through word of mouth that no system recorded. The commercial program built on that diagnostic grew revenue 36 percent in 24 months on essentially flat marketing spend. In another engagement, shifting demand from bought to owned channels cut customer acquisition cost by 60 percent and tripled the share of demand the business owned outright. Neither number was available before somebody could tell which customers were which.
The pressure to do this work is not going away. In S&P Global Market Intelligence's 2026 Private Equity Survey, 71 percent of general partners and 53 percent of limited partners said they prioritize operational value creation over financial engineering. A platform that cannot identify its own customers cannot operate them. Where the identity work sits in the wider commercial picture, and how we sequence it, usually comes out of an eight-week commercial audit that maps overlap and referral flow across the brands first.
A single customer view is one record per real customer that links every relationship that customer has with every brand in the platform: which brands they buy from, what they have spent, how they were acquired, and how the business is permitted to contact them. It is an identity layer rather than a system migration or a dashboard. Its job is to decide that a set of records in different brand systems refer to the same customer, and to hold the resolved picture in one place so that overlap, retention, and acquisition cost can be measured across the platform.
In the platform CRM when the brands already run on one operational system and a person needs to see the customer at the point of service. In a data warehouse when the brands stay operationally separate, more acquisitions are coming, and the questions are analytical rather than real time, which is where most mid-market platforms should start. In a customer data platform when high-volume consumer marketing across brands needs the resolved record to activate campaigns daily. Decide the customer definition, matching logic, and survivorship rules first; the tool decision is easier and cheaper once those exist.
Normalize first, then match deterministically in tiers of decreasing confidence: exact email, phone plus surname, normalized address plus surname, then normalized address alone where the record grain is the premises. Record which tier produced each link so a noisy tier can be unwound. In services businesses the service address is usually the strongest key, because a technician has to drive to it and it is therefore the best populated field in the estate. Reserve probabilistic matching for the residue, and keep its output reviewable rather than merging it silently.
The useful threshold is the point at which finding more overlap stops changing a decision, not a fixed percentage. Most platforms get the answer they needed from the deterministic tiers alone and then spend disproportionate effort on a long tail that moves no number. Set the target against the decision in front of you, such as sizing a cross-sell corridor or calculating platform-level acquisition cost, and stop when the answer is stable.
Have a revenue problem the board is asking about? Start a conversation.