By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Revenue Operations
Flash Icon Decorative

Leads & Contacts: Bypass the Lead or Keep It?

Scribbles 2

For those of you wondering how others have bypassed the lead object in CRMs, we’re about to get nerdy.

For those of you at B2B companies who haven’t had cause to complain about leads and contacts, I welcome you to your new career in operations. If you’ve tried to summarize data at the account level for account-based marketing efforts, campaign attribution, or even aggregate a complete sales history, you’ll understand why leads suck.

We’ll cover why the lead object exists (allegedly), the “easy fix,” and the tested fix to (nearly) eliminate the lead object.

Why Do Leads Exist in Salesforce and Microsoft Dynamics?

The Lead object in Salesforce and Dynamics is intended to represent both a person and a company all at once. It was originally created to simplify integrations and form field collection. If a person can enter just their email address to enter your system and become a qualified lead, you may not have enrichment tools or the ability to immediately match them to an existing account and convert them into a contact.

Many a B2B RevOps professional has asked themselves why CRM platforms decided the lead object was a good idea. Almost as many people have tried to justify this grotesque object because it was intended to help sales managers review how unqualified leads are progressing to an opportunity. In their minds:


I’m here to tell you that argument is nonsense for every sales motion outside of PLG and direct-to-consumer.

The problem with the argument for most B2B businesses is that the buyer journey for products with a buyer committee and multi-day buying cycle is not linear. It never has been. Prospects will jump in and out of sales cycles like they’re going out of style.



Prospects look to solve a problem, lose the budget to fix the problem, then bounce back again when they get the budget back.

Sometimes, prospects go through a product evaluation, purchase a product, find out they bought vaporware, and then find a vendor who can live up to their promises (not that I’m a bitter buyer).

And what about upsells? Lost opportunity boomerangs? Customer attrition and a user who discovers they really needed your product once it’s gone? In these cases, inbound activity or outbound prospecting should be done against the account (or a contact) so that your sales representatives retain access to a complete record of activity at the account.

While marketers and operations professionals may *think* that sales really just needs to know what a lead did to raise their hand to qualify an opportunity, it’s extremely important to understand the history of an account – and salespeople are judged harshly if, for example, they didn’t know the person had been a paying customer in the past.


Step One: Ask Yourself If You Need Duplicates

I’ve had debates with sales managers who wanted multiple copies of the same account to create a false hierarchy. Or they wanted to split the account to accommodate assignments to different representatives based on what they were selling.

I have yet to hear a bullet-proof reason to intentionally keep duplicate account records. 

If your organization doesn’t already have a working definition of an account, we recommend you set about creating one now. Are you creating accounts based on physical locations? Will you allow exceptions for regional groupings and create shadow accounts for conglomerates that don’t have a regional headquarters? These rules will help you avoid duplicates for the sake of organizing hierarchies.

Territory teams are an excellent solution to most of the other reasons I’ve heard for splitting out accounts. It’s inadvisable to hide opportunities from people working the same account. More often than not, it makes the organization look unprofessional (“What do you mean you don’t know Tony Tobbobbin is already working with us on a deal? He’s in YOUR company.”).

There are very few reasons to advocate for multiple person records or lead and contact records.

Note that I’m not talking about retaining a record for Company A when someone leaves for Company B. I’m a big advocate of keeping both records where they are in that case and having a “Status” indicator to show the person is “No Longer Employed” at Company A. These historical interactions might have good information for sellers who are prospecting Company A.

If you’re raising your hand and saying, “But marketing needs to have a record of each interaction, so when a person fills out another form, we create another record,” lower it. I’ve heard this excuse. This is precisely why campaigns and campaign members were created. You don’t need multiple person records to log multiple marketing campaigns.

And if you’re raising your hand and saying, “But we need to track each stage of the funnel as a person passes through,” lower it. As admins, it’s up to us to figure out how to accommodate exits and re-entries of the buyer journey. We should anticipate that “recycling” will happen (because it does all the time) and figure out how to keep comprehensive records of multiple buyer journeys on a person record and learn how to elevate them to the account level.

We’ll cover exactly how in a future article.

If you’re raising your hand and saying, “But our product integration requires duplicates,” it’s time to hound your product manager into figuring out a better solution.

