SugarCRM object naming is wrong.

[edykstra]

Hello,

I feel that our process is very similar to what most people would go through with their business. However, every CRM I have seen has some other 'philosophy' that just does not work well. This includes SugarCRM.

They have objects like Leads, Contacts, Accounts, and Opportunities, that seem to make sense based on their names, but in practice do not. In fact, the 'C' in CRM is for Customer, yet I do not see anything called 'Customer' in SugarCRM!

For example, most B2B sales people target a COMPANY to contact first. They don't identify a person first and the company later. However, to create a LEAD, you MUST enter a Last Name. This forces many Last Name entries that are 'TBD' or 'NA'. This creates confusion.

Soon, there are multiple people as leads for a company, but it is still not obvious which is the appropriate contact. That often takes a bit of time. So, then we have multiple Leads in the CRM, each at the same Company, but no way to group them together with a Company object. This creates confusion.

Eventually, we reach a point where we know which Lead is the appropriate contact. We then convert them to a Contact and attach the other Leads for future reference. However, this means they are still Leads when really, we want them to become 'references' or something. We could delete them, but when we do. we usually regret it later when we need to involve them as well. This creates confusion.

However, sometimes there is more than 1 Lead we convert. In those cases, there is still no way to group them into a Company object. Our only choice is to use an Account object, but they do not have an Account with us yet! This creates confusion

Eventually, we receive a RFQ. At that point, there is an opportunity to win their business. However, to create an Opportunity, you must create an Account! To me, an Account is someone we will invoice. Therefore, an Opportunity should be attached to an Account, not the other way around. This creates confusion.

The issues go on and on, and trying 'work-arounds' just makes things worse.

To me, it seems that everyone decide to copy the first 'philosophy' out there (SalesForce?) and the bad design is being perpetuated.

Have I got that right? If not, what gives?

Thanks,

Eric

[Angel]

To me, it seems that everyone decide to copy the first 'philosophy' out there (SalesForce?) and the bad design is being perpetuated.

Have I got that right? If not, what gives?

Thanks,

Eric

Actually, I think the applications are not so much mirroring each other as much as the applications are trying to adhere to popular sales methodologies like Miller Heiman. It kind of makes sense that software vendors would want to do that, because many sales organizations recognize those methodologies as pseudo-standards for sales processes, thus, not providing functionality that aligns with those methodologies -- at least to some extent -- would have the reverse effect of appearing to be an inadequate tool for sales.

Now, in reality, I've heard people ask whether such methodologies are supported in various CRM systems I've worked with, but I've yet to encounter anyone who actually puts those methodologies to practice.

It is a bit of a catch 22. If the tools aren't there, it becomes a "no" on the checklist, if they are there, they are rarely used in the manner in which they should be, if at all.

[edykstra]

Angel,

I have no understanding of the 'Miller Heiman' approach. Sure, I could Google it to learn more, but I can't see how what I see as faults could be justified as 'correct''.

Are you stating that no data should be entered into the CRM until AFTER a name is determined from a company we are trying to sell to? Or, are you suggesting that we should enter their last name as 'TBD'.

Following the "Miller Heiman" approach, what 'triggers' defines when a Lead should be converted to a Contact?

To me, there is a HUGE opportunity here (no pun intended) to grab a HUGE SMB market for a 'real' as opposed to a "Miller Heiman" approach) CRM solution.

Eric

[Angel]

I think you read a little too much into my comments.

My point was merely that the software is designed more to address common sales methodologies as opposed to the competing products mirroring each other, which is the point you made which I was responding to.

By no means was I inferring, nor meant to infer that using those methodologies is the correct approach to design the software or use it.

The software can be tailored for many different scenarios and needs, that's one of its strong points. If one doesn't like the way it works out of the box, one doesn't have to use it that way. One could be completely oblivious to the fact that Miller Heiman or other methodologies exist and still use it effectively.

I am not a Miller Heiman consultant, so I couldn't tell you all the nitty gritty details involved in that methodology. However, what I can tell you is that if you don't use that methodology or one of the other popular ones, that doesn't translate to you not being able to use Sugar.

The best advice I can give you is to document how you envision your sales process functioning, or how it currently functions so you can effectively translate that to functional areas of the application.

[roblaus]

I may add a few words here:

@CRM - it's a recognized concept in the meantime and everybody knows that the C is obsolete. Do you know what "3M" stands for?
@Account - rename it to "company" and your problems disappear
@Leads - skip them, remove the tab and use companies and contacts. Add a field to the company that reflects the status (lead, account, dead...)

And Angel is right - there are quasi-standards in the meantime and all CRM packages use them in one way or the other. Miller-Heimann is one of the better known ones.

[edykstra]

Hello Robert,

What you suggest is a significant 'hack' to the process laid out by SugarCRM and the 'quasi-standards'. I am certain it will create more issues than it solves. Further, if I have to make drastic changes like that to SugarCRM, that tells me it is the wrong solution - for us and most businesses.

Eric

[SugarDev.net]

edykstra, Robert's suggested alterations are not what we usually consider a 'hack'. These mods are very well possible without any hacking.

[roblaus]

Thanks Loek.

@edykstra - In fact - my suggested solution is a fairly common one and most of the CRM systems I know don't even have lead and target as separate entities. It's usually nothing else than a status a company (or a person) has: from suspect to prospect to customer (or supplier, influencer, sponsor - you name them).

[edykstra]

Gentlemen,

Thanks for your feedback. Here is the summary.

1. CRM = Customer Relationship Management, but there is no 'Customer' object in typical CRMs.
2. CRM was designed based on sales methodologies like Miller Heiman, but no one follows them.
3. In B2B, the B = Business, which means the CUSTOMER and the SUPPLIER are Businesses.
4. CRM Leads do not support B2B, which require a person's name, not a Business name, to create.
5. As a 'work-around' to the above, it is suggested to ignore Leads, and rename Accounts to Companies.

I could go on and on, but this reminds me of the joke, where the guy is at his PC late at night, and his wife says, "What? You can't come to bed because there is someone on the Internet who is wrong?"

So, it is time to 'agree to disagree'.

You guys think things are fine.

I think that there is a HUGE opportunity for someone to create an Excellent and Simple solution that follows processes we all use. It won't be anything like SugarCRM and it won't give a care in the world about Miller Heiman etc.

Cheers,


Eric

[roblaus]

Probably there is. And it's up to you to make it happen. Good luck.