Don't like the data model.... (Leads, Accounts, Contacts) - ideas?

[abloch]

I have a general gripe, it is not Sugar specific, but since I am (seriously) evaluating Sugar I think this is as good a place as any to ask the question....

My "problem" is with the data model that Sugar (and others) force you to use with respect to the logic of Leads, Accounts and Contacts. Leads and Contacts are essentially people, while an Account is an entity (Company). Now...

As per MY business process, we start at the company level. Meaning, we import a large bulk of data, essentially a list of companies, and then work off that. The process for me would be: Lead (which is a company) -> Account -> Contact. The logic is that first we qualify the company and create a valid account, and only then add contacts.

In Sugar, a Lead is a person and when you convert a lead, the default (which must be there) is a Contact, and only then can you also opt to create an Account (and an Opportunity). For me that seems very backward...

It is also, by the way, extremely annoying that you can enter address information for a Contact, and have to do so for every contact. Why not just associate a contact with an Account and have that as the address? I think this can and would lead to a very messy data integrity.

Comments? Suggestions?

Thanks

[Proware]

We have a very similar requirement as yours. We have been using Sugar for some time and were getting nowhere with Leads. We eventually just simply stopped using leads at all and everything becomes an account / contact.

We categorie each record to filter out our suspects / prospects / clients.

It could be better but seems to work reasonably well at the moment.

I also agree with you that there should eb synchronisation of addresses between accounts and contacts. I would go further and also want synchronisation of Assigned To and Team (Pro version).

[abloch]

Yes, I don't know why it is modeled like that. It is very "un-realworld like". Considering that it is not only a Sugar problem, I really wonder about CRM people some times....

The issue of multiple offices is also very annoying. Meaning, a company (i.e. Account) can have many office (i.e. locations) and as per me, you should be able to associate a contact with an office (south, north, head office, etc.).

But coming back to the Leads issue, yes I really don't know what to do about it. As you said, you just dropped using it, and that is the worst option in my view at least as far as the software vendor is concerned....

By the way, SalesForce, while having similar issues, has a very very nice Que management feature, as well as the ability to create a hierarchy amongst the members (i.e. so that all sales people in a territory can be viewed by a manager, and the regional manager views the territory manager. etc etc.).

[roblaus]

Yeah, I agree in principle. When I started looking at Sugar I couldn't deal with the concept because for me a "lead" was actually an opportunity with associated information like account (address in my case), contact(s), product etc. I couldn't understand why a lead should be a person.
In the meantime it suits me well as sort of a general "pot" where I put everybody and everything that I can't really qualify or that is waiting to become part of a target list (where is the difference here by the way...). But yes, I could easily live without it.

What I would like to see: a method of adding entities easily and connecting them through a relationship "backbone". That would solve the multiple office problem as well as the channel issue (which dealer is responsible for which customer and vice versa).

On the other hand: I sincerely believe that Sugar currently is the best value that you can get for your money. I have seen most of them (the OS ones) and I was working for quite some time as a distributor for one of the more advanced packages (strictly commercial). I would look somewhere else if I was looking for a solution for a larger entity, though.

rgds
rl

[abloch]

Yes! I could not agree more....
A good structure of entity relations in the background would, indeed, make things a lot more *real*. Of course you might be able to twist the system to suit your needs (err... meaning you work the way the system does), but it is far from best.
By the way my comment is on the Pro version (which is what I am considering) as well as the OS.....
Sugar staff? Any takers??

[andydreisch]

... What I would like to see: a method of adding entities easily and connecting them through a relationship "backbone". That would solve the multiple office problem as well as the channel issue (which dealer is responsible for which customer and vice versa) ...

Hi roblaus, the "Member Organizations" subpanel may be a solution for you. It allows you to specify one/many Accounts to associate with a given Account. The relationship of a given Member Organization to an Account cannot be further described by a type (e.g., "Partner", "Vendor") but maybe this won't be too restrictive for you.

Finally, we purposefully designed the system to not require Leads, so we're curious what functions are missing from the account-centric standpoint. Proware mentioned tighter linkage w/r/t Account-Contact addresses and Team-Assigned, and these are important, but not fundamental. Are there truly fundamental issues preventing the use of Sugar from an account-centric standpoint?

Thanks,

Andy

[roblaus]

Hi Andy,

Two things - when I am talking about a relationship "backbone" then I mean the possibility to create a relationship "network". Think of an entity "machine". For one of my previous customers it is the most important thing to know WHERE a machine (e.g. a heavy construction vehicle) currently is. By knowing the average life span of such a thing they can exactly determine when to approach the current customer (who might be the fourth owner already) in order to sell a new (or more importantly a used) one to them. Another example is the construction industry in general: For them usually the PROJECT is the anchor. Sometimes a project exists long before there is an account - just because sometime, somewhere a political decision was made. Only afterwards they group accounts (= other entities) around it. We're talking municipalities, architects, influencers, competitors etc.

Re, account vs. lead: I guess the lead is sort of a legacy thing in Sugar and will disappear eventually. The account in my opinion must be a lot more flexible in order to reflect all possible characteristics. It would be cool if the account type (supplier, competitor, customer etc..) could also define the required fields (screen layout) and if there was sort of a workflow component that allows certain attributes to change automatically once e.g. an opportunity has been created. But this is a very complex topic.

For the time being it would be a big progress if accounts could have n addresses and if they could be "related" visibly.

rgds
rl

[andydreisch]

OK, roblaus, thanks. This helps clarify things.

Andy

[kpit]

The Leads module is not needed by all business models. Leads is very useful in many models of business. Each type of business will have a diffrent method of doing business that may or may not use leads. For example a company needs to maintain some seperation of leads from actual customers.

That is why the leads module is optional and not nessarly needed to use SugarCRM. This flexability allows SugarCRM to serve many business types. The fact that you can disable the Leads module from being seen at all, gives you the ability to control how your users see SugarCRM. The ability to mold SugarCRM to your business model is its greatest feature.

[roblaus]

I tend to disagree. In the "real" world (and that's what we try to depict one way or the other) there are unique objects or entities. The main ones being the company and the person. A company might be considered a "lead" as in unqualified address but at the same time this company is a supplier and probably even a partner in my own business. The difference is what many people call the "role" of this particular entity.

Any business is essentially dealing with the same types of entities but their business model is defined by how these entities interact, how they relate to each other, which roles they are playing. This said it doesn't make any sense whatsoever to keep two or more copies of the SAME entity in the database (and by all DB standards it's forbidden anyway).

I'd prefer a model where a company can evolve from a very basic role (essentially just a name and probably a phone no) into a very rich and well defined object with people, orders, products, projects etc. attached IF this role is chosen. If an assistant is viewing the same company as a supplier the role is different and thus the set of relations and objects.

I do agree with you when it comes to practicality, though. For the user it doesn't matter how an object is represented in the database as long as it does what it is supposed to do.

rgds
rl