Dupe Checking
Dupe checking, or duplicate checking, is the process of identifying and managing duplicate vendor leads within a database or CRM system. It's crucial for maintaining data accuracy, optimizing sales efforts, and preventing wasted resources.
Here's how it works:
Identification:
The system compares incoming vendor leads against existing records.
TLD only uses the first phone number primarily for Dupe Checking
The Dialer can check against all three phone numbers
Review and Resolution:
There are several different types of dupe checks performed within TLDCRM.
Allow Dupes - this mean that even if the lead exists somewhere in the TLD account a new lead will be added and created under this Vendor Source
Reject if in this Vendor - If the lead already exists for that vendor source a new lead will not be created. Instead the existing Lead will open, regardless of where it originally came from
Reject if in the Account - If the lead exists anywhere in the account the lead would not be created and the existing lead will not open
Benefits of Dupe Checking for Vendor Leads:
Cleaner Data: Ensures the accuracy and integrity of your vendor data, leading to better decision-making and reporting.
Efficient Sales Operations: Prevents duplicate outreach efforts, saving time and resources, and reducing the risk of annoying potential customers
Improved Customer Experience: Avoids sending multiple communications to the same customer, creating a more professional and seamless experience.
Enhanced Analytics: Accurate data leads to better insights and more informed business decisions.
Â
It is typically encouraged using "Reject if in this Account" because otherwise the system will create duplicates. This way there is 1 single lead for each phone number, and it is possible to see ALL the historical information relating to that lead over time. Everything is in one place.
There are some instances where "Reject if in this Vendor" is needed/desired, so that option is also available.
Allowing all duplicates is VERY VERY BAD! This can cause serious damage to the integrity of the account. The problem with allowing all duplicates is there is absolutely NO historical data EVER, and ALL of the data tracking is worthless because it may appear that 57 leads have arrived from a vendor, when in reality there was potentially 1 lead from that vendor 57 times. It's a terribly slippery slope.
We also have an "Reject in this ____ by Criteria" and the "Criteria" is a day value for how old the lead is (based on date_created).
When a dupe is rejected, there's an option to take the data from the rejected lead post, and use it to update the existing lead in the system with the new data.
When a vendor source is set to "Reject if in this Account" and "Update on Dupe" and a duplicate is posted in, this can "steal" the lead from one vendor source into another.
There's two options related to this:
"Don't allow any dupe updates to steal my leads" (this is called Protect this Vendor's ID from Dupe Updates (From other Vendors))
"Don't steal any leads when doing dupe updates" (this is called Omit Vendor ID on Dupe Updates (If different Vendor))
It is also possible to add a whitelist or a blacklist of IP addresses of where you want to allow dupe updates from, so if there is one platform you want to allow to perform dupe updates (say, for example, an external dialer system), and another platform you don't (say, for example, an actual vendor), then the system can just use the IP addresses for this.
Lastly, there's also a new option that can allow dupe updates to only update specific lead fields. This does not currently allow custom lead fields to be updated..
Dupe Checking example
By default every vendor source is set to reject dupes account wide, but there's a couple of other options here. Here's some different scenarios…
Â
There are two vendor sources, Vendor A, and Vendor B
There is a lead with the phone number 8888888888
The led with the phone number 8888888888 is posted into Vendor A.
Scenario 1:
Vendor B is set to "Reject if in this Account"
The lead with the phone number 8888888888 is posted into Vendor B
This post is rejected, because there's a lead somewhere else in the account with this same phone number.
Scenario 2:
Vendor B is set to "Reject if in this Vendor"
The lead with the phone number 8888888888 is posted into Vendor B
This post is accepted, because there's no lead with the phone number 8888888888 in Vendor B yet, only in Vendor A
The lead with the phone number 8888888888 is posted into Vendor B a second time
This post is rejected, because there's already a lead with the phone number 8888888888 in Vendor B now.
Scenario 3:
Vendor B is set to "Allow Duplicates" (THIS IS VERY BAD, DO NOT USE THIS!)
The lead with the phone number 8888888888 is posted into Vendor B
This post is accepted because we're allowing all duplicates no matter what.
The lead with the phone number 8888888888 is posted into Vendor B a second time
This post is also accepted, because again, we're allowing all duplicates