Companies rarely set out to run several CRMs. It happens through acquisitions, regional autonomy, a departmental purchase that grew, or a migration that never quite finished. Then someone asks a simple question, “how many customers do we have?”, and three systems give three answers.

Before any tooling, you need a decision about which system is the authority for which piece of data. That decision is called choosing the system of record, and skipping it is the root cause behind most of the sync fights and duplicate records in multi-platform setups.

System of Record Is Per Field, Not Per Company

It is tempting to declare one platform “the master” and be done. In practice, different systems are best placed to own different facts. The billing system knows the legal entity name and payment terms. The marketing platform knows consent and subscription preferences. The sales CRM knows deal stage and owner. Support knows open cases.

Trying to force everything into one place often loses the detail that made each system useful. A better model is to assign ownership at the level of each data element, and let other systems hold read-only copies.

Build a Field Ownership Matrix

Start with the objects that matter most: account, contact, opportunity, product, and any identifier that links them. For each important field, record the owner, the consumers, the direction of flow and the update frequency.

Data Element	Owning System	Consumers	Flow	Freshness Needed
Legal entity name	Billing/ERP	All CRMs	One-way out	Daily
Primary contact email	Regional CRM	Marketing, support	One-way out	Near real time
Marketing consent	Consent platform	All	One-way out	Real time
Deal stage and owner	Sales CRM	Finance reporting	One-way out	Hourly
Open support cases	Service desk	Sales CRM (view)	One-way out	Hourly

This is an illustration. Your table will reflect your systems and your priorities. What matters is that every row has exactly one owner.

Settle Identity First

None of this works without a reliable way to say “this record in system A and that record in system B are the same customer.” Options include a shared customer ID issued by one system, a cross-reference table maintained in middleware or a data warehouse, or matching on stable attributes.

Matching on name and email alone is fragile because people change addresses and companies have many spellings. If you can create a persistent customer identifier and push it to every system, do that early. It makes every later problem easier, including reporting, migration and consent management.

Decide How Conflicts Are Resolved

Even with clear ownership, edge cases arise. A rep fixes a phone number in a non-owning system, and the next sync overwrites it. People then lose trust in the data. Decide, per field, what happens: the owning system always wins, the most recent change wins, or edits are blocked in non-owner systems.

Blocking is often kinder than silent overwriting. If a field is read-only elsewhere, make it visibly read-only, and give users an easy route to request a correction from the owner. Silent loss of edits is the thing that drives people back to spreadsheets.

Handle Existing Duplicates

You almost certainly have duplicates already. Plan a one-off clean-up separate from the ongoing design. Typical steps are defining match rules, reviewing a sample of proposed merges with account owners, choosing survivorship rules about which values win when records merge, and keeping a log so merges can be traced and, if needed, reversed.

Be conservative at first. A false merge, combining two different customers, is harder to repair than a missed duplicate.

Don’t Forget Privacy and Region

If systems are split by region partly for data residency reasons, the system of record might need to stay put by design, and copies elsewhere may need to be limited or pseudonymised. Requirements vary by jurisdiction, so involve privacy and legal advisers before centralising personal data.

A Hypothetical Example

Consider a group with a sales CRM in one region and a different platform in another after an acquisition. Both hold accounts for a shared multinational customer, with different names and owners. The group creates a persistent customer ID, assigns legal name ownership to the ERP, and designates each regional CRM as the owner of contacts in its own region.

Reporting then joins on the shared ID, and a monthly review of unmatched records catches new duplicates. Nobody had to migrate the platforms to get a single view of the customer.

Document and Revisit

Publish the matrix where people can find it, with a named data steward for each domain. Revisit it whenever a new system joins or a merge happens, since an out-of-date matrix is worse than none: it gives false confidence.

Frequently Asked Questions

Do we need a master data management tool? Not necessarily. Smaller estates can manage with a cross-reference table, clear ownership and disciplined sync. Dedicated tools make sense as scale and complexity grow.

Can two systems own the same field? Avoid it. Shared ownership creates conflicts. If both teams genuinely need to edit, split the field into two with different meanings, or route changes through one system.

What if the owning system has poor data quality? Fix it at the source. Syncing bad data outward only spreads the problem faster.

How do we get teams to accept read-only fields? Explain the reasoning, make the owner visible on the field, and provide a quick correction process. Resistance falls when corrections actually get made.

Who decides ownership when teams disagree? A cross-functional data governance group with an executive sponsor, since the conflicts are usually about organisation as much as technology.

Next Step

Pick the five most contested fields, write down their current owners, and get the relevant team leads to agree on one authority for each.