Why is sugar based on three contact types (Target/Lead/Contact)?

Hello Dale,

Conceptually SugarCRM has divided the persons (Entities) in different ways in the CRM as per the sales and business need. Contact referes to the acutally customers for the business, Leads are obvious understood, and Targets are people to be approached for specific campaigning.

You can always use the application the way your business needs are. If your concern is to use only Contacts or Leads for campaigns, Certainly you can do that.

I am pretty sure that you will be knowing the usages of modules, Though just for reference for someone's need here is the explaination of the modules.

https://support.sugarcrm.com/Documentation/Sugar_Versions/6.5/CE/Application_Guide/index.html

Thanks & Regards,

Team Urdhva Tech

Web : http://www.urdhva-tech.com

The classic sales process behind these three types of persons is as follows:

1) Targets are persons you normally buy from an address seller, or collect in your company from old excel files. Normally you do not know these persons (any more) and the first step is to get in contact and check whether there is any chance to  have a deal with them. After unsuccessful contact you normally delete or mark them as dead in your system.

If such a target shows interest you convert it to a Lead.

2) A Lead is a person who met you on an exibition or a faire or who filled out a web2lead form on your homepage e.g.

These persons are interested in some information from your company but you did not have any deal with them until now.

You know already some details about their company and their special needs.

So communicate with them and in the best case they ask you for an offer. That it the point when you convert them to a Contact, an Account and an Opportunity.

3) Contacts are persons working in a company (Account). You know each other and you have or had some deals with them.

Some companies have all 3 kinds of persons in their environment, others only the Contacs/Accounts, in Sugar each company can decide which of these modules are used and shown on the screen...

Harald sums it up quite nicely. To his comments I will add some questions/comments on each of your points:

a) What exactly is the problem you are experiencing? As is, Sugar is rather account centric, so I am curious as to what challenges it is you are experiencing in applying that out-of-box paradigm to your specific needs.

b) There is usually a duplicate check that kicks in during this process, along with the ability to manually link to an existing record. The duplicate check is not much different than the one a user typically sees while entering a record via the standard creation process. Are you not seeing the duplicate check?

c) I am not sure I understand the problem. If we assume that a custom field of same type and name exists on both the Leads and Contacts module, Sugar will automatically carry over the content of the field upon the Lead being converted to a Contact.

Lastly, if you are better served by only using the Contacts module, that's also possible. For example, you could always create a custom "Status" field for the Contact entries that in turn helps you organize them based on their interest.

Hi again, thanks for taking the time for those replies, I guess I didn't phrase my problem too well, probably because I haven't really defined it yet, let me tell you more...

We have been using Sugar Professional for about 3 years and it has been reasonably successful. It was introduced by our new (at the time) marketing manager but she is just about to leave us so I have been asked to look at a few things as I have some database design experience...

I already knew how the three contact types should be used in marketing operations, but the reason for my question was that I would have thought that a much better way of working would be to have all TARGETS/LEADS/CONTACTS in a single, common data file (and format) and to simply change a status flag (or similar) to indicate whether they are considered a TARGET/LEAD/CONTACT? Surely this would make it easier to “convert” between the levels or to market to the whole list (as we often do) without fear of too much duplication (it seems to me that after conversion records also remain at their previous level causing a duplicate?).

For instance if I recall correctly there was no INDUSTRY_TYPE field in the TARGET database, but this is an important field for us to select on when marketing, so we added one to the TARGET database, but this then has to be “handled” when converting to the LEADS database, which was not easy for a marketing person with limited database skills. Was this the right thing to do?

As has been suggested in the replies above I am considering converting all TARGET records with good contact information, i.e. valid email, telephone and useful profile information such as postcode, industry type and company size) to LEADS and market primarily to that group. Then the TARGET database would only be used if we want to add new names to the LEADS database, probably by going through a cleansing exercise.

So back to my original question, is there a good (technical?) reason why the three databases are separate? Or is it just the way it is.

Finally, regarding contact/account centricity, it seems to me that throughout the SugarCRM system, particularly in TARGETS and LEADS everything is handled at the individual rather than organisation level. This seems strange to me as surely most marketing activities are aimed at organisations rather than individuals? For instance I am much more likely to be trying to work with ACME CORPORATION than JOHN DOE, but everything in Sugar seems to revolve around the individual. Does that make sense?

