Let me tell you about a dashboard I saw last month that was, by any reasonable measure, beautiful.
Gorgeous, actually. Real-time revenue by practice group. Client acquisition cost trending downward. A pipeline funnel in three colours that would make a McKinsey slide designer weep with joy. The operations director who'd commissioned it was visibly proud - and fair enough, it had cost the thick end of £80k to build, including the BI platform licence and the integration work to pull data from three different systems.
There was just one problem. The numbers were wrong.
Not dramatically wrong. Not obviously wrong. Wrong in the way that's genuinely dangerous - off by enough to change decisions, but not by enough to trigger suspicion. The pipeline figure was inflated by roughly 30% because of duplicate contact records in the CRM. The revenue-by-sector breakdown was meaningless because different teams tagged the same clients under different categories. And the client acquisition cost? Calculated against a denominator that included prospects who'd been dead for two years but nobody had bothered to mark as closed-lost.
I remember sitting with the operations director afterwards - we'd gone to get coffee, away from the rest of the team - and she said, almost to herself, "I knew something felt off." She'd had a nagging sense for months that the pipeline number was too high. But the dashboard looked so authoritative that she'd talked herself out of it. That's the bit that stuck with me.
The managing partner had been using this dashboard in board meetings for six months. Decisions had been made. Resource had been allocated. A hiring plan had been approved based on projected pipeline conversion. All of it built on data that was, to use a technical term, rubbish.
I call this the dashboard delusion. Not because dashboards are bad - they're genuinely useful when the data underneath them is trustworthy. But a dashboard that visualises unreliable data doesn't make better decisions possible. It makes worse decisions look better-supported.
Here's what makes this particularly insidious. A number on a spreadsheet that someone cobbled together in Excel carries a certain amount of implicit doubt. Everyone in the room knows it's an approximation. They interrogate it. They say things like "that feels about right" or "I think that's probably overstated" - and that healthy scepticism actually protects the decision.
Put that same number in a chart, inside a platform, with a percentage sign next to it and a timestamp showing it was updated twelve minutes ago, and something shifts psychologically. It looks authoritative. It looks like a fact. Leadership acts on it with a confidence it hasn't earned.
This is the bit that most technology leaders underestimate. The problem isn't just that the data is inaccurate. The investment in visualisation has removed the human scepticism that was previously compensating for the inaccuracy. You've spent money to make your decision-making worse.
We've got dashboards. People use them. The data's not perfect, but it's a separate issue we'll get to eventually.
I hear variations of this constantly. And I understand the logic - you've made the investment, people are using the tools, and fixing the underlying data feels like a different project for a different day. But "eventually" never comes. It doesn't come because the dashboard creates the illusion that the data problem has already been solved. The very existence of a professional-looking reporting layer makes it harder, not easier, to get leadership attention on the quality of what's underneath it.
If you're running operations or technology in a mid-market B2B service firm, you're almost certainly dealing with some version of all of this. Let me walk through the patterns I see most often - not as a tidy taxonomy, but because naming them is usually the first step to admitting they're yours.
Duplicate records are the most common and the most corrosive. The same client appearing multiple times with different information in each instance. "Acme Corp", "Acme Corporation", "ACME Corp Ltd", and "Acme (Manchester office)" are all the same client, but your CRM thinks they're four different organisations with four different revenue histories. Every report that aggregates by client is wrong before it starts. I worked with a professional services firm last year that discovered, during a data audit, that their "top 50 clients by revenue" list was actually a top 38 list with twelve duplicates. They'd been using it for partner compensation discussions. Nobody had noticed - or if they had, they hadn't said anything.
Then there's inconsistent tagging. Categories and labels applied differently by different people or teams, making aggregation meaningless. One practice group tags work as "Advisory," another calls it "Consulting," a third uses "Strategic Advisory Services." Your sector tags are even worse - is it "Financial Services" or "FS" or "Banking & Finance"? When I ask firms about this, they usually know it's a problem. They just haven't quantified how much of their reporting it invalidates. The answer, in my experience, is most of it.
Data silos are where things get politically complicated. The same data living in multiple systems with no single authoritative source and no reliable synchronisation. Client contact details in the CRM, different contact details in the billing system, a third version in the marketing platform. Which one is right? Nobody knows. So people maintain their own spreadsheets - which, let's be honest, is what's actually happening in most firms I work with. The "single source of truth" exists in theory. In practice, everyone trusts their own version.
And then there's the ownership problem, which is really what all of this comes back to. Nobody is responsible for the accuracy of the data, so nobody fixes it when it's wrong. There's no data owner for client records. No agreed standard for how contacts should be entered. No process for identifying and merging duplicates. No regular audit. The data just degrades. Slowly. Continuously. And everyone assumes someone else is dealing with it.
Sound familiar? Yeah. I thought so.
Right, here's where I'm going to say something that might land a bit uncomfortably.
Poor data quality is not a technical failure. It's a leadership failure. I don't mean that unkindly - I've seen it in firms run by brilliant people. But the pattern is always the same: data quality gets treated as something the IT team or the CRM administrator should sort out, when it's actually a problem that can only be solved by the people who run the business.
The reason your CRM has duplicate records is that nobody has decided, at a sufficiently senior level, that accurate client data matters enough to create standards and enforce them. The reason your tagging is inconsistent is that nobody has convened the practice group heads, agreed a shared taxonomy, and made compliance with it non-negotiable. The reason your data sits in silos is that nobody with enough authority has said "this system is the authoritative source, and everything else syncs from it." These are not technical decisions. They're organisational decisions. And they require the kind of authority that a data manager simply doesn't have.
I remember a conversation with a COO at a consulting firm - maybe 180 people - who told me, slightly sheepishly, that he'd spent two years asking the CRM team to "clean up the data." Two years. Nothing had changed. When we dug into why, it was obvious: the CRM team could clean the data, but they couldn't stop partners entering it badly. They couldn't mandate a tagging standard across practice groups. They couldn't decide which of three systems was the authoritative source for client records. Only he could do that. He just hadn't. And to his credit, he knew it. He said something like, "I think I've been hoping it would sort itself out." It won't. It never does.
I get why this happens. Data quality improvement is unglamorous. It doesn't have a launch date. Nobody's going to congratulate you at the partner meeting for implementing a duplicate detection workflow. And it requires the kind of cross-functional agreement that's politically difficult in any firm, but especially in partnerships where practice group autonomy is sacrosanct.
But the alternative is what you've got now: expensive tools producing unreliable outputs, leadership maintaining shadow spreadsheets because they don't trust the systems, and an organisation that thinks it's data-driven because it has dashboards - while actually making decisions on gut feel with extra steps.
I've written separately about what "using AI in your business" actually means for mid-market firms, and one of the things I keep coming back to is this: AI doesn't fix bad data. It amplifies it.
The numbers are striking. Seventy-one percent of organisations now say they regularly use generative AI, according to McKinsey's 2025 State of AI report. Over 85% of financial firms are actively applying AI. And yet - only 7% of CFOs report seeing high ROI from their AI investments, according to Forrester's 2024 survey.
Seven percent. Let that land for a moment.
There are many reasons AI pilots disappoint, but in my experience, the single most common one is that the data wasn't ready. Sixty-eight percent of organisations report that legacy systems obstruct AI adoption - and "legacy systems" is often a polite way of saying "systems full of inconsistent, duplicated, ungoverned data."
Here's why this matters so much. Traditional reporting tools - your dashboards, your spreadsheets - are at least transparent in their logic. You can see the formula. You can trace the number back to its source. AI doesn't work that way. A model operating against a dataset full of duplicates, inconsistencies, and gaps will produce outputs that are confidently wrong in ways that are very hard to detect.
It'll tell you that your most profitable sector is financial services when actually it's technology - because financial services clients have more duplicate records and the revenue is being counted twice. It'll recommend that you prioritise a specific service line based on growth trends that are really just the result of inconsistent tagging creating phantom categories. It'll generate client insight summaries that blend data from three different records for the same company, producing a profile that's a fiction assembled from fragments.
And it'll do all of this with the calm authority of a system that has no idea it's wrong.
The firms getting genuine value from AI - and some absolutely are - are almost always the ones that did the boring, unglamorous work of cleaning and governing their data first. They didn't skip to the exciting bit. They earned the right to use AI by making sure it had something reliable to work with.
So. Practical steps. I'll be honest - I'm slightly wary of turning this into a four-point framework with a catchy acronym, because that's not really how this work goes. But there is a sequence, and the sequence matters.
Start with an audit. Before you fix anything, understand what you've got. Where does your data live? How is it maintained? What are the quality problems, and where do they concentrate? In most firms I work with, this exercise alone is revelatory - you'll find that 80% of your data quality problems originate in about 20% of your processes, usually the ones where data is entered manually with no validation. A decent audit takes two to three weeks, not months. Don't overthink it.
Then assign ownership. Who is accountable for the accuracy of client records? Contact data? Activity data? Financial data? "Accountable" means a named person who can be asked "is this data reliable?" and is expected to know the answer. This is where most firms stall, because ownership implies authority - and authority over data in a partnership means navigating politics. There's no way around that. Someone senior needs to back this, or it won't stick.
Once you've got ownership, define standards. What does "correct" look like for each data type? If a client record requires a company registration number, make the field mandatory. If sector tagging must use a controlled list, remove the free-text option. This isn't about perfection - it's about stopping the bleeding. Every new record that enters the system clean is one fewer record you have to fix later.
And then - only then - think about integration. Connect systems so that data is entered once and flows reliably rather than being duplicated across multiple environments. This is where technology investment actually makes sense. Not in dashboards. In the plumbing. I've seen firms spend six figures on integration projects that essentially automated the distribution of bad data to more places. Don't do that.
Let me close with something I find myself saying to operations and technology leaders more often than almost anything else: fixing data quality is not a background task. It's a programme. It needs a sponsor, a budget, a timeline, and a defined scope. If you're trying to do it in the margins of someone's day job, it won't happen.
The good news is that it doesn't need to be expensive. A focused data quality programme for a mid-market B2B service firm - 150 to 500 people, say - typically takes three to six months and costs a fraction of what you've already spent on the dashboards and platforms that are currently visualising unreliable data. The ROI isn't hypothetical. It's the difference between a leadership team that trusts its own numbers and one that maintains private spreadsheets.
And if you're thinking about AI adoption - and at this point, who isn't - the quality of your data is the single biggest determinant of whether those investments will pay off or disappoint. The firms that invest in data quality now are positioning themselves to extract real value from AI in twelve to eighteen months. The firms that skip this step and go straight to AI tooling are setting themselves up for expensive pilots that produce impressive-looking outputs nobody trusts.
Which is, if you think about it, the dashboard delusion all over again. Just with more sophisticated technology and higher stakes.