Why domain matching keeps merging the wrong two companies

A lead comes in, gets auto-associated with a company record, and routes to the wrong team. Nobody misconfigured the routing rule. The company record the lead landed on is simply the wrong one of two nearly identical records sitting in the same CRM, both plausible, only one correctly formatted. Whoever built the routing logic did their job. The matching logic underneath it did not.

The usual response is a cleanup project: export the duplicates, merge them, close the ticket. That fixes the backlog for exactly as long as it takes the sync to run again. If the logic that created those duplicates in the first place hasn't changed, it will produce a fresh batch on the same schedule it always has. A dedup sprint without a matching-logic fix is mopping a floor under a leak you haven't found yet.

The fix starts by treating this as a design question, not a housekeeping task: given an incoming record, what signals does your matching logic trust, in what order, and what happens when they disagree?

When we've traced misrouted records back to their source, the duplicates almost never come from one cause. They come from three, running at the same time.

The first is inherited mess: duplicates that predate the current matching logic and have simply never been swept. They sit there until someone happens to notice a record with a missing field, or a lead routes strangely enough that a rep asks why.

The second is a false negative in the matcher itself. This is the one people don't expect: most matching engines don't create a duplicate by actively getting confused between two real companies. They create one because they fail to recognize that an incoming record already matches something in the system, so they file it as new. A small formatting difference is usually enough to trigger this: an abbreviation appended in parentheses, or a suffix one record has that the other doesn't. Exact-string matching has no tolerance for either.

The third source is the sync itself. In a two-platform setup, records flowing from the CRM side into the marketing platform (or the reverse) aren't always reconciled against what already exists on the receiving end before they're written. Every pass of the sync becomes a second opportunity to create the same duplicate a different way.

None of these three causes gets fixed by the other two. A sweep clears the first. It does nothing for the second or third, which is why the same account can look clean in January and be duplicated again by March.

Matching on email domain feels like the obvious shortcut: it's a stable, deterministic value, unlike a company name that gets typed six different ways by six different people. Then you hit the edge case that breaks it outright.

We watched a client's team propose domain matching as the fix for exactly this kind of duplicate problem, and the counterexample showed up almost immediately: a city government and that same city's police department, two entirely separate organizations with their own leadership and their own budget, sharing one email domain. Match on domain alone and those two records collapse into one. That's not a rare fluke. Any organization with a shared mail system underneath separate operating units (a parent company and a subsidiary, or a government body and one of its agencies) produces the same collision.

This is the actual argument for weighting company name over domain, not domain over name: name is closer to the thing you're actually trying to identify, which is the organization, not the mail server it happens to sit behind. Domain is a useful secondary signal. It should not be the primary one.

Company name matching has its own problem: nobody types a company name the same way twice. State abbreviations get spelled out or dropped. Parenthetical clarifications get added by one rep and left off by the next. Exact-string comparison misses all of it, which is exactly the failure mode behind the second duplicate source above.

The fix one team built was a clean-name layer: strip the formatting noise, a state prefix or a parenthetical abbreviation, before comparing two names, rather than comparing the raw strings. Tested against roughly a hundred sample records pulled from the existing duplicate backlog, it produced a real, measurable jump in correct matches over exact-string comparison alone.

It also introduced a new problem the team hadn't planned for. Stripping state information to normalize the name meant the matcher could no longer tell two similarly named organizations in different states apart: a county office in one state clean-matched against a differently located department with a near-identical name. The fix for the false negative had created a false positive.

The resolution wasn't to abandon clean-name matching. It was to add state back in as a required secondary field, checked after the clean-name comparison rather than folded into it. Get the primary signal wrong and you miss real matches. Get the secondary signal wrong and you merge two things that were never the same thing. Check any matching-logic change against both failure directions before it ships: the one it was built to fix, and the one it might introduce.

Not every duplicate is a matching-logic problem. One case a client's team found was a raw domain string typed directly into the company-name field: someone had entered the website address where the organization's name was supposed to go. No amount of clean-name normalization or fuzzy comparison fixes that, because the input itself isn't a company name in any form the algorithm could parse.

The fix for this category lives upstream, not in the matcher: field-level validation at the point of entry, on both the client's intake form and the consulting team's ingestion side, that rejects a bare domain or URL where an organization name belongs. Some duplicate sources are a matching-logic problem. Some are a data-entry problem wearing a matching-logic costume, and treating the second kind like the first just makes the matching logic more complicated without fixing anything.

The hardest case in this whole category centers on a person, not a company record: someone with real, simultaneous ties to more than one organization (a consultant working two client accounts, an executive who sits on both a parent company's team and a subsidiary's). That doesn't fit the assumption most CRMs are built on, one contact, one company.

Ingestion pipelines built around that assumption tend to solve the mismatch by creating a separate person record for each organizational tie, rather than one contact with multiple nested relationships underneath it. That produces three records for one human being, and a follow-on question nobody wants to answer under time pressure: which of the three is the "primary" one for outreach and notifications.

This case doesn't resolve with better matching logic. It resolves with a data-model decision: does your CRM support a contact holding more than one company relationship natively, and if it doesn't, is the workaround a documented exception process rather than something each new instance gets solved from scratch. Flag it before the second or third instance shows up, not after routing has already gone sideways on a real deal.

Before wiring up matching logic for a new sync, or auditing the one you already have, walk through these five questions in order:

Which signal is primary (company name, not domain), and why does your logic weight it that way? What's the secondary signal that catches what the primary one misses on its own (state, region, or a unique external ID), and is it required or optional? When the matcher can't confidently confirm a match, does it create a new record by default, or hold the record for review? Silent creation is how false negatives turn into permanent duplicates. Is there field-level validation catching data-entry failures, like a domain typed where a name belongs, before they ever reach the matcher? Does your data model allow one contact to hold more than one legitimate company relationship, or does every multi-org case get solved manually?

Run a new fix through a real sample set in both directions before it ships. A matching-logic change that improves recall without being checked against precision will trade one duplicate problem for another, and you'll be back here in a few months with the same complaint about a different root cause.