One buyer, three enquiries, three salespeople

A man is looking for a flat. On Monday he fills the form on a property portal. On Wednesday he passes the site and rings the number on the hoarding. On Sunday his broker brings him for a visit.

Three records. Three owners. Three people who will ring him this week with the same pitch, and at least two of whom will believe they are talking to a fresh enquiry.

The buyer's experience of your organisation is now settled, and it is that the left hand does not know what the right is doing. If he books, there is a commission argument waiting. If he does not, three executives will each report a lost lead, and your enquiry count for the month is wrong by two.

Why exact matching fails in this market#

Every system ships with duplicate detection that compares two phone numbers for equality. It catches almost nothing, for reasons that are entirely ordinary.

The country code. The portal delivers the number with a code prefixed. The tele-caller types the ten digits she was told. The broker's registration email has it written a third way. Three strings, one phone.

Spaces, hyphens and brackets. A number typed with a space in the middle, or split with a hyphen because that is how the buyer said it, is a different string to a computer and the same number to a person.

The spouse's number. He enquires on his own number and his wife walks in and gives hers. Both are correct contact numbers for one household and one purchase decision.

Two spellings of one name. Transliteration from a regional script varies, initials expand or contract, and the caller writes what she heard through a call that was breaking up.

A shared family email address. One address serves the father, the son and the business. Matching on it will merge people who are genuinely different, which is a worse error than missing a duplicate.

The portal's proxy number. Some sources deliver a masked line that routes to the buyer rather than his actual number. Two enquiries from the same person through two portals arrive as two different numbers, neither of which is his.

Notice that half of these are cases where naive matching finds nothing, and half are cases where it would confidently merge two people who are not the same. Both errors are expensive and the second is harder to undo.

What a duplicate rule should do#

Normalise before comparing. Strip everything that is not a digit, handle the country code the same way on every path in, and store one canonical form. This has to happen at the point of capture and on every route — portal feed, bulk import, walk-in form, the app the caller uses at a kiosk. A normaliser applied on three routes out of four produces duplicates that look impossible.

Treat the phone as the spine and everything else as a hint. A matching number is strong evidence. A matching name is a reason to look. A matching email is barely anything. That ordering is the practical half of what a lead record should hold, and it is why alternate numbers deserve a real field rather than a line in a remarks box — they are the ones that catch the household case.

Propose a merge; do not perform one. This is the important one. The system should say this enquiry looks like that one, here are both, decide — and then wait for a person. Automatic merging on a fuzzy match will eventually combine two genuine buyers, and the damage is silent: one buyer stops receiving calls, one history becomes nonsense, and nobody finds out until somebody looks for a record that no longer exists under its own name. The general form of this rule is the machine proposes, and duplicate detection is the case where it earns its keep most obviously.

Never destroy the losing record's history. A merge should join two histories, not overwrite one with the other. The dates, the owners, the notes and the source of the second enquiry all survive.

The second enquiry is information#

This is the part most implementations miss. A duplicate is treated as a mistake to be cleaned up, and cleaning it up destroys the fact.

That the same man enquired three times in one week, through three channels, is the strongest intent signal in the file. It is worth more than any rating out of five. A merged record that shows three touches in six days, from three sources, tells the executive exactly how to open the call.

There is also a marketing fact in there. The portal, the hoarding and the broker each produced an enquiry from this buyer. If the merge overwrites source with the most recent one, the hoarding and the portal have both silently lost credit for a booking they helped produce, and next season's budget is set from that damaged number. Keep every touch with its own date and source, and let the current values sit on top of a history that is added to rather than rewritten — append-only records is the same discipline applied to a different desk.

A merge is an ownership decision#

Two records had two owners. One merged record has one. Somebody's name has been removed from a live enquiry, and if that enquiry books, somebody's earnings changed while a screen was being tidied.

This means a merge cannot be a housekeeping task handed to whoever has time on a Friday. It needs the same authority a reassignment needs, the same written rule about which owner prevails — first touch, most recent activity, the one who has actually met the buyer — and the same record of who decided and when. All of that is who owns the lead, and a duplicate policy written without settling it will be quietly ignored by the executives it costs.

There is a related trap. If the office knows that merging removes an owner, duplicates stop being reported. Everyone can see the second record and nobody raises it, because raising it might cost a colleague a case, or cost them one. A merge rule that names the losing owner and pays nothing to the finder is a rule that guarantees nobody looks.

The short version#

The same buyer arrives through several channels in the same week, and exact matching on a phone number will not catch it.

Normalise numbers at every point of capture, treat the phone as the spine and the name and email as hints, and propose merges for a person to confirm rather than performing them automatically.

Keep both histories, keep every source and date, and treat the merge itself as a change of ownership requiring the same authority and the same record as any other.