One business ran two boards. When we checked them against each other, 712 of the 1,568 records on the smaller board were already on the bigger one.
That is about 45% of the smaller board (712 ÷ 1,568 = 45.4%). The other 856 were moved across into one board, and none were lost.
The number says a lot about how information was moving between the two boards. On its own, it does not prove that 712 prospects were lost, that 712 records should be deleted, or that every matching row was the same deal. The useful work starts by defining what was counted, then checking what each match really is.
A matching row is a candidate. A confirmed duplicate is a decision, made with the person, the property and the history in view.
What the number does, and does not, tell you
The figures answer one question: how many records on one board were already on the other, under the rules used in that review. They do not explain why the duplicates appeared, and they are not an error rate for every CRM.
In acquisition work, four different things often get squeezed into one row:
A person or company
The owner, buyer, partner or business.
A property
One specific parcel, ideally with its county and parcel number.
A deal
One conversation about one property with one person.
An activity
A call, message, review or task that happened at a set time.
One owner can have several parcels. One parcel can have several contacts or old deals. Two boards can also show the same real-world record at different stages of work. A duplicate rule that ignores those links can merge records that should stay separate.
Why duplicates build up across boards
Duplicates are usually created by ordinary work, not carelessness. Someone adds a record because they cannot find the first one. An import does not carry a stable ID. One board tracks the owner while another tracks the parcel. Names and addresses are typed differently. A record gets copied into a new workflow instead of linked.
Treat these as things to test, not as the confirmed cause. Before blaming anything, compare when each record was created, where it came from, who owned it, what each board was for, and the import history.
A careful duplicate review in seven steps
01
Freeze a snapshot
Export both boards with record IDs, key fields, source, owner, status and last-updated date. Keep one untouched copy so the review can be repeated.
02
Decide what one row means
A person, a company, a parcel, a deal or an activity. Do not compare different kinds of record as if they were the same thing.
03
Clean the fields you will compare
In a working copy, make phone formats, email case, spacing, address abbreviations and parcel numbers consistent. Keep the original values so you can show what changed.
04
Match in tiers
Start with strong identifiers: a CRM record ID, a verified email or phone, or a parcel number with its county and state. Use name and address similarity only to find candidates, never as an automatic merge.
05
Review each candidate in context
Compare the type of record, linked properties, call history, status, source, owner and dates. A person with two parcels is not a duplicate parcel. A shared mailing address is not enough to merge two people.
06
Pick the record that stays, and keep the trail
Decide which record survives, which values it keeps, which calls and deals must be re-linked, and how someone can still find the old record IDs later.
07
Reconcile the counts before touching live data
Report confirmed duplicates separately from uncertain matches, rejected matches and distinct records. Have one responsible person approve any merge before it runs.
Every CRM handles this slightly differently. HubSpot, for example, matches some imports automatically and others by record ID or a unique field, and its duplicate tool asks you to review properties and linked records before merging. Salesforce uses matching rules you configure. The rule underneath is the same everywhere: confirm the match and keep the right links before any bulk change.
Stop the same mess coming back
A clean-up only lasts if the way records come in changes too. Give every important record a clear identity rule. For a person, that is a stable CRM ID plus carefully chosen contact fields. For a parcel, the parcel number with its county and state. Give each deal its own ID, because one owner or parcel can appear in more than one deal.
- Search for an existing record before creating a new one.
- Carry the source and the original record ID through every transfer.
- Decide which board owns each field, and which system has the final say.
- Use duplicate warnings to surface candidates, with a person deciding the unclear ones.
- Track confirmed, rejected and unresolved matches separately.
- Spot-check new records regularly to see whether the same pattern is coming back.
Most importantly, make the right path easier than the workaround. If people cannot find the record, do not know which board owns it, or cannot link a new task to the existing deal, they will create a new one. Better matching helps. Clear ownership and a workflow people can actually use finish the job.
Before you merge anything, write this down
The date of the review, what was in scope, what one row means, how you defined a duplicate, how matches were made, how many were confirmed versus uncertain, and what action was taken. If you report a percentage, say exactly what it is a percentage of.
The lesson from the 712 of 1,568 review is not that everything should be merged. It is that record identity and board ownership have to be designed across boards. Once that is clear, the team can decide which records to link, merge, keep separate or investigate.
Sources and further reading
- HubSpot: Review and manage duplicate records — reviewing candidates, chosen properties and linked records before a merge.
- HubSpot: Deduplicate records — record IDs and unique properties for matching imports.
- Salesforce Help: Matching rules — how configurable rules flag potential duplicates.
Counts come from an anonymised AS Ventures review. No client names, contact details or property addresses are published.