Problem
One customer may appear under several names
“I thought they were already a customer.”
The sales report shows a newly created account. The person reviewing it recognizes the name, but it looks slightly different from the one they remember.
Consider a fictional business with these entries in its customer system:
Three entries in the fictional customer system
- Cedar Lane Services
- Cedar Lane Svc.
- Cedar Lane Services LLC
What do these records represent?
One came from a website inquiry. Another was created by someone preparing a quote. The third uses the name provided for billing. Each record contains useful information. None shows the whole relationship.
Are these three customers, three ways of writing the same name, or separate accounts that should remain distinct? The person preparing the report now has another job: work out what the records actually represent.
Good data management gives the business a consistent way to answer that question. It helps people recognize an existing customer, understand their history, and explain the numbers in a report.
Examples
Decide what one customer record represents
Before looking for duplicates, agree what belongs in a customer record. Does it represent a company, a branch, a billing account, or an individual contact? Those can be related without being interchangeable. In the fictional example, Cedar Lane might have two locations with separate service arrangements. The business may need a record for each location, linked to the same company. Combining those records could hide information employees need to do their work.
Write down the distinction in plain language. Give employees an example of when to use an existing record and when a separate record is appropriate. Then check what the report counts. A count of newly created records does not necessarily show newly acquired customers.
The Government Data Quality Hub explains that records can be duplicates even when some fields differ. The important question is whether they refer to the same entity. Duplicate customer records can inflate customer counts or split activity across accounts. They do not automatically double revenue. That depends on how transactions are recorded and how the report combines them.
Solutions
Use evidence to identify possible duplicates
A similar name is a useful starting point. It needs supporting information. Compare details such as the account’s history, verified company information, location, and known trading names. Use a stable customer identifier once the business has established which customer the record represents. Keep that identifier distinct from the display name. A spelling correction or trading-name change should not make an existing customer look new.
Identifiers also need context. Customer 104 in one system may have no connection to customer 104 in another. Record the relationship between those systems’ identifiers after confirming the match. Be careful with shared details. Two companies can use the same office address. Several contacts can share a general email address. A familiar phone number may belong to a central switchboard.
IBM’s record-matching guidance distinguishes uncertain matches from matches and nonmatches. It also explains the tradeoff between finding more matches and making incorrect matches. For Cedar Lane, a reviewer might confirm that two entries are spelling variations while the third represents a separate billing account. Record that conclusion and the evidence behind it. An unresolved match can stay unresolved until someone obtains the missing information.
Review what a merge would change
“These look like duplicates” is not enough preparation to combine them.
Someone needs to decide which details are current and what happens to the information attached to each record.
Before approving a merge, check:
Check identity, details, history, relationships, and recovery
- Identity: Have these records been confirmed as the same customer at the same level?
- Details: Which name, address, and contact information should remain?
- History: What happens to quotes, invoices, notes, and open requests?
- Relationships: Will branches, billing accounts, and contacts stay correctly connected?
- Recovery: What can be restored if the decision proves wrong?
Check the system and verify the result
Salesforce’s guidance for its Nonprofit Success Pack illustrates why this matters: users select the retained record and field values, and the contact merge is irreversible.
Check the behavior of the system your business uses before changing records. Do not assume every product offers an undo button or preserves every relationship in the same way. A permitted export or backup may help with recovery, but it needs to contain the information required to restore the affected records and relationships.
Keep a record of who approved the change, what was combined, and why. Afterwards, check that employees can still find the customer’s history and that reports reflect the intended change.
Stop new duplicates at the point of entry
Cleaning up the existing records is only part of the work. In the fictional business, employees searched by the exact name they had received. When nothing appeared, they created another account. The system held no alternate names to help them recognize Cedar Lane.
The business could make confirmed trading names and abbreviations searchable. A new-account form could show likely existing records before someone finishes creating another one. Give employees a clear route when a suggested match is wrong or uncertain. They should be able to explain why a separate record is needed or ask for a review. Look at imports too. A list containing unfamiliar names may still include existing customers.
The Government Data Quality Framework recommends addressing quality problems at their source. Applied here, that means examining how duplicate records enter the system and improving that step. Check the duplicate-management features already available in the software. Start with a small set of known examples and see whether the rules find the right records without repeatedly flagging legitimate separate accounts.
Let automation prepare the comparison
Automation could help gather possible duplicates into a review list, display matching and conflicting details, and link each suggestion to its source records.
For Cedar Lane, the reviewer could see all three entries together, including their identifiers, account types, and relevant history. The reason for each suggested match should be visible.
The reviewer then records whether the entries belong together, should remain separate, or need more information. A workflow could route the approved next step to the authorized person and keep the decision attached to the records. Keep the final customer-identity and merge decisions with people responsible for the data.
Start with one confusing customer group
Start with one customer group that employees already find confusing. Review what the records represent before changing anything.
Then check whether people can find the right account, whether the customer count makes sense, and whether new duplicates keep appearing. Removing rows alone does not establish that the data is better.
How Zoevin helps
Make the comparison and review easier
At Zoevin, I build scoped automations in a business’s own environment and hand them over on an agreed date.
Bring one example where a customer’s history is spread across several records. We can look at how to make the comparison and review easier for the people who need to resolve it.
- Examine one customer group whose history is spread across records.
- Identify comparison and review preparation that automation could support.
Zoevin has no delivered automation projects yet. Discovery names the seam. If I build, I hand it over on a written date. You get the workflow, the logins, and the write-up. I don't stay on to run it. You buy the software.
Evidence
Sources
Primary reporting first. Open the sources yourself rather than taking this account alone.
primary source
Government Data Quality Hub — Meet the data quality dimensionsJune 24, 2021 guidance explaining that duplicate records can contain different field values while referring to the same entity. Cedar Lane and its entries are fictional teaching examples, not client work or measured reporting outcomes.
primary source
IBM InfoSphere Information Server 11.5 — Cutoff valuesProduct documentation distinguishing matches, nonmatches, uncertain pairs, and incorrect classifications. Suggested customer-review practices are editorial applications of these concepts, not an IBM deployment or a recommendation to buy its software.
primary source
Salesforce Trailhead — Manage Duplicate Contacts and AccountsNonprofit Success Pack training describes selection of the retained record and field values and an irreversible contact merge. This is a bounded product example; the article does not claim that all products merge or recover records in the same way.
primary source
UK Government — The Government Data Quality FrameworkGuidance on addressing data-quality issues at their source. Searchable aliases, review lists, and entry checks are illustrative business practices, not a legal obligation, promised savings, or autonomous customer-identity decisions.