Your sales team knows one version of a customer. Support knows another. Marketing has a third, billing a fourth, and the website a fifth that's just an anonymous cookie. None of them are wrong, they're partial. A single customer view is what you get when you reconcile those fragments into one trusted record. The hard part is almost never buying the tool. It's deciding whose version wins.

The quick version

  • A single customer view (SCV) is one trusted record per customer, stitched together from every system that holds a fragment of them, not a dashboard, a discipline.
  • CRM and CDP do different jobs. CRM manages known relationships and deals; a customer data platform unifies behavioural and identity data across channels. Buying one doesn't get you the other.
  • The blocker is data quality and identity, not storage. Duplicates, conflicting fields and "is this the same person?" decide whether the view is trustworthy.
  • More data isn't always better. Privacy law and plain risk both say: collect only what serves a purpose, and the SCV is healthier for it.

The idea in depth

The phrase "single customer view" hides how much disagreement it has to resolve. Picture the same person as "J. Smith" in the billing system, "Jane Smith" in CRM with a work email, "jsmith88" as a loyalty-app login, and an unnamed device ID in your web analytics. Are those four records one customer or four? Get the answer wrong in either direction and the view is worse than useless, you either merge two different people or split one across four profiles and treat a loyal customer like a stranger every time. Everything else in this topic is downstream of that one judgement.

CRM is a strategy, not a database, and that's where it goes wrong

The most useful caution about this whole area predates the modern data stack. Darrell Rigby, Frederick Reichheld and Phil Schefter set it out in "Avoid the Four Perils of CRM" (Harvard Business Review, February 2002). Their headline finding was uncomfortable then and still lands: roughly 55% of CRM projects at the time failed to deliver the expected returns, and a good number actively damaged long-standing customer relationships. Their diagnosis was that companies treated CRM as a technology purchase when it is a customer strategy, and bolting expensive software onto a business that hasn't decided which customers it wants and how it wants to serve them just automates the confusion.

