The Lead Object Never Should’ve Existed

A costly error in modeling logic.

Highlights:

• [Hot Take] The Lead Object never should’ve existed. Agree or disagree? Join the conversation in our Slack community.
• [Big Data 100] Syncari once again ranks in CRN.com’s top platforms for Data Management and Integration - two years running!
• [New Podcast Episode] Scott Marker shares his experience helping leaders solve for data quality problems caused by the most universal culprit: people.
• [Job Hunting?] We’ve partnered with BlueprintGTM.com to produce a curated list of GTM ops & analytics job openings that require data expertise (complete with tech stack intel). Request access in the Customer Data Automation community.
• [Partner Blog] RevPartners got super detailed in their excellent guide on how to migrate from Salesforce to HubSpot .
• [New Book] Congrats to Jomar Ebalida on the release of Rethinking RevOps: Gain Confidence in your Revenue Operation System , featuring Syncari and Stack Moxie.

—

Sometimes data models are not constructed well.

For example: The infamous Salesforce Lead Object.

According to Salesforce , the Lead Object’s purpose is to “[t]rack prospects apart from your contacts and opportunities with Salesforce lead records. After you’ve qualified your lead records, convert them to contacts and create accounts for them…” The Lead Object is a way to track the status of your relationship with prospective buyers.

Here’s why this is a problem:?

1. You’re doing this on the Contact Object anyway. Contact Status, Type, Engagement, Scoring fields are still prevalent on the Contact itself.
2. Plenty of Contacts are unqualified and still need to be qualified.
3. Knowing which “Account” a person belongs to is a major part of qualification. In B2B, company attributes are critical to understanding whether there’s a potential fit for a product. Did Salesforce miss this when they created the Lead Object? Why exclude this massive piece of information from the qualification puzzle?
4. Separate Objects means separate tables, reporting silos, integration problems because 3rd party developers pick and choose which to connect with, mismanaged CRM deployments, and a lot more cost.
5. The logic required to convert Leads to Accounts is, well, a nightmare.

And ultimately, it’s an error of data modeling logic.

Both Leads and Contacts are a People Entity, with different names… because jargon.

One is “People who are interested and may or may not be qualified for our product” and the other is “People who work at a company.” You see in that language that detaching Lead from Company doesn’t make sense.

Let’s say, for instance, someone comes to you with an idea for a new CRM. But they want to do something revolutionary: they want to track massive numbers of companies, and separate the unqualified ones from the qualified ones with two different objects: Account and Potential Customer Account.

Your first question should be: “Why can’t we track qualification as an attribute on the Account object?”

We’ve been asking around for a bit on ops experts’ thoughts about the Lead Object. Rarely is it favorable. Most of the time it’s a begrudging admission that sometimes it can be useful. Even those who defend the Lead Object don’t really defend its Object-level glorification.

Ever since its inception, the Lead Object has forced CRM admins and sales ops pros to accommodate a fundamental error of first principles.

HubSpot does it right: Contacts and Companies.

So here’s an example of the ideal Contact record. There’s a lot here, and it lives in multiple different systems (a strong case for the need to unify contacts across your systems ).

And if someone invents a time machine, maybe they can use it to go back in time and prevent Salesforce from implementing the Lead Object as a separate entity from Contacts.

Tell us what’s missing from this contact model in the Customer Data Automation community .

Cheers,

Evan Dunn

Director, Growth Marketing