Resolve Duplicate Property Records Without Merging the Wrong Information

Duplicate property records create a practical risk for an estate agency. Two CRM entries may represent the same house but contain different prices, photographs, seller instructions or viewing histories. They can arise after a branch transfer, a portal import, a change of address format or a colleague creating a new record without finding the original. Deleting one entry may look efficient, but doing so before identifying the correct source can erase useful evidence or attach a buyer's message to the wrong instruction. A controlled duplicate-record merge preserves identity and history while removing the confusion that caused the duplicate.

The purpose is not to make every similar-looking listing disappear. A converted building may contain distinct flats with similar addresses; a development may have several units sharing photographs; and the same seller may instruct an agency on more than one property. A valid merge requires evidence that the records describe the same intended entity and business instruction. Relevant consumer-protection duties encourage accuracy in outward-facing information, while data-protection principles matter where personal details are duplicated or incorrect. Neither source establishes a universal automated threshold at which two records should be combined.

Identify what each record is meant to represent

A property database may contain separate objects for an address, a physical home, a marketing instruction and a transaction. Two entries at the same address are not necessarily duplicates if one represents a former instruction and the other a new agreement, or if they relate to distinct units. Before choosing to merge, define the object that should have a single identity in the particular system. Document the expected relationship between property, seller, branch and marketing history.

Use stable references and relevant evidence: address and unit identification, original instruction, internal property number, seller authority and any appropriate authoritative property information. Do not rely only on name matching. Addresses can be abbreviated, re-numbered or written differently across systems. A system claiming that two entries are 98 per cent similar has not proved that they represent the same thing.

Where certainty is lacking, place the pair into an investigation queue rather than combining them. Record the reason for suspicion and who is authorised to make the decision. A false merge can be more damaging than a temporary duplicate because it mixes records that should remain separate.

Find the current controlling instruction and record owner

Each candidate record may contain instructions that are accurate for different periods. An earlier price could be a valid historical fact, even though a later approved price controls today's marketing. Identify the current instruction, who authorised it, its effective date and which record is used for public publication. A date of last edit does not guarantee authority: somebody may have opened an old entry recently without changing its status.

Compare the seller's actual instructions, branch ownership, active offers, diary and key records. One duplicate may contain an unresolved buyer question missing from the other. Another may have a more recent photograph but outdated marketing terms. Select a canonical record only after determining which attributes are authoritative and which histories must be retained.

Where the seller identity or legal interest differs, seek appropriate clarification before merging. An agency database is not a reliable adjudicator of disputed ownership. Keep business decisions and legal interpretations with authorised people and relevant records.

Classify every field before moving information

Do not perform an indiscriminate overwrite. Divide fields into stable identity data, current approved marketing data, historically valid events, personal information, operational permissions and technical identifiers. Each class needs a different rule. Preserve the most recent approved asking price, but retain previous prices as dated events; preserve buyer offers with their original timestamps; do not copy an unverified parking claim into an approved description simply because it appears in the other record.

Images also require careful linking. A photograph may belong to the same physical home but have rights restricted to a particular marketing use. Check property identity, capture date, licence and approval before associating it with the surviving record. A floor plan may represent the building before alteration; label it accordingly rather than substituting it for current evidence.

Keep source provenance. Every moved field should retain its originating record ID, relevant timestamp and confirmation status where practical. If the merged dataset cannot show where a consequential value came from, the merge has made the information less trustworthy.

Protect buyer, seller and occupier histories

Customer interactions can be duplicated or accidentally reassigned during imports. An enquiry may concern a particular flat, not the entire building. A buyer's offer relates to a specific instruction and set of terms. Review these relationships carefully before moving them. A single buyer might have contacted the agency more than once; that is not proof their messages belong to a single property event.

Personal data accuracy matters. The ICO explains that organisations should take reasonable steps to ensure personal data are accurate and, where relevant, kept up to date. This principle does not justify collapsing different people or relationships merely because names match. Preserve context and provide a correction route if an incorrect link is identified. Minimise the personal information exposed to employees who do not need it.

