Without a single customer view (SCV) you are going to see lost revenue of 5-10% from missed cross-sell/up-sell opportunities and 2-5% additional churn from poor experience and missed signals. Gartner calls it $12.9M per year, IBM gives a range of $7M to $25M, House of Martech points at $7.8M in lost productivity due to the toil of duplicated work.

For a $100M company you’re responsible for $5M-$15M of revenue leakage. You have two choices, solve the SCV problem or prepare excuses for your board, investors, and successor.

Why it keeps not getting done

If the consequences are this serious, why do so many companies still not have a single customer view? The answer usually comes down to a combination of misclassification, misguided effort, and underestimated complexity.

It gets handed off and deprioritised. Once it’s framed as a data or IT project, it enters a queue. It competes for resources with other technology initiatives. It gets scoped, estimated, and scheduled – and then, typically, delayed. The business urgency that motivated it in the first place gets lost in the backlog.

Companies try to solve the wrong problem. The two most common anti-patterns are: first, trying to turn the CRM system into the master customer record; and second, overengineering a governance and compliance framework before the business problem is even defined.

CRM tools are not designed to be master data management systems. They’re transaction tools. Attempting to consolidate customer data into a CRM is a category error that creates the illusion of progress while the underlying fragmentation remains. Similarly, building an elaborate compliance and governance layer first treats the non-functional requirements as if they were the goal. Governance and compliance are necessary features of any well-designed customer data system, but they’re not why you build it. The goal is a single, accurate view of your customers. Everything else serves that.

The complexity is routinely underestimated. There’s a principle in information theory that a system which models a problem has to be at least as complex as the problem itself. You can’t make it simpler than the minimum complexity the problem requires. When CEOs push for faster delivery or cheaper solutions, the question isn’t whether a simpler approach is possible, it’s whether a simpler approach can actually model the problem. If it can’t, it won’t work. Nine engineers can’t make a baby in a month, as the old saying goes. Some problems take the time they take.

Key knowledge lives in one person’s head. In many mid-market companies, the ability to produce anything resembling a single customer view depends on one or two individuals who know how the systems fit together and can navigate across them. We call this ‘hero risk’ and it’s more common than executives realise. Run a simple analysis of who’s responsible for maintaining the integrations between your key customer-facing systems. If the answer is one person, ask yourself: what happens if they leave? The informal single customer view leaves with them. And the business often has no idea how dependent on it they’ve become until it’s gone.

SaaS proliferation makes it worse. Mid-market companies have typically grown their technology stack by accumulating point solutions – a CRM here, a marketing automation tool there, a billing system, an analytics platform, a customer support tool. Each solves a specific problem. Each holds a slice of customer data. And the work of keeping them in sync, of reconciling the differences between them, is often an afterthought – handled by integrations of varying quality, maintained by whoever had time to build them, and understood by very few people.

How to start building the single customer view

The solution is not to centralise everything into a single system. That approach is expensive, brittle, and typically fails because the business logic embedded in each system is as hard to migrate as the data itself. The goal is aggregation and reconciliation – the ability to bring together a consistent, accurate view of the customer without destroying the systems that hold the underlying data.

A practical roadmap looks something like this:

Start by defining what “customer” actually means for your business. This sounds obvious but it isn’t. What data elements define a customer in your context? What sources hold that data? Where are the gaps between what you need to know and what you can currently see? This is the foundation, and skipping it is the single most common reason these projects fail.

Audit what you have. A rigorous gap analysis – what’s relevant, what’s missing, what’s irrelevant – gives you a clear picture of the terrain. It also tells you where your compliance exposure is greatest, where your data quality is lowest, and where your hero risk is concentrated.

Implement identity resolution. The same customer appears differently in different systems. John Smith in the CRM. A customer ID in the loan origination system. A username in the web analytics platform. Reconciling these – building a reliable, deduplicated identity layer – is the technical foundation of a single customer view. It’s unglamorous work, but there’s no shortcut.

Build a single layer that brings everything together – without replacing anything. The architecture that works in practice doesn’t require you to rip out your existing systems and replace them with one giant platform. Instead, think of it as building a coordination layer that sits across your existing tools, pulling data from each of them, reconciling the differences, and making a clean, consistent view available to any system that needs it. The CRM can still see what it needs to see. The billing system keeps its own data. The customer support platform can pull up a complete interaction history. None of them become the master record, but any of them can access one.

Make the rules part of the infrastructure, not an afterthought. Once you have that coordination layer in place, it becomes the right place to embed your data governance – who can see what, which data has to stay in which country, how PII is handled across jurisdictions. The practical effect is that any system or person querying customer data automatically gets only what they’re permitted to see, without having to implement those rules themselves. Compliance stops being a patchwork of individual systems each doing it differently, and becomes something consistent and auditable across the business. This is how you reduce regulatory exposure without making compliance the whole project.

Treat it as continuous, not one-and-done. The world changes. Your technology stack changes. You acquire companies. You enter new markets. A customer data architecture that isn’t designed to evolve will calcify. The goal is to build a system that can accommodate change – new data sources, new compliance requirements, new business definitions – without requiring a full rebuild every few years.

Five questions to ask this week

You don’t need a full technology assessment to know whether this is a problem worth addressing. These questions will tell you a great deal:

1. Can my team produce a single, consistent view of any customer on demand – without a spreadsheet? If the honest answer involves any manual reconciliation, the answer is no.
2. Do the customer metrics in our board reporting all draw from the same source of truth? If different reports use different systems and occasionally disagree, that goes beyond a data quality issue. It’s a governance issue – and potentially a compliance one.
3. If our top two data people left tomorrow, could we still answer basic questions about our customer base? If the answer is uncertain, your single customer view is a person, not a system.
4. Do we know where every piece of customer data lives, and whether it’s governed consistently? For companies that have grown through acquisition, this question is particularly important, and frequently unanswered.
5. Are we compliant with data residency and PII rules for every jurisdiction our customers are in? If this is being handled differently in different systems, it almost certainly isn’t being handled consistently.

The real impact of not having it

A single customer view is not a technology project you commission and forget. It’s a business capability – one that underpins every customer decision you make, every metric you report, every compliance obligation you carry, and every opportunity to use data intelligently as your business scales.

The impact of not having it often remains invisible until it suddenly isn’t. It’s the board metrics that don’t quite reconcile. It’s the customer who churned because no one connected the dots. It’s the regulatory inquiry that reveals inconsistent data governance. It’s the humiliating meeting where you don’t know the answer to your counterparty’s very reasonable questions.

Don’t ask yourself whether you can afford to build this capability but whether you can afford not to have it – and whether you know, right now, which side of that line you’re on.

Ten Mile Square helps growth-oriented companies diagnose and address the technology and data challenges that are holding their businesses back. If these questions reveal gaps you’d like to understand better, our 5-step technology assessment is a practical first step.