SugarCRM vs. Salesforce

[davidsmith31988]

Hey folks,

I was wondering, if anyone of you have used SugarCRM, SAP Business by design, Netsuite, Salesforce.com or Oracle on Demand. I am interested in learning from your experience, when one is better than other.Thanks for your opinion!

Best,
David

[REByers]

Hi David

I am in the middle of rolling out Sugar to replace an aborted Netsuite install that replaced a Salesforce.com install!!

From my point of view owning my data (after havng SaaS) is a huge win. I know (after being at a recent MS CRM launch and an address by the ex MD of SalesForce.com in UK) that the SaaS guys use their hands on your data as a retention tool. So getting data out of Netsuite was a real (and I mean REAL) pain. Also there are legal complaince shortfalls using NetSuite in Europe.

The users of the system have reported that (compared to NetSuite) Sugar is far simpler to use, and I find the interface far less cluttered.

Sugar is slightly defieicnt in some areas (IMHO) compared to Netsuite, esp in teh area of support (case handling) where it's so basic it barely made it through the slection process for the support teams I aim to roll it out for. I am spending my money in this area with partners to try and bring this module up to scratch. Also I found that the way Custom screens can be attached to teams in Netuite a real win over Sugar. This would be a big imprvement if Sugar could do something in this area.

On balance I have found the Sugar partners, and Sugar themselves far more approachable and helpful than the NetSuite folks, and, overall, the application wins over NetSuite and SF.com for me.

I head up Operations for a 150 seat software house who do large scale DB work for a living.

[andydreisch]

Hi REByers, thanks for the informative post.

On this: "Also I found that the way Custom screens can be attached to teams in Netuite a real win over Sugar.". Can you please explain this in a little more detail? I'm not sure how this would work and the use cases it'd be useful for.

Thanks,

Andy

[Angel]

Andy,

This would be an awesome enhancement in my opinion.

When we introduced it into GoldMine, it was introduced as a feature called "Record Typing."

The basic issue we were trying to address at the time was there were many users that were utilizing their CRM database to store varying types of data entities within a single database.

One common use case in the GoldMine world was that of a real estate agent. If you examine how they conduct business, they deal with potential (or past) buyers, sellers, properties, inspectors, personal contacts, etc., but for each of those, there are differing data entry needs (and often, display too).

For example, if you enter a record that corresponds with a potential buyer, you'd be most concerned with being able to enter all their contact phone numbers and any other way you might have of contacting them. On the other hand, if you enter a record for a property, you'd want things like the square footage, year built, number of bedrooms, etc.

The dilemma from a customization standpoint is which end result becomes the focus of your customizations. Without the "record typing" in GoldMine, users often times had to create a lot of different fields to accommodate the various data entities they needed to enter.

But then you still had the problem that all the fields were displayed all the time, even if you didn't need them. There were ways to circumvent that to some degree, but record typing allowed you to eliminate the problem by allowing you define entire layouts that were specific to a given entity and could be controlled by populating a particular field (or other rules). Thus, you not only have the ability to display completely different fields and eliminate the clutter, but you also have the ability to have field labels that were directly tied to the entity at hand. For example, a field with of a label of "MLS ID#" doesn't serve any purpose for a data record that is a personal contact.

If you extend this to a workgroup environment, you could tie different layouts to different teams in order to display the most pertinent info for the record depending on who is viewing it, similar to the tabs in the sub panel area.

A good example of where this is helpful is a scenario where you have multiple departments within an organization looking at the same data. On a given account's record, one may wish to store some basic financial/accounting info, as well as info relating to their IT infrastructure and some info about the e-mail campaigns they are members of, etc.

But does the accounting team need to see the info pertaining to the IT infrastructure when they pull up that contact? Highly unlikely. Their interest lies elsewhere and the same is true for other departments, i.e. marketing is also unlikely to want to see that info either and conversely, Support is unlikely to have a need to know the marketing cost of that specific account.

Anyway, just some thoughts off the top of my head...

Feel free to call me if you wish to discuss further or you want me to show it you in action. 714.740.1820

[darrenbordelon]

I'll chime in my two cents to echo support for the previous post.

Some method of controling the fields visable in a form/view based on who is looking at the form, or based on the value of some key field in the form, is very important.

Indeed, a few days ago I was just about to start seriously digging around for a method to do this in Sugar.

Like any compnay, we have a range of contact types. We are an educational recruiting compnay, so contacts largely fall into two clases, applicants and school officials. We also have the various vendors and other assorted contacts.

When editing a contact of type "applicant" we need to see fields covering things like special credentials, availability, work history, age range of kids he/she can teach... etc.

But the information for a school HR rep is much different, and includes things like hiring preferences, and so on.

Applicants and school HR reps are both "contacts" but they have much different data associated with them.

Yet you can't have seperate form views in Sugar to edit the data for these distinctly different contacts. So, you just have to put ALL the fields you may use for any possible contact type into the global form view.

Thus, Sugar gives us forms that work, but they tend to have far more fields than required when editing a specific type of data, or when being viewed by personel that only needs to see a subset of the data.

It would be fantastic if there was a way to have this ability.

Cheers!

[ronshoe]

Have there been any additional developments along this line? I, too, could make great use of this functionality. Thanks.

[JWG]

I am involved two business, one uses Netsuite and the other SugarCRM. As well as direct access to the data, the other massive advantage of SugarCRM is that you also control the hardware. If the system is running slow you can buy a bigger server. Also I find the SugarCRM page loads approx 3 times faster (obviously while on the same network, but also when accessing remotely).

[samson smith]

Nice thread that gives the proper information about Netsuite and SugarCRM. All opinions are so informative. In my opinion Netsuite is better than sugarCRM. So, I say thanks to all for sharing your opinions.