of the
In Dynamics CRM, the Lead entity is designed for potential clients that are qualified by a salesperson prior to becoming Accounts, Contacts, and Opportunities. Once qualified, CRM creates Accounts, Contacts, or Opportunities. After the salesperson speaks with the potential client, if there is no interest, the lead is “disqualified,” which deactivates the lead record.
When used in this manner, the lead entity can be useful. However, it can cause some issues if it is not used properly.
- Leads are like perishable products or smelly fish at the grocery store—they should not get old. The longer a lead sits in the lead entity, the more likely it will be that data issues will arise.
- When a lead is “qualified,” it is deactivated and most of the data is moved to a contact and account. However, not all data is moved. For example, notes associated with the lead are not moved to the contact. You can use plugins to move the missing pieces, but it is incomplete by default.
- There is no sure-fire foolproof way to do duplicate detection between leads and contacts. This makes it highly likely that a lead might get created for an existing contact, duplicating the identity of the person in CRM.
- When you disqualify a lead in CRM, the lead record is deactivated. If that person calls back in 6 months with renewed interest, most likely the salesperson will be unaware of the old lead and not know the previous interactions with that potential client.
- When you qualify a lead in CRM 2013/2015, you are forced to create a contact and an opportunity. Not all CRM users want to always create an opportunity and a contact. See http://www.pedroinnecco.com/2013/10/lead-entity-2013/.
For these reasons, many companies elect to not use the lead entity for prospect management. One common alternative is to use accounts and contacts for prospects and leads. Using the “relationship type” field you can define a type of “suspect” and “prospect,” and flag prospective customers appropriately. Once this is in place, views can be configured so that leads are excluded from the customer views. The benefits of this approach:
- Better duplicate detection
- No loss of data when converting leads
- Marketing lists can include both leads and customers
- More flexibility over when opportunities and contacts get created.
So who should use leads?
Based on the points above you may think that I am anti-lead. I do see several types of deployments where leads are favorable.
- Environments with web form integrations that get many submissions with “Santa Claus” or “Mickey Mouse.” In these cases, the lead bucket may make sense to avoid introducing invalid contact data into your contact entity.
- Environments that import heavily from trade shows or other high-junk information sources.
- Organizations that have an individual or people that call potential clients only for the purpose of qualifying them (thanks Donna Edwards).
One more thing: Cross Entity Process Flow
The introduction of cross entity process flow in CRM 2013 does potentially alleviate some of the potential risk of using leads. This allows a user to see the qualified lead and the opportunity in the same process flow, making it more of a unified process. However, this does not take away the issues with leads and other data not converting, it just makes it easier for users to navigate between the qualified lead and the opportunity. http://canada.hitachi-solutions.com/blog/dynamics-crm-cross-entity-business-process-flow/
Thanks for a great post.
I used to recommend not using leads, but after CRM 2013, where it is possible to create Leads for existing accounts.
In our business case, there is a lot of reporting going on at the account level that force us to have a lot of required fields to make sure that all the related systems in the company are working as expected.
To make sure that we handle dublicates in the right way, I will teach users to go an create the Account and Contact (or assign existing ones if they are present) BEFORE qualifying the Lead.
In the case where the lead does not become an opportunity immediately, but the person would like to receive newsletters etc. from us, the will create the account and contact person, attach them to relevant Marketing lists and then disqualify the lead.
So for us the lead is a potential opportunity, which could be for either a known customer or a new one.
To look at is this way is made possible OOTB from version 2013.
Thanks Stig. Great feedback. If you have users manually create the account and contact first before doing the lead, doesn’t that take away the main convenience reason for using leads?
Actually, using OOB dupe detection can work better with Leads vs Contacts than just Contacts, especially in certain sectors.
I did a project for an organisation who mainly worked in the startup space – small firms, sometimes not even incorporated yet, or just getting their brandm domain etc off the ground (many of these were commercial spin-offs from academic projects i ntechnology sectors).
Their clients were as likely to use a business email as their own personal Gmail, Hotmail, Outlook.com address. And there was usually no rhyme or reason to this, it depended on their mood, time of day, which device they had when they sent an email enquiry, filled in a form etc.
So we made sure their dupe detection rules were set up to check Lead:Email1 Contact:EMail1 and Lead:Email2 Contact:Email1 and Lead:Email1Contact:Email2 etc (all 6 combinations of 2 x 3 email addresses as separate rules). This meant that once you had captured someones different email addresses (not necessarily in the first interaction) there was a good chance of identifying a match later.
If we used only Contacts, there is no OOB way to match Email1 Email2 for example. I wish it was possible, so if you agree, please vote:
Connect item: Duplicate detect different fields on same entity
We also used a custom entity to capture details filled in via web forms, which could then be optionally linked to existing Account and/or Contact records and an on-demand workflow to create new Account and/or Contact records, or update details of existing ones (eg adding email2 if email1 was already known). Lots of the “big” marketing tools have similar mechanisms, but were out of budget for this small project.
Great point Adam. I agree, you can create OOTB duplicate detection rules, but they are far from foolproof. Partly for the reasons you mentioned (people sign up for lists with Hotmail, contacts have business addresses). Also, one of my rules of life is that salespeople will always take the path of least resistance. Even with duplicate detection rules, I’ve still seen leads be a major source of duplicates. Either the salespeople are too lazy that they ignore the lead pop up, or the lead qualifiers don’t have security permission to the account/contact that already exists, so they don’t see the duplicate record. Course the same could apply to just using contacts
Another reason I should have included in the post is that IMO having two places to work from in some cases is more work for users, and they will either neglect their lead list or their customer list. if you have salespeople whose sole job is to monitor and qualify leads, and they only work from the lead entity, then it can work quite well. The issue comes in when you have the same people working from both leads and accounts/opps.
Minor correction. You can identify a contact and or an account on the lead and so only create an opportunity. The new opportunity is linked to contact and account identified on the lead record. Personally, I dislike the automatic creation of Opportunities from Leads but I suppose in a purist sales world it works.
Right–you can link to an existing one. The point is, if you don’t link to an existing one, it will create one for you. Many companies don’t want to always create opps for qualified leads.
Our CRM Consultants teamed up with our development team and made a customized product called “FlexQualifier” that actually takes care of your #5 problem– “When you qualify a lead in CRM 2013/2015, you are forced to create a contact and an opportunity. Not all CRM users want to always create an opportunity and a contact.”
Our FlexQualifier is a CRM plugin that allows for a more flexible process when qualifying leads. The users can easily turn on and off the plugin as well as choose their settings and actions when it comes to creating entities for contact, account, or opportunity. They can choose either to auto-create or make the decision at the time of qualifying on whether a certain entity will be created or not. You can find out more about our FlexQualifier by visiting our custom products page: http://ktlsolutions.com/Products/KTLProducts.aspx
Thanks for the comment–Yes, I have also done something similar using a custom dialog.