Any thoughts?

Thanks again for your time.

Dale

Hi Dale,

It feels good when some interesting things gets discussed which is worth. It has always been one of the most asked and concerned question. I certainly agree to your perspective, which is clear enough on how to manage the entities within system. Harald Kuske has made things clear on how things are used and Angel Magana as well helped showing how each entities can be carried out along the business flow, like passing the fields along the modules and The duplicate check features which intervenes in the process.

I would say it would be an individual's choice on how he foresees the CRM and how he want the business process to be implemented. If it better serves by having only contact module, It can be manage by having custom Status field as suggested.

Thanks & Regards,

Team Urdhva Tech

Web : http://www.urdhva-tech.com

There are very valid reasons for separating them. Before I get into it, I'd like to correct your point about it being in three databases, as that's not the case. The various objects are stored in three different tables within a single database. The data in those tables in turn translates to three different modules.

As for the reasons behind the three objects, bear mind that your use case is but 1 representation of how to utilize the system. Other organizations will vary and the product is designed with the flexibility to meet various needs versus one or only a few.

That being said, I've worked with many customers that would find that adding all the records into a single module results in a polluted database. That's one of the primary reasons as to why you find that many CRM systems use the paradigm that you see in Sugar. It helps create a clear delineation between "active" customers and those that are being qualified (and what stage of qualification they happen to fall into).

This also opens the door to run metrics such as seeing your lead conversion rates, or essentially, figuring out how many qualified leads are being converted to active customers during a given time period. It becomes much harder to do that if everything is in a single bucket because beyond the change to the "Status" field, there is no definitive way of knowing if the person is active or still being qualified.

On the more technical side, the separation also simplifies security models and the ability to restrict access to data. I know of customers whose processes are basically such that the users doing the qualifying of leads never have access to contacts/opportunities/accounts. Those users essentially are used to do nothing else but work the leads to find out if there is an interest for the company's services/products. Once they have a positive answer on that question, the lead is handed off to a sales person to actually work the deal.

I am sure there are other examples we could come up with, but i think you get the point. Different businesses have different approaches, hence the flexibility in the system. Per my previous post, if you feel you are better served by only using one module, Sugar allows that. Just be mindful that it might complicate other processes, such as the lead conversion metrics I mention.

Hi all, thanks again for the contribution, especially the comprehensive response from Angel. I'm sorry I used the wrong terminology, I completly understand the difference between databases and tables but not doing ths type of work very often I misused them. I'm an IT Sales guy (server & storage infrastructure mainly) who happens to have a reasonable understanding of database architecture so I have been tasked with looking at our options for getting better value out off SugarCRM, but my coding skills are very basic and rusty, plus time is very limited.

The guys we had in to help implement Sugar 3 years ago told us we had to have the 3 table/module approach, knowing what I know now I would have ignored targets and started everyone as a lead, that suits us, but I now absolulty get why you offer the flexibility for other use cases.

However, that leaves me with a bit of a dilema. We have about 400 records in contacts, 6,000 in leads and about 65,000 in targets, Of those 65,000 about 20,000 have good quality data (i.e. valid email, phone, industy sector, company size, job role etc) so I would like to convert those to leads where our marketing campaigns are run from, but I see two problems, without coding:

1) I don't think I can make a selection based on multiple fields having data in them.

2) I don't believe there is an easy way to mass convert selection to leads.

The only solution I can think of is to export whole target table to Excel. Delete all records in target table. Make my selections in Excel, import selected records into leads table and reimport other records back into Targets (if I want to.)

Any better ideas?

Thanks again for your valuable help so far.

Dale

If you have access to the database, you can use some SQL statements to transfer the data...

For example, I could take the first and last name values from all the non-deleted Targets and copy them into the Leads table by way of this statement:

insert into leads (id, first_name, last_name)

select id, first_name, last_name from prospects where deleted = 0;

You would need to do something similar to account for the data in any custom fields you might have added as said data is stored in prospects_cstm and leads_cstm respectively.