A friend wrote:

I’m neck-deep in planning for a migration to Salesforce, which has exposed some fascinating differences in philosophy. Salesforce is, in principle, infinitely customizable, which leads to this dispute: leaving intact the system’s core data structure (based on B2B), or gutting Salesforce’s data structure to power the simplicity of future usage.

How should you approach structuring a new Salesforce instance? If, for example, your company doesn’t think in terms of leads, opportunities, and accounts, would you use those as the default objects or would you use something custom? On the one hand, a custom CRM architecture feels both simpler and better, but on the other hand you’d end up losing a fair amount of any CRM’s interoperability, extensability, and, likely, outside expertise.

My History: Sugar CRM Customization

This isn’t an academic exercise, even for me, a consultant. In 2011, I deployed SugarCRM for a non-profit. (As the tech lead, this fell to me, as did email marketing and making powerpoints look nice.) Why Sugar? We wanted something cheaper than Salesforce and just as, if not more, customizable.

And boy was it custom! We made objects for activists, Members of Congress, local groups, you name it. It was the administrator's dream architecture--every relationship between object and every field on each object was what we wanted. And it was cheap: Sugar cost a few thousand dollars a year, and we in-sourced (aka I did) all of the customization and admin work.

After about a year, the simple custom CRM dream became complex and expensive.

It turned into a nightmare when we tried to report on the data or integrate this CRM to anything else. We ended up spending more on cheap SugarCRM than we would have had we used Salesforce or another enterprise CRM in a standard configuration. When we wanted to connect Sugar to Marketo or to a BI tool, we needed custom development work on our hosted version of Sugar to get it to communicate to the outside world or even to upgrade it to the next version.

My Lesson Learned in CRM Best Practices: If exploiting integrations or standard reporting functionality is important, then it’s better to keep your CRM customization to a minimum, at least in terms of core data architecture.

Customizing HubSpot CRM

This is a common issue I find with larger teams who use HubSpot. They've programmed in a fair amount of complexity and eschewed HubSpot’s standard functionality. Often the customizations arrive at only marginally better solution than the default functionality. But, such customizations make vast portions of the tool unusable and result in tougher work in doing basic segmentation or reporting.

In my view, this kind of customization ends up being a subsidy for the setup team itself. Why? They’re needed to keep the system running. They’ll be needed for any improvements or new integrations between the modded system and other tools in the future. Off-the-shelf plugins and add-ons likely won’t work if the fundamental architecture of your CRM is different from everyone else’s. It may become prohibitively expensive to graduate to the next version of your tool--upgrading becomes an exercise in updating all of the custom work.

In case you can’t tell where I fall: I wouldn’t advise customizing the architecture of your CRM. Of all of the strategic setup choices, this kind of thing has the least upside and the most downside. I’d rather customize the labels and screens people use to make their jobs easier, not the administrator’s conceptual database design. Another argument for keeping the standard setup: it's really hard to find a sales/marketing process that doesn't have lifecycle stages, lead statuses, etc. CRMs tend to work the way they work for a reason--if your sales process doesn’t involve a normalized progression through standard lifecycle stages, maybe the problem is you 🙂.