Duplicate Customers (what is the best practice to prevent when uploading large lists)?

We go to a few trade shows per year and we collect leads from these shows. We scan the customer badges and we get the data that each individual typed into their trade show registration. Unfortunately, the trade shows do not utilize an address validation, so we will get multiple entries that are slightly different.

For example, one contact can enter their address with Boulevard, Boul, Boul., Blvd, or Blvd.
Another example is with the Company name as Incorporated can be fully spelled out, abbreviated as Inc or Inc., or completely dropped off the company name.
Another example is within the street address is using a direction like 125 South Blue Bell Road, could also be 125 S Blue Bell Road, 125 S. Blue Bell Road, and Road could be Rd or Rd. or mistakenly enter as Street or Avenue or any abbreviation with or without punctuation.

Contact validation is much easier by using an email address, but Customer validation is much more difficult. Some customer names are very similar, some customers are located on the same street, some customers have the same numerical address, so trying to get a near match may yield too many false positives.

From what I remember, Epicor does NOT have an option to Merge customers (that were accidentally created as a duplicate customer), so cleaning up the customer data BEFORE it will be DMT pushed into Epicor is very important.

What are others doing to prevent entering duplicate customers from a long list of trade show leads (or any other list of potential customers)?

Compare the email domain (not the whole address). This works reasonably well both for individual contacts and at the company level.

1 Like

Please note that we already have an “Epicor Idea” around the concept of merging Customer IDs within the system. This idea has lots of comments and suggestions and Votes (148 votes), making it the 8th most popular idea in Kinetic, and the TOP idea in Sales Management. We do take this seriously, but it is also a fairly large idea to implement. the soonest that it could be implemented (:safe_harbor:) would be 2024.2 2025.1 (EDIT: Note that after further review, this change is a very huge change, and we are still trying to figure out some of the challenges), Your Votes Count!
https://epicor-manufacturing.ideas.aha.io/ideas/ERP-I-740

3 Likes

This is also where I’ve started from in the past. Email domain is usually the most effective way to reduce comparison scope. Postal code, city, and region also add useful perspectives to pare down comparison scopes. Sometimes people move or change names, so it’s never perfect but such is life.

Some degree of manual clean up is inevitable for feral data that hasn’t gone through a control template, unless it’s worth the development and friction of making new contacts do data entry through an address validation template.

1 Like