Review permissions. A branch that previously handled an instruction may not require continuing access to all correspondence after a transfer. Merging records must not widen visibility of financial documents, occupier details or security-sensitive access instructions by default. Enforce access through the underlying application rather than relying on an AI assistant's text instructions.

Establish a canonical identity without deleting evidence

Choose the surviving canonical ID using documented criteria appropriate to the CRM. Preserve the losing record's identifier as an alias or redirect in a controlled mapping so existing integrations and audit records can still be reconciled. Do not silently reassign an old event to a new date or overwrite the original message. Historical references may appear in portal feeds, customer communications or internal reports; they need a predictable transition.

Keep an audit record of the decision: records compared, reason they were judged identical, approvals, fields selected, events retained and effective merge date. Where the business has an approved retention policy, archived source records should follow it. A process that erases important history solely to reduce the visible row count undermines later accountability.

Separately identify records that only appear duplicated because of system design. A property object and an active instruction object may share address details legitimately. Combining them would be a structural data error rather than a quality improvement. The team should understand its own CRM's data model before purchasing automation.

Reconcile publishing, enquiries and operational dependencies

After a merge, the agency may still have two live portal feeds or two contact forms routing to different branches. Test the customer-facing listing and enquiry destination. Remove or redirect obsolete public marketing as appropriate, preserving valid current particulars. A successful database merge is not proof that a duplicate advertisement has disappeared from external platforms.

Check viewing diaries and related communications. Two copies of the same booking should not produce contradictory reminders; equally, two genuinely distinct visits should not be collapsed into one. Key custody remains a separate physical record. A CRM merge does not establish that a key is returned or that access arrangements were changed with permission.

Review reports and analytics. Historical enquiry counts can be distorted if the business adds the totals from two records without deduplicating events, or if it destroys one record's activity. Where reporting definitions change, document the before-and-after method so vendor updates and operational analysis do not imply false trends.

Test a proposed merge before committing it

Run the process on representative copies in a controlled environment. Include exact duplicates, similar flats at one address, a withdrawn historical instruction, conflicting asking prices, photographs from different periods and a conditional offer attached to the older record. A safe tool should identify uncertain relationships and allow staff to decline a merge. The objective is correct identity resolution, not maximum record reduction.

Provide a preview of surviving attributes and linked events. Ask the reviewer to approve material conflicts and retain a recovery path. Test whether connected systems can still find the canonical property and whether permissions remain appropriate. A rollback plan may need more than restoring a database row if public feeds have already changed. Coordinate the underlying records and downstream destinations.

AI-assisted similarity detection can help flag candidate duplicates, but does not verify the legal or business identity of an instruction. Staff should not rely on a model's confident explanation when the source documents contradict it. When the system cannot decide safely, leaving the records separate pending investigation is a legitimate outcome.

Measure accuracy, traceability and long-term maintenance

Useful indicators include confirmed false merges, duplicate advertisements, misrouted enquiries, orphaned events, time spent tracing provenance and unresolved conflicts after migration. Count how many candidate pairs were reviewed and how many were correctly resolved, not just the number of records eliminated. A business that halves its database while losing offer history has not improved data quality.

For illustration, suppose a branch spends thirty-six staff hours monthly investigating suspected duplicates. A controlled detection and merge tool reduces initial searches by fifteen hours but requires seven hours for verification and reconciliation, leaving eight potential hours before licences, recovery planning and training. These numbers are hypothetical, not reported benefits. The cost of a mistaken offer association or misleading property listing may greatly exceed routine time savings.

Make the process repeatable. New imports and branch changes can create fresh duplicates, so establish clear property-ID rules, controlled creation permissions and periodic review. A simple prompt warning that a similar property exists may prevent more problems than a sophisticated clean-up project. The enduring result should be one authoritative current identity with traceable evidence, not a database whose neat appearance hides uncertainty.

Research sources: ICO accuracy principle (UK personal-data records and correction obligations, not a prescribed property merge algorithm); UK Government material-information consultation and response (truthful property disclosures); The Property Ombudsman residential agency Codes (professional context). The identity and merge design are original editorial recommendations rather than a claimed industry standard.