One Person, Three Visits, Two CRM Records: Fixing Duplicate Leads

One person visits your website three times and ends up in the CRM twice. The sales report now shows two leads, two owners start follow-up and the campaign report gives different answers depending on which record you open.

The problem is not solved by keeping whichever record was created last. You need to establish whether the records describe the same person, preserve the history that matters and decide how future activity should attach.

Start with one confirmed duplicate. Use it to build a process your team can review before applying the same rule across the database.

Separate the objects before merging anything

A visit, a person, a company and a contact record are different things.

A person can visit several times. A company can have several people researching the same purchase. A CRM can hold more than one record for a person because of imports, forms or changes in how the relationship was recorded.

Decide which object is duplicated. Two colleagues using the same company website are not the same person. Two visits from one browser are not two contacts. Two records sharing a company name are not enough evidence to merge personal histories.

The OSPRY overview is a useful starting point for considering the distinction between visitor activity and a known relationship. Keep that distinction in the actual fields and decisions your team uses.

Build a small, explicit evidence rule

Write down the evidence that makes a pair safe to review as a likely duplicate. Use the identifiers and relationship records your business can legitimately inspect.

An exact match on a verified address may be stronger evidence than a similar name. Even then, check whether the address belongs to a shared inbox, whether someone changed roles and whether the records contain contradictory information.

Do not use a company domain as a universal person-matching rule. A business may have many contacts. A shared phone number can also belong to a reception desk or team.

Keep uncertain pairs in a review queue. A wrong merge can combine conversations, permissions and ownership that should remain separate. A queue with a reason is more useful than a rule that quietly resolves every ambiguity.

Follow one fictional contact through the history

Consider a made-up example.

Jamie visits a service page from a search campaign, returns directly two days later and then submits a contact form after opening an email the business sent during an existing relationship.

An earlier import already created a CRM record for Jamie. The form creates another record. The team confirms, through its own appropriate records, that both refer to the same person.

The website contains three observed visits. The CRM contains two contact records. After a correct reconciliation, the business should be able to describe one confirmed person and the relevant history without pretending that every visit created a new lead.

The campaign evidence still matters. The first known visit, the later direct return and the email touch should remain distinct observations. Resolving the duplicate is not permission to overwrite the journey with one convenient source label.

Choose a surviving record for a reason

Before consolidating anything, check which record is connected to active work. Look for opportunities, support conversations, commitments, notes, account relationships and assigned ownership.

Choose the surviving record using a documented rule. It might be the record already linked to an active opportunity or the one your team has confirmed as the current relationship record. The rule should be understandable to the next person who reviews it.

Record the identifiers of the affected records and the reason for the decision. Preserve enough information to investigate or reverse the change through the tools and recovery process your business supports.

Do not treat deletion as the definition of successful deduplication. Success means the right person has a coherent record and the systems feeding it know where to send future activity.

Preserve source history as a sequence

Keep the first known source separate from the most recent source and from the source credited by a reporting rule. These fields answer different questions.

For Jamie, the search campaign may be the first observed arrival. The email may be the final recorded touch before the form. A reporting model may assign credit according to a different rule.

A merge that replaces the search campaign with the email source can make the earlier campaign disappear from the relationship. Keeping only the oldest source can hide the later touch that helped the team understand the enquiry.

Preserve timestamps and provenance where the system supports them. When a field conflicts, record what you resolved and why. Avoid combining incompatible values into a text field that no report can interpret later.

Carry contact choices and stop conditions forward

Review the communication preferences and restrictions on both records before allowing follow-up to continue.

If one record contains an unsubscribe or a wrong-contact report, do not discard it because the other record looks newer. Resolve the conflict according to the applicable rules your business has defined, and make the resulting state visible to the owner.

Keep the purpose of a preference clear. A choice about one communication or collection activity does not automatically describe every other use of the record.

Your consent workflow belongs in the deduplication discussion because combining records can also combine the context around their creation. The surviving record needs an accurate history, not the most permissive collection of fields.

Stop the duplicate at its source

After resolving the example, inspect the route that created the second record. A website form, import, sales entry or connected system may each follow a different matching process.

Test that route with an appropriate internal record. Confirm whether a repeat enquiry updates an existing relationship or creates another contact. Check what happens when a person changes their address or supplies incomplete details.

Review the integrations feeding your CRM with that specific path in mind. A correction in the CRM will have a short life if the next import recreates the same duplicate.

Assign ownership of the matching rule. Someone needs to know where it is configured, what it assumes and how exceptions are handled. Keep the test case so future changes can be checked against it.

Reconcile reporting without rewriting the past silently

Decide how corrected records affect your reports. A current count of distinct people and an earlier snapshot of created CRM records describe different things.

If a monthly report originally counted two new records for Jamie, identify whether the report will be restated or accompanied by a correction. Keep the original definition and the adjustment understandable.

For a campaign review, use a clear unit: new distinct accepted contacts, record creations or something else your team has agreed. Exclude repeat activity only according to that definition.

Do not remove a real second person because their activity resembles an existing contact. Deduplication should improve the count's meaning, not simply make it smaller.

Review a handful of cases before scaling

For each reviewed pair, record the evidence, decision, surviving record, retained history, preference handling and originating route. Include cases you deliberately did not merge.

Ask sales to inspect the result. Can the owner understand what the person asked, what was promised and which action is next? Can operations trace how future submissions will arrive?

Explore how OSPRY connects visitor context to a practical workflow with that coherent record as the destination. Three visits can be useful history. Two CRM records can be a repairable problem. The goal is one accurate relationship without losing the evidence that explains it.