Contact vs. Lead - Whats the difference?

[jeffreyr]

Hi, I'm a new user of SugarCRM. Could someone tell me the difference between a contact and a lead?

Are contacts simply those people which you have contacted but are not interested in the service you have to offer? And if there is a contact who becomes a lead, does that mean I have to have duplicate info, because contact and lead will be the same.

[JDTurner]

Hi

The contacts are the people that you already deal with or have contact with in some way so you manage there information as part of your day to day business.

A lead is a potential new customer or contact so could come from a purchased list or a new customer generation campaign. With in the lead module there is the facility to convert a lead so a lead effectively becomes a contact.

Hope this helps

[salesagility]

SugarCRM information & functionality hierarchy:

LOWEST - Target - someone you don't know anything about - probably a bought in list
MIDDLE - Lead - someone who has expressed an interest in your product or service but needs to be qualified by sales
HIGHEST -Contact - The people you do business with or have been qualified by sales and you have a reasonable expectation to do business with. CONTACTS can also be suppliers, stakeholders etc.

You can convert TARGET -> LEAD -> CONTACT

You cannot create an Opportunity for a Lead or a target. If you need to create an Opportunity for either of these then there is a reasonable expectation that you are going to do business with them and they should be converted to a CONTACT.

Hope that helps :-)

[CBREGolf]

It helps me. Thx.

So would you typically create a custom module for targets?

[salesagility]

No, there is a targets module in Campaigns

[Angel]

I would further add that it is not necessary to use any of those modules. It all depends on how you do business or plan on running your business.

For example, for some folks, it is perfectly acceptable that everything gets inserted into Contacts and active customers versus prospects are distinguished by simply using a drop down with the selections of "active" and "inactive."

Point being, one should look at documenting ones processes first then adjust the software accordingly. In some cases that'll mean completely ignoring or hiding certain modules.

[D_M_S]

SugarCRM information & functionality hierarchy:

LOWEST - Target - someone you don't know anything about - probably a bought in list
MIDDLE - Lead - someone who has expressed an interest in your product or service but needs to be qualified by sales
HIGHEST -Contact - The people you do business with or have been qualified by sales and you have a reasonable expectation to do business with. CONTACTS can also be suppliers, stakeholders etc.

You can convert TARGET -> LEAD -> CONTACT

You cannot create an Opportunity for a Lead or a target. If you need to create an Opportunity for either of these then there is a reasonable expectation that you are going to do business with them and they should be converted to a CONTACT.

Hope that helps :-)

Great explanation. Sugar needs more documentation like this. So where does Accounts fit into your scheme?

[josh7272]

Totally agree with Angel in terms of mapping out your existing business processes first.

However, It would be useful if there existed a "functions versus entity" matrix. Maybe it does somewhere???

Also, it would be incredibly useful if there existed a "best practices" document. I'm sure most use-cases in sugar correlate to "best practice", and whilst it is great to have functionality to process alternative scenarios, it would be even better to have these identified.

I for one would really want a good reason to move away from "best practice" functionality as from experience it is always best to "use it as it was made to be used"

To give a real world example, I am trying to implement email marketing and just wasn't very familiar with the from and reply-to differences in email and how they can be used for bounce handling. Email server rejections go back to the from address and are therefore handled by sugar as bounces, whilst a client that "replies-to" the newsletter (failing to read where the landing page links are), can be directed to a readable inbox. For me, my question is "well what does everyone else do". Sugar just lets you know that there are a couple of fields which you can use.

It would be great to have more directions in areas such as this such as "Some typical real world issues with email marketing and bounce handling are x,y, z - and sugar has implemented the following sets of possible solutions to these problems. Many companies have traditionally resolved these by using set A of functionlality, but set B of functionality is fast becoming the norm"
set A [description of sugar functions and business processes]
set B [description of sugar functions and business processes]
etc

The same exists for the old target/lead/contact/account issues. At the minimum, a function/entity matrix would go along way to helping to understand, as would some detailed explanations and alignments with "best practices".

In short, the documentation is good for the "what", but fails on the "why".

Simon Jones