Most businesses don't suffer from a lack of data—they suffer from a lack of clarity. When information is scattered across systems and teams, leaders are left making critical decisions without a complete picture.

Why most services businesses are flying blind — and what it actually takes to see clearly

There is a moment in a strategic planning session that we have come to recognize immediately. The leadership team is around the table. Each department head is making their case — describing their pain, naming the opportunities being left on the table, explaining why their initiative should be the priority. The arguments are passionate. Some of them are compelling.

And then someone asks: what does this cost the business?

The room goes quiet.

Not because the leaders don't care about the financial impact. Not because they haven't thought about it. But because no one in the room can answer the question with a number they actually trust.

This is the moment when a leader realizes — sometimes for the first time, in those words — that their organization has data everywhere and insight nowhere. They are flying blind. They know something is wrong. They can feel the weight of decisions that need to be made. But when they reach for the data that should make those decisions clearer, what they find raises more questions than it answers.

What Flying Blind Actually Looks Like

In most mid-market services businesses, the data problem is not a shortage of information. It is an abundance of the wrong kind, stored in the wrong places, in formats that were never designed to talk to each other.

There is the CRM that the sales team uses. The separate operations system that manages service delivery. The financial platform that accounting lives in. The spreadsheets — and there are always spreadsheets — that individual contributors have built over years to track the things none of the systems track automatically. In some cases, entire business functions are still being managed in Excel. Not because the people running them are unsophisticated, but because no one ever built them a better option, and a spreadsheet in the hands of someone who knows the business deeply can do remarkable things.

The problem is not the spreadsheet. The problem is that a spreadsheet is invisible to everything else. The insight it contains — the customer data, the operational metrics, the exception tracking that one person has been maintaining for six years — exists only for the person who built it and the people they choose to share it with. It cannot be queried at scale. It cannot feed a dashboard. It cannot power a workflow. It cannot tell the leadership team what they need to know in a planning session.

When someone does manage to pull all of this data together in one place — which is itself a significant undertaking — what they usually discover is that the data quality undermines the analysis before it begins. Misspellings in customer names. Duplicate records created because the legacy system had no enforcement on unique identifiers. Accounts that should be linked — five contacts at the same company, all entered separately, with no relationship between them in the database — treated as independent customers. Fields used inconsistently across different time periods, or different regions, or different teams who each developed their own conventions.

This is the moment when trust in the data evaporates. And once trust is gone, the organization reverts to what it was doing before it tried to use data: making decisions based on gut feeling, institutional memory, and whichever fire is burning loudest that week.

Why Services Businesses Have It Worse

Every business has data quality problems. But services businesses — particularly mature ones that have been operating for twenty years or more — have them in ways that are structurally different from digital product companies, and harder to resolve.

A SaaS company is, by definition, built on a digital foundation. Every user interaction is a data event. Marketing flows directly to website conversions, to product signups, to feature usage, to churn signals. The business is engineered to measure itself. KPIs are defined before the product launches, because the product cannot function without them.

A services company is built on human engagement. The exceptional service that built its reputation — the account manager who anticipates a client's needs, the operations lead who finds a workaround when a system fails, the customer service rep whose relationships have held key accounts for a decade — is delivered through judgment, experience, and personal knowledge that has never been formalized, documented, or entered into a system.

By the time a services business reaches maturity, its people have engineered hundreds of ways of getting things done. Each approach is a response to a specific customer need, a specific operational constraint, a specific moment in the business's history. Individually, each approach represents exceptional service. Collectively, they represent a data analyst's nightmare — a landscape of variability so extensive that no two records describe the same experience in the same way.

This variability is not a failure. It is the natural result of a business that has prioritized people over process for a long time. But it is the central challenge that any transformation initiative — and any AI capability — has to navigate. You cannot build on top of data you cannot trust.

What a Data Audit Actually Involves

When we tell a client they need a data audit before they can build anything, the reaction is sometimes impatience. They came to us to move forward, not to look backward. They want to build the product, launch the platform, deploy the AI. The audit feels like delay.

What it actually is, is the foundation that determines whether everything built on top of it works.

A data audit begins with assumptions. We document how we believe the business operates — the processes, the workflows, the customer journeys — and we translate those assumptions into questions we can ask of the data. If the sales process works the way we think it does, then the data should show us X. If the service delivery process works the way we think it does, then the records should look like Y.

Then we let the data tell us where the assumptions fail.

