You don't discover how broken your data is by running an audit.
You discover it the moment you try to connect two systems that were never designed to talk to each other.
A team recently sat down to integrate their ERP with their CRM. The goal was straightforward: sync customer records so the sales team could see financial context — credit limits, balances, overdue status — without flipping between screens.
Simple enough. Until they pulled the customer table.
One Hundred Thousand Reasons to Pause
The ERP held over 100,000 customer records. Same company appearing twice under slightly different names. Cash-only accounts flagged not with a status field, but by appending text to the customer name. Contacts stored one-per-customer in a structure that assumed every business relationship is a single-threaded conversation.
This isn't unusual. This is what every ERP looks like after a decade of real use. Nobody built it wrong. The system just accumulated decisions — each one reasonable at the time, collectively unintelligible to any other system.
The integration project wasn't really an integration project. It was an archaeology project.
The Six Decisions That Changed Everything
What made this session remarkable wasn't the mess. It was the clarity.
The team worked through six architectural decisions in a single sitting:
- Scope the sync. Active customers only, last two years, excluding cash-only accounts. Not because the others don't matter — because you can't clean 100,000 records and build a sync engine at the same time.
- Establish data ownership. The ERP owns financial fields. The CRM owns relationship fields. Neither overwrites the other's domain. Simple rule, but most organizations never state it explicitly — and then spend months debugging why data keeps reverting.
- Build three-tier matching. Customer ID first (exact match). Email domain second (strong signal). Fuzzy name matching third (human review). The fact that you need three strategies to answer "is this the same company?" tells you everything about the state of the underlying data.
- Auto-create with a flag. Unmatched records get created automatically — but flagged for human review. This is the balance between speed and quality that most integration projects never find. They either go full-manual (and the backlog becomes infinite) or full-auto (and garbage data flows downstream unchecked).
- Map territory to ownership. ERP sales rep assignments mapped to CRM contact owners. This seems like a technical detail. It's actually the bridge between two completely different models of who owns the relationship.
- Define the financial bridge. Credit limits, available credit, overdue status — the financial intelligence that sales teams always want and never have. Not because it doesn't exist, but because it exists in a system they can't see.
Six decisions. Each one surfacing a different kind of debt.
The ERP Trap
Here's what most teams miss: the ERP isn't the problem. The CRM isn't the problem. The problem is that nobody ever built a Unified Customer View.
When your financial data lives in one system and your relationship data lives in another, you don't have two systems — you have two incomplete pictures of the same customer. Every person in the organization sees a different slice. The sales team sees the relationship. The finance team sees the balance sheet. The operations team sees the orders. Nobody sees the whole person.
That's the ERP Trap. Not the software itself, but the assumption that because data exists somewhere, it's accessible to everyone who needs it.
What Quiet Adoption Looks Like
Nobody in that room said "digital transformation." Nobody said "unified data architecture." They said: "We want the sales team to see credit limits without switching screens."
But look at what they actually built:
- →A data ownership model that prevents conflict between systems
- →A matching framework that handles the messiness of real-world data
- →A financial bridge that gives context to every sales conversation
- →A review process that maintains quality without creating bottlenecks
That's a Unified Customer View. They just didn't call it that.
This is how real adoption happens. Not with a transformation initiative and a steering committee. With a practical problem and the willingness to make architectural decisions instead of avoiding them.
The team that approached this as an "integration project" left with something much more valuable: clarity about where their data lives, who owns it, and how the pieces fit together.
The Prescriptive Shift
One more thing worth noting. The session worked because the team responded to prescriptive recommendations instead of open-ended questions.
Too many consulting engagements start with "What do you want?" and end with the client doing all the thinking. This team wanted expert guidance. They wanted someone to say: "Here's how this should work. Does that match your reality?"
That shift — from facilitation to prescription — is a signal. It means the relationship has earned enough trust that the team would rather move fast with confident guidance than slow with consensus-driven exploration.
The decisions got made in one session. Not because the problems were simple. Because the approach was direct.
The Path Forward
If you're about to integrate your ERP with your CRM, know this: you're not doing an integration. You're building the foundation of a Unified Customer View.
That means the real work isn't writing API connectors. It's answering questions you've been avoiding:
- →Who owns this data?
- →What constitutes a "customer" across both systems?
- →What do your people actually need to see to do their jobs?
The technology is the easy part. The architecture is the hard part. And the hardest part of all is admitting that two systems holding the same customer's data isn't "working fine" — it's working around the absence of a real foundation.
Start there. The integration will follow.