Most companies don’t realize their CRM has an architecture problem. At least, not right away. The records are there, the dashboards work, workflows are running and sales is still closing deals. From the outside, everything seems fine. Then someone asks what, in theory, should be a pretty simple question: “How much revenue do we have coming up for renewal next quarter?”
One report says $1.8 million. Another says $1.3 million. Finance has a spreadsheet with a different number altogether. Eventually, someone decides it’ll be easier to export everything and figure it out in Excel. At that point, it’s easy to assume you have a data quality problem (sometimes you do). Often, the biggest issue is how that data was structured in the first place.
Clean Data Doesn’t Always Mean Good Data
When we talk about CRM data quality, the conversation usually goes straight to duplicates, missing values, inconsistent formatting and outdated records. Those are important, but they’re only part of the picture. You can actually have very clean data and still have a CRM that struggles to answer basic questions about the business.
Let’s say a company sells equipment. Each piece of equipment has its own serial number, installation date, warranty and renewal term. The CRM tracks the customer and their deals, but nobody really decided where the equipment itself should live.
So over time, the serial number gets added to the deal. Maybe the warranty expiration date gets stored on the company. Installation information ends up somewhere else. Operations starts keeping a spreadsheet because they need to track details the CRM wasn’t really set up to handle.
None of that necessarily looks wrong when you look at each field individually. The problem is that the CRM doesn’t actually understand the relationship between the customer, what they purchased, the individual device, its warranty and the future renewal.
That might work when you have 50 customers. It becomes a very different problem when you have 5,000.
Your Data Model Is Being Built Either Way
Every time you create a property, add an object, build an association or connect another system, you’re making a decision about your data model.
The problem is that those decisions are often made one at a time.
Sales needs a new field, so one gets created. Marketing needs something for segmentation, so another property gets added. Operations imports a spreadsheet. Someone builds a workflow to solve a process issue. Finance needs information from another platform, so an integration gets connected.
Every one of those decisions can make complete sense on its own, but fast-forward a few years and now you have hundreds of properties, workflows touching workflows, integrations passing data back and forth and spreadsheets filling whatever gaps are left.
Nobody necessarily built it wrong. It just wasn’t built as one system. And that’s usually when seemingly small changes start getting risky because nobody is completely sure what else is connected to them.
Automation Won’t Fix the Foundation
This is something I think is especially important right now because companies are investing heavily in automation and AI. Automation is great, but it doesn’t fix poor architecture. It just moves through it faster.
If your lifecycle stages aren’t reliable, automating around them doesn’t suddenly make them reliable. If duplicate companies exist, an integration can spread those duplicates into another system. If renewal information lives in the wrong place, adding more workflows around it can make the process even harder to untangle later. AI has the same problem.
We’re asking AI to summarize CRM records, identify opportunities, enrich information, recommend next steps and even take actions. But AI still needs context. If the relationships between your data aren’t clear, you’re asking AI to make decisions based on a system that doesn’t fully understand the business either.
Before asking what else we can automate, sometimes it’s worth asking whether the foundation we’re automating on actually makes sense.
Stop Asking Where You Can Put the Field
One question I hear a lot when building something in a CRM is some version of: “Where can we put this?” A better question is: “What does this actually belong to?”
Take a renewal date. Putting a Renewal Date property on a company sounds completely reasonable. But what if that company eventually has 10 contracts? What if those contracts cover 50 devices? What if some of those products renew in March and others renew in October? Now one company-level Renewal Date doesn’t really represent what’s happening anymore.
It wasn’t necessarily a bad decision when it was created. It may have been exactly what the business needed at the time. The problem is when the business changes and the data model never changes with it.
That’s when you start seeing increasingly complicated workflows, reporting exceptions, integrations with special rules and spreadsheets sitting beside the CRM because there isn’t a clean way to represent something inside it. And at that point, I wouldn’t immediately blame the spreadsheet. Usually, the spreadsheet is telling you something.
Good Architecture Usually Makes Things Simpler
A well-designed CRM doesn’t mean building the most complicated system possible. Actually, I think the opposite is true. When the architecture makes sense, a lot of other things get easier.
Sales knows where information belongs. Marketing can build segments without wondering whether the data is trustworthy. Operations understands which system owns which information. Developers don’t have to build around dozens of exceptions just to keep two systems in sync. Even workflows get simpler because you’re no longer asking automation to compensate for how the data was structured. Most importantly, people start trusting the CRM.
When leadership asks how much revenue is up for renewal next quarter, the goal shouldn’t be figuring out which report is right. There should just be an answer.
Before You Build the Next Thing
It’s easy to get excited about the next integration, workflow, AI tool or new CRM feature. And sometimes that absolutely is the right next step.
But before adding another layer, it’s worth asking: Does our CRM actually represent how our business works today?
Not how it worked three years ago. Not how the original implementation was designed. And not how we had to structure it because we needed something working quickly. How it works today.
Sometimes the biggest improvement you can make to a CRM isn’t adding anything at all. It’s taking a closer look at the foundation and making sure everything you’re about to build has the right place to stand.
.jpg?upscale=true&width=240&upscale=true&name=The%20Deep%20View%20Conversations%20podcast%20art%20(1).jpg)