The only time it may make sense to have a lead record when a contact already exists is if you have a PLG motion that allows people to sign up for your product with a personal email address and only requires a lead record because you don’t need company information until after they purchase an upgrade.

There are few exceptions that make the lead object an attractive option in B2B, and most of them evolve around an extremely short buying cycle or a direct-to-consumer motion.

“Fixing” Duplicate Leads With Bandaids

If you’re short on time and are looking for easy ways to make a messy database cleaner, you can try matching and duplicate rules in your CRM. You can determine how stringent or lax the rules are, whether they fire for specific roles or profiles, and create fields to prevent them from firing on certain records at all.

Warning: If a lot of thought is not put into duplicate rules, you can cause a lot of problems for people trying to fill out a contact us form, block integrations, and frustrate the crap out of end-users. 

LeanData, Ringlead, Cloudingo (now Symphonic Source), and a few other platforms have deduplication products. Before you turn these on, you’ll want to discuss whether or not the logic is customizable. For example, you’ll want to know if you can include or exclude certain fields from being considered in the matching formula and what fuzzy logic options they have (for example, can the application catch a match that may be misspelled?). You’ll also want to understand if the record is merged properly and historical data is thereby retained.



Unfortunately, you probably won’t be able to turn off the lead object (restrict access). Many integrated platforms and forms rely on the lead object to transfer data. By passing in lead information, the form can require less information and does not have to spend processing resources trying to figure out if there’s a match.

You also may not be able to address historical data without manual intervention or significant review. Campaign Member tracking, in particular, can be very problematic due to member limits.

Fixing the Problem With the Big Guns 

While we don’t see getting completely away from the lead object in the short term, there are options to minimize your lead records to an absolute minimum. These records should only be created for people with personal email addresses with no way to associate them with a company.

At its simplest level, we’re suggesting you convert leads to contacts whenever possible following this logic:


Note: 

  • Don’t assume that contacts will only have expansions or renewals associated with them. 
  • Build a qualification process on the contact record that is robust enough to account for expansion and renewal sales. 
  • Manage your more niche sales processes on the opportunity level with different record types.

Option A: Fix It in a Marketing Automation Platform

Not all marketing automation platforms have an account object. Some will require you to set this data up in a custom object or not allow you to have account records and use lookups to bring in needed data. If this is the case, trying to convert and merge lead records into contacts will be very difficult.

That isn’t to say that your platform can’t identify existing person records with matching email addresses and append additional campaign data on these records. You should have this turned on if it isn’t already automatically running. All marketing automation platforms should be able to determine if the email address already exists on a contact record and, if so, append the data to the existing record.

If you have a marketing automation system like Hubspot, it is possible to set up workflows to create contacts instead of leads. Suppose you determine that contacts should only be created. If Hubspot doesn’t find a matching account and contact, Hubspot will create the contact first with a blank account, determine whether or not you have a matching account based on domains (or assumed domain if website data wasn’t collected based on email address), and then create the account or associate the record with the matching account. 

Warning: If you have a process to assign orphaned contacts to a catch-all account, be sure to delay the process. If Hubspot finds the record already has an associated account, it will assume it doesn’t need to perform any further action.

Option B: Fix It in Your CRM

Once a lead record lands in your CRM, you can kick off a process to see if the record already exists as a contact or if the account already exists. In Salesforce, this logic can run in flows. When the flow determines if and how you want to convert the record, you’ll need to use Apex to handle the conversion to properly trigger merge functionality and retain related records.


Option C: Fix It in Your Data Warehouse/Data Lake

Suppose you have a talented business intelligence team or the right skill sets in your RevOps department. In that case, you can set up a two-way integration with Salesforce and handle matching and merging logic in your database. 

The benefit of taking this path is that you have complete control over the process and can be as granular as you would like when it comes to logic. The downside is your team will have to do a lot of testing to make sure that records related to your leads and duplicate contacts are moved appropriately and saved.

We hope you found this guide useful! At the very least, we hope you’re reassured by the fact that other companies have successfully implemented ways to minimize their use of the lead object and have seen big benefits in how this has improved their data hygiene and simplified their reporting.

Looking for more great content? Check out our blog and join the community.


Related posts

Join the Co-op!

Or
scribbles 7 birds
Tail Spin Animation