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.
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 it’s a bunch of nonsense! Shenanigans, I say!
The problem with the argument is that the buyer journey 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? Company attrition that brings about a buyer who really does want to buy your product on the same account? In these cases, the lead should be converted against the existing account so your information is easily digested by sales, making us wonder why it wasn’t a friggen contact in the first place.
I’ve had debates with sales managers who wanted multiple copies of the same account to create a sort of hierarchy. Or they wanted to split the account assignments between different representatives based on what they were selling.
I have yet to hear a bullet-proof reason to intentionally keep duplicates.
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 account 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.”).
I’ve even heard that companies wanted to keep multiple records of people if they filled out forms multiple times or entered the sales cycle more than once. I highly recommend leveraging campaign members to track your marketing interactions (a one-to-many association with contacts) and opportunities to track your sales cycles (also one-to-many by design).
Once you have your rules, cycle tracking, and assignments sorted out, you can determine whether or not you need duplicates.
**cough** You don’t. **cough**
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 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.
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 be restricted to people with personal email addresses with no way to associate them with a company.
At it’s simplest level, we’re suggesting you convert leads to contacts whenever possible following this logic:
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 platforms should 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 platform 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.
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.
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.
To some, RevOps is the glue that holds the entire go-to-market function together. To others, it's like trying to convince your dad that a Tesla Model S is a faster, smoother, and more comfortable ride when all he wants is his tried and true ’65 Lincoln Continental.