The four perils they named still map onto SCV projects today: implementing CRM before you have a customer strategy; rolling out the technology before the organisation is built to use it; assuming more CRM is better (it isn't, it can be invasive); and stalking customers rather than courting them. Each one is a way of mistaking the tool for the goal.

"When you automate a customer-hostile process, you get an efficient customer-hostile process."

(That line is our paraphrase of the article's argument, not a direct quotation, it's the through-line of all four perils.)

What to do about it: before any tooling decision, write one page answering "which customers do we want, and what does a great relationship with them look like?" If you can't, the SCV will faithfully unify data in service of no particular goal. The technology should follow the strategy, never lead it.

An honest limitation: that 55% figure is now over two decades old and reflects the on-premise CRM era. Modern cloud platforms are far easier to deploy, so the technical failure rate is lower. But the underlying point, that the strategy gap, not the software, sinks these projects, has aged well, which is exactly why we anchor to it rather than to a fresher but thinner statistic.

CRM and CDP are different animals

Teams routinely conflate two tools that solve different problems, then wonder why the single view never materialises. A CRM (customer relationship management) system is built around known relationships: named contacts, accounts, deals, support tickets, the things a salesperson or agent acts on directly. A CDP (customer data platform) exists to unify data across sources, web, app, transactions, email, offline, and resolve it into persistent profiles, including the behavioural and anonymous-then-identified signals a CRM was never designed to hold. As Salesforce frames it in its own Customer 360 material, the unified view draws from CRM, marketing, service, point-of-sale and web analytics together, no single operational system is the whole picture.

flowchart TD
    A(["CRM
deals, contacts, tickets"]) --> R{"Identity
resolution"}
    B(["Web & app
behaviour"]) --> R
    C(["Transactions
& orders"]) --> R
    D(["Email & marketing
engagement"]) --> R
    E(["Service &
support history"]) --> R
    R --> S(["Single customer view
one trusted record per person"])
    S --> U(["Used by sales,
service, marketing"])
The SCV is the output of identity resolution across systems, not any one source system on its own. Leaders Loop

The practical sign you've confused the two: you bought a CDP expecting it to manage your sales pipeline, or you're trying to force anonymous web behaviour into CRM contact records and drowning in junk. They feed each other, the CDP resolves identity and hands clean, unified profiles to the CRM that acts on them, but they are not substitutes.

A practical first step: draw your actual data sources on one diagram and label, for each, whether it holds known-relationship data (→ CRM territory) or cross-channel behavioural data (→ CDP territory). The gaps and overlaps in that picture tell you what you actually need to buy, and what you already own. This connects to the wider question of how you segment once the data is unified.

The limitation worth naming: the CRM/CDP boundary is blurring fast as vendors absorb each other's features, so the labels matter less than the jobs. Don't let a category war distract from the only question that counts, does this give us one trustworthy record per customer?

The single view lives or dies on data quality

Here is the part nobody puts on the project poster. Unifying data sounds like plumbing; in practice it's adjudication. Two records with slightly different spellings, a changed surname after marriage, a shared family email, a typo in a date of birth, each is a small decision about whether to merge, split or flag. Get the rules wrong and you produce a confidently wrong single view, which is more dangerous than four honest fragments, because people trust it. The single-source-of-truth idea from data architecture, aggregate scattered data into one authoritative place so everyone reads the same number, only delivers value if the matching underneath is right; an SCV built on bad identity resolution is a single source of falsehood.

So before you scale, run a deliberate data-quality pass on a sample. Count your duplicates, your conflicting fields, your records that can't be confidently matched. Decide your survivorship rules explicitly, when two records disagree, which source wins, and why? Those rules are the real product. The software just executes them. This is where a voice-of-customer programme and the SCV reinforce each other: clean identity makes every later signal attributable to a real person.

The limitation: perfect resolution is unattainable, and chasing it is its own failure mode. Some records will always be ambiguous. Mature programmes accept a confidence threshold and a small reconciled error rate rather than freezing the project in pursuit of certainty that the data can't support.

More data is a liability, not a trophy

The instinct behind a single customer view is to gather everything. Both the law and basic risk management push the other way. Under the EU's General Data Protection Regulation, Article 5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed", the data minimisation principle, and Article 5(1)(b) requires it be collected for "specified, explicit and legitimate purposes." A single customer view that hoovers up every available field, indefinitely, "just in case," isn't a richer asset. It's a larger breach surface and a compliance problem waiting to be audited. (This is a general principle, not legal advice, your obligations depend on your jurisdiction and a qualified adviser.)

flowchart LR
    A(["A data field
we could collect"]) --> B{"Does it serve a
specific, stated purpose?"}
    B -->|"No"| C(["Don't collect it
liability, not asset"])
    B -->|"Yes"| D{"Still needed,
or past its purpose?"}
    D -->|"Past it"| E(["Retire / delete
storage limitation"])
    D -->|"Still needed"| F(["Keep in the SCV
minimised & purposeful"])
Data minimisation as a gate: every field in the single view should earn its place against a purpose. Leaders Loop

The discipline here: treat the SCV schema as opt-in, not opt-out. For each field, name the decision it enables. If no one can, that field doesn't belong in the view, dropping it quietly improves both your privacy posture and your data quality, because fields nobody uses are the ones that rot. Minimisation and accuracy turn out to be the same discipline wearing two hats.

The honest tension: minimisation and the "360-degree view" pull against each other, and that's the real design decision in any SCV programme, not how much you can unify, but how much you should. There's no universal answer; there's a defensible one, made on purpose, that you can stand behind in an audit.

A worked example

Picture a mid-sized retailer with a web store, a loyalty app, physical shops and an email programme. (The figures here are illustrative, a composite to show the method, not a real client.) Leadership wants "a single customer view" so marketing can stop sending tone-deaf campaigns, like a 20%-off welcome offer to someone who shopped weekly for three years.

First, the strategy question, per the four perils: which customers matter, and what's a good relationship? The answer turns out to be "retain our top 20% of repeat buyers," which immediately narrows the scope, this is a retention SCV, not a collect-everything SCV.

Next, the CRM-vs-CDP map. They already own a CRM holding loyalty members and service history (known relationships). What's missing is the link to anonymous web and app behaviour. That's CDP territory, they need identity resolution, not another contact database.

Then, data quality. A sample audit is sobering: the same customer averages 2.3 records across systems, because the web store keyed on email, the app on phone number, and the shops on a loyalty card. Illustratively, an estimated 38% of "customers" in the raw count are duplicates. The team sets survivorship rules, loyalty-card identity wins, most-recent contact details win, and the unique customer count drops by roughly a third overnight. The "single view" only becomes real at this step.

Finally, minimisation. Tempted to ingest browsing history going back years, they instead ask what the retention goal needs: recent purchase frequency, category preferences, and channel. Detailed clickstream older than a defined window is dropped, smaller breach surface, cleaner profiles, and nothing of value lost. The campaign that prompted all this now suppresses the welcome offer for known loyal buyers, because the unified record finally knows they're loyal. Illustrative outcome: wasted discount spend falls and the top-20% retention metric the strategy named actually moves, because the view served a decision, not a dashboard.

Notice the order. Strategy scoped it, the CRM/CDP map told them what to build, data quality made the view trustworthy, and minimisation kept it lean. Skip any one and you get an expensive system that unifies the wrong things confidently.

Frequently asked questions

What's the difference between a CRM and a single customer view?

A CRM is a system that manages known customer relationships, contacts, deals, tickets. A single customer view is the unified record itself, assembled from the CRM plus every other source that holds part of the customer (web, app, transactions, support). The CRM is one input to the SCV, and often a consumer of it; it isn't the whole thing. You can own a CRM and still have no single customer view.

Do we need a CDP to get a single customer view?

Not necessarily. A CDP is purpose-built for cross-channel identity resolution, which makes the job easier at scale. But plenty of organisations build a workable SCV with a data warehouse and disciplined matching logic, and a small business may get most of the value from a single well-governed CRM. Buy the category only after the source map shows you actually have cross-channel identity to resolve, not because the acronym is fashionable.

Why do these projects fail so often?

The same reason Rigby, Reichheld and Schefter found in 2002: organisations treat them as technology purchases rather than customer strategies. The platform unifies whatever you point it at, so without a clear decision about which customers matter and what you'll do with the view, it efficiently unifies data in service of nothing. The failures are rarely about the software working; they're about the software working on the wrong problem.

Isn't more customer data always better?

No, and both privacy law and risk management say so. GDPR's data-minimisation principle requires data to be limited to what's necessary for a stated purpose. Beyond compliance, fields nobody uses still have to be stored, secured and kept accurate; they enlarge your breach surface and decay into noise. A leaner, purposeful single view is usually a more accurate one, because every field has an owner and a reason to be right.

How do we know when the single view is "good enough"?

When it reliably supports the decisions you named in your strategy, and no further. Perfect identity resolution is impossible; some records will always be ambiguous. Mature teams set a confidence threshold, accept a small reconciled error rate, and ship. The goal isn't a flawless view; it's a trustworthy-enough one that moves the metric you set out to move.

Related in the Toolkit

Where to go next