The failures are not a problem. They are the point. Each assumption that the data cannot confirm tells us something specific: either the process doesn't work the way we thought it did, or the data wasn't captured in a way that can confirm it, or both. That information is exactly what we need to know before we build anything — because every process we intend to automate, every AI capability we intend to deploy, every product feature we intend to release requires the data beneath it to be reliable.

What we typically find in this process is a combination of data quality issues, duplicate records, inconsistent formatting, and structural problems with how data is related. A customer who exists in three different systems under three slightly different names. An account with five contacts that are not linked to each other. Fields that were repurposed over time — used to track one thing in 2015 and a different thing in 2022, with no documentation of the change.

Data normalization — the process of cleaning, standardizing, and structuring this data so it can be used — is almost always the largest effort in a digital transformation engagement. It is almost always the most underestimated. And it is almost always what separates the initiatives that deliver on their promise from the ones that stall at the moment they were supposed to launch.

What Bad Data Actually Costs

The cost of bad data is not abstract. We have seen it materialize in specific, expensive ways.

Consider a business preparing to launch a customer-facing digital product — an online booking tool, a self-service portal, a mobile app. The product is built. The user experience is designed. The launch date is set. And then someone runs a test against the actual customer database and discovers that the customer records cannot support the product as designed.

Email addresses — which modern digital platforms use as unique identifiers, the key that ties a customer to their account — are missing, duplicated, or incorrect in a significant portion of the records. Customer hierarchies that a human service rep navigates intuitively — knowing that these five contacts all belong to the same account, that this person is the decision-maker and these others are the end users — do not exist in the database as structured relationships. They exist in the service rep's head.

The launch is delayed. The data normalization effort that should have happened at the beginning of the project now has to happen under deadline pressure, with the team that was supposed to be focused on launch activities redirected to data cleanup. The people most capable of doing that work are the ones who have been at the company the longest and know the legacy systems most deeply — and they now have to document and standardize, from memory, relationships and conventions that were never written down.

This is not a technology failure. It is a sequencing failure. The audit that would have surfaced these issues in month one is now being performed under the worst possible conditions.

What Good Data Actually Looks Like

Good data is a relative term — and an honest conversation about it starts with honesty about how far most businesses are from it on day one.

The best case is a business running on modern digital platforms that enforce data entry rules, require unique identifiers, and maintain clean relationships between records. In this environment, the data architecture is already built to support analysis and automation. What's needed is definition — deciding what to measure, setting the KPIs, and building the reporting that makes the data visible and actionable for the people who need it.

Most of the businesses we work with are not in this position. They are working with multiple databases, separate systems, historical spreadsheets, and legacy data that accumulated over years before anyone thought about how it would eventually need to be used. The path from where they are to where they need to be runs through normalization, migration, and consolidation — staged carefully so that progress can be made and features can be released while the work continues.

This process takes time. For a mid-market services business of meaningful age and scale — one serving multiple customer segments across multiple geographies, running several disconnected systems — a thorough data normalization effort typically takes three to six months. That timeline is not delay. It is investment. The alternative is building on a foundation that will fail at the worst possible moment.

What the roadmap looks like in practice is a staged approach: clean and structure the highest-priority data first, build and release the first features on top of it, then move to the next segment of data and the next set of features. Progress is visible throughout. The business is not waiting for a three-year initiative to deliver value. It is releasing capabilities in sequence, each one building on the foundation established by the previous one.

Why We Build It This Way

The data audit is not a phase that exists because we enjoy finding problems. It exists because insight is the operating system of a transformed business — and you cannot install an operating system on hardware that isn't ready to run it.

Every article in this series has returned to the same starting point: before you build anything, you have to understand what you are working with. The current state of the business. The processes that are actually running. The people who are actually doing the work. And the data that is — or is not — capturing what the business actually does.

The Plan phase of our methodology is where the data audit lives, and it lives there by design. Not because it is pleasant, and not because the findings are ever entirely comfortable. But because the leaders who do this work at the beginning are the ones who can answer the question in the strategic planning session — the one that silences the room — with a number they actually trust.

That number changes everything. It changes the priority conversation. It changes the investment conversation. It changes the relationship with ownership. And it changes what the business is able to build next.

Insight is not a luxury for businesses that have the time to pursue it. It is the foundation that every other capability rests on. And it starts with being honest about what the data can — and cannot — tell you today.

This is part of a series of six articles exploring the most common challenges facing digital transformation leaders — and how a connected, cross-functional approach changes the outcome. Read the full series here.