Why doesn't matching on Website solve the problem?
Website is useful. We use it. But we would not call two Accounts duplicates just because they have exactly the same Website.
A company with 50 branch offices may use the same Website on all 50 Account records. The same thing happens with hotel chains, retailers, school systems, hospitals and other multi-location organizations. Those records may also have very similar Account Names.
If your organization needs those locations represented separately, the shared Website tells us the Accounts are related. It does not tell us they are duplicates. That's an important distinction.
How do you tell an actual duplicate from a separate location?
For Account deduplication, Salesbroom generally starts by finding Account Names that may represent the same company. We don't require the names to be exact. Different spelling, punctuation, abbreviations and company-name suffixes can make two records look different even when they represent the same Account.
Account Name gives us the candidates. Then we look at the rest of the data.
Depending on what is available, that can include:
- Street Address
- City
- State
- ZIP Code
- Phone
- Website or domain
- Other customer-specific fields that help distinguish one Account from another
No single field has to make the whole decision. We look at the records together and ask: Do these records actually represent the same Account, or are they legitimate separate locations of the same larger organization?
That's what the matching rules need to answer.
Here's a simple branch-office example
Imagine these two Account records:
The Account Name is exactly the same. The Website is exactly the same. But the Street Addresses are different.
If your rules say separate branch locations should remain separate Accounts, the different Street Addresses give us the information we need to keep these records out of the duplicate group. They belong in No — not a duplicate under those rules.
Now compare these two:
The Account Names aren't exact, and the Street Addresses aren't formatted exactly the same. But they're pointing to the same location, and the Website matches too.
That's a very different result. These records deserve to be evaluated as potential duplicates.
This is why exact matching alone isn't enough. The same Website does not always mean duplicate, and records that don't exactly match can still represent the same Account.
Don't pollute the results
Finding potential matches isn't very useful if the results are full of false positives.
If a dedupe tool gives you thousands of weak or questionable matches, it hasn't really solved the problem. It has moved the problem onto your team. Somebody still has to sort through all of those records and figure out which matches are real.
The bigger problem is when weak matches get mixed in with strong ones. Now you don't know which duplicate groups you can trust.
We don't think that's good data work. The goal isn't to produce the largest possible number of duplicate groups. The goal is to produce duplicate groups you can trust.
Why does Salesbroom use Yes, Maybe and No?
Because the real world doesn't always give you enough information to make a clean Yes-or-No decision.
Salesbroom evaluates records against the rules we define with you and separates the results into three practical outcomes.
Yes
Yes means we have enough evidence under the rules to call the record a duplicate. Yes should mean Yes. If we put a record in the Yes group, the evidence should support that decision.
Maybe
Maybe means there is a legitimate reason to look at the record again, but not enough evidence to call it Yes. Maybe is not a dumping ground for weak matches or obvious false positives. A good Maybe really deserves another look. Sometimes the data is incomplete. Sometimes two records are unusually similar. Sometimes we need another rule from you before we can make the call.
No
No means the record does not meet the duplicate rules. No means No under the rules we're using. It doesn't mean some duplicate could never exist outside those rules. It means the record did not meet the agreed rules strongly enough to belong in Yes or Maybe.
This separation matters because uncertainty does not get promoted to Yes. It gets its own place: Maybe.
Why are we so careful about false positives?
Because the cost of getting the answer wrong is not equal in both directions.
If we miss a duplicate, that duplicate can still be found and dealt with later. If we incorrectly call two legitimate Accounts duplicates, somebody may merge them. That can create ownership problems, territory problems, lost Account structure, confused activity histories and a lot of cleanup work.
That's why, when there is real doubt, Salesbroom fails shut. We would rather leave a questionable duplicate out than put two Accounts together that should never be merged.
Precision isn't about being timid. It's about understanding which kind of mistake costs the customer more.
Your definition of a duplicate matters
There isn't one universal rule that says every branch office should stay separate or every related company should be grouped together. It depends on how your organization uses its Accounts.
One company may want every branch represented as its own Account. Another may want one parent Account with separate child Accounts underneath it. A hotel company may need every property kept separate. A school system may need each school treated independently. A franchise business may need to distinguish the franchisor from each franchise location.
Those aren't unusual exceptions that we deal with after the matching is done. They're part of defining the job correctly before we start.
That's why your Salesbroom project manager talks through the rules with you first. We need to understand what a duplicate actually means in your data before we can reliably find one.
What should I look for in an Account dedupe tool or service?
If separate locations matter in your CRM, you need something that can do more than exact-match Website or domain.
A useful Account dedupe process should be able to find candidates using fuzzy Account Name matching, compare additional fields such as address and phone, recognize that related Accounts are not necessarily duplicate Accounts, and apply rules that reflect how your company actually uses its data.
It should also be able to group potential duplicates without automatically merging them and distinguish high-confidence duplicates from records that genuinely need another look.
Most importantly, ask what happens when the system isn't sure.
If the answer is essentially, “We'll show you everything that might be a duplicate and let you sort it out,” you may end up with a lot of noise rather than useful results.
How does Salesbroom handle duplicate Accounts?
We start with your data and your rules.
Your Salesbroom project manager talks through how your organization uses Accounts and what should or should not be considered a duplicate. Branch offices may need to stay separate. Regional offices may need to stay separate. Hotels may need to stay separate by property. Parent companies and subsidiaries may require completely different treatment.
Once we understand the rules, we apply them consistently across the dataset. We use Account Name to identify candidates and the other available fields to help determine whether those records really represent the same Account.
The output groups records into Yes, Maybe and No so you can see which Accounts belong together, which ones genuinely deserve another look and which ones don't meet the rules.
The first job is to get the grouping right.
Good data is trusted data
A duplicate group is useful only if you trust it. You should be able to look at a Salesbroom Yes group and believe the records belong together. You should be able to look at a Maybe and understand why it deserves another look. And you shouldn't have to dig through piles of obvious non-duplicates because a tool wanted to show you more results.
That is what we mean by precision.
Give me results I can trust.
That's the deliverable.