Most CRM systems now boast “easy point and click customizations.” Administrator users with no formal training are empowered to easily customize their organization’s CRM system, which can save time and money compared to the programming that may have been required with legacy systems.
However, with power comes responsibility. Taking the wrong approach to even basic CRM customizations can end up being very costly in the long run if improper customizations and resulting data need to be later transformed into a more usable format or a more easily reportable format.
Here are some common CRM customization mistakes and how to avoid them.
1. Creating too many custom fields
It’s best if there’s some level of team consensus on whether to create a new custom field, what the data type of the new field should be and which loosely or strictly enforced business rules should be included with the new field. Continually adding new fields without forethought or consensus can ultimately result in unused or redundant fields.
2. Adding a sea of checkboxes
A specific example of an excessive number of custom fields involves screens with dozens of checkboxes.
Instead of creating a lot of boxes for users to check, it’s better from a data management and reporting perspective to create a related, custom entity or object — and then allow users to select the appropriate values.
3. Requiring data entry in too many fields
The number of required fields in each entity or object should be kept to a bare minimum. Too many required fields can end up discouraging adoption if users continually encounter situations in which they have not been able to collect all the information for which non-null values are technically enforced while creating a new record.
4. Using pick lists instead of lookups
Instead of creating a pick list with dozens of drop down values, it’s normally better to create a lookup on a custom entity or object. For a large number of potential values, a lookup allows for search. A lookup field also allows for an inverse view from the selected value back to all related records.
5. Not leveraging dependent pick lists
Often, the values in one pick list are dependent on the values in another pick list. By controlling which values appear in a pick list based on the value selected in another pick list, users are guided down a path of proper data entry.
6. Not setting up field validation rules
Let’s say that your company only sells into the United States and Canada. For these two countries, there’s a well-defined set of two character abbreviations for states, territories and provinces. With validation rules, it’s easy to ensure that only valid, two character values are entered and that you don’t end up with CA, Calif, California and Cafilorina all referencing the same state.
7. Creating groupings of flat fields
Unlike with a flat file contact manager, in a relational CRM database, there should never be a need to create redundant sets custom fields such as for “Property #1”, “Property #2”, etc.
In this example, it’s much better for each Property to be its own, separate record.
8. Not displaying important parent fields in a child table
CRM applications allow for easily displaying parent fields in a record view. In order to economize on upstream navigation to view important parent record data, an administrator can easily display selected parent record fields within a record.
9. Not segmenting customizations by user roles
If your organization has users within different departments who need to access the same CRM records but need to see custom fields that are specific only to their role, you can segment record views by type of record and/or by user.
By avoiding CRM customization mistakes such as these, your organization can save money and have a more adoptable CRM system.
