A LinkedIn post the other week from someone who got HubSpot for Christmas got me thinking back to the simplicity and efficiency of having a fresh CRM without modifications. After working 20+ years with CRMs as a CMO, COO and VP of Sales, the modifications we do to our CRMs rarely provide the value we think. In fact, heavily modified CRM systems actually hinder operations, and eventually leave an organization ham strung by spaghetti workflows, fields no one knows what to do with, and a fear that they are one change away from breaking the system. My belief comes from inheriting everything from fresh installations of a CRM to joining a company that had spent over $500K customizing it. In all cases, the modifications did not help over the long term. The sales and marketing teams were anywhere from 3 to 100 reps, selling anywhere from 3 to 30 products. It is just too easy to modify these systems for what appear to be good reasons in the short term, but in the long term, these changes only create problems.
Here is my checklist to consider before you modify the system. If your modification doesn’t involve any of these items, you should be OK.
#1 – Fields that Require Manual Data Entry
But wait – this is almost all fields? Exactly. See the title of this blog post. Everytime you create a field that requires manual data entry, you are creating work for someone – your prospects, your sales team, your support team.
If you create 5 lead fields to capture information from the first sales call, with a sales team of 50 people, that connects 40 times per week, you just created 10,000 weekly field completions. At five seconds a field, you just added 14 hours of work to the sales team each week.
Tweet
Don’t add manual collection fields unless you really really really have to. If you have to create a field, calculate the weekly field load number for the organization. Come up with the total number you are willing to tolerate and maintain that budget. Add a manual field, then remove another field.
#2 – Behavior Enforcers
Sales and marketing leadership is notorious for wanting to add fields to opportunity or deal objects to enforce behavior. For example, creating an opportunity requires that you record the “business driver” or “budget amount”, or else you can’t create the opportunity. Or you might be able to create the opportunity, but it is obvious you haven’t recorded the value.
These are just bad reasons to create fields. First off, you can enforce this discipline by asking people to record info in the Notes section of a deal. Second, a hot topic now, may not be hot in 3-6 months as leadership changes and other priorities come into play, the field gets used less and less. Third, sales reps will pick the fastest pick in a list to move on. Use the notes, and enforce the discipline at the manager level when doing account reviews. Hubspot, specifically, has the ability to use snippets to paste into notes. These snippets are incredibly effective implementing your favorite sales methodology.
#3 – Check Boxes
Check boxes are perhaps the worst type of field that a marketing organization can create. The problem with a checkbox field is that unlike say an address field, where the data is generally static, unless the prospect moves, a checkbox is binary and records no meaningful information. It records the state of the company, prospect, or deal at a particular point in time only. If that information changes, unless there is some automated way to uncheck the box, these fields are just worthless over time. Worse, if they trigger workflows you end up with a bunch of checkbox fields that you don’t want to delete least they break something. Avoid checkboxes.
#4 – Fields that Record Duplicate Information
You are holding a webinar and someone wants to create a field that records the webinar name that a prospect attended. This type of a field makes reporting super easy since you are adding a simple field to a record. But, this is an inelegant solution. CRM systems already have a method to record this type of events/calendar data using an activity object. Almost all CRMs have the ability to record completed activity. A webinar is a completed activity. Use the system as designed.
#5 – Fields with No Long Term Value
Ask yourself – “Will this field still be in use in 2 years?”. If the answer is uncertain, then don’t create it. If the CRO demands a field gets created for whatever reason, ask them if it will be used in 2 years. If the answer is “Of course it will”, that is fine, create it, then track monthly usage, and let the CRO know you are deleting it when usage falls before 50%. Don’t build workflows off the field until you use it for 6 months and you see that it is actually getting usage.
#6 – Fields without Queries
One of the main purpose of a field is to pull data into a discrete identifiable block so you can query and summarize the data. Before you create a new field, ask yourself, what query will be run off the field, when the query will be run, and what ongoing report/dashboard this information will show up in. If the answer is vague, then don’t do it. Think through how many dashboards have been created and which ones are actually used. It takes a lot of value to break through the noise and provide information of actual value. If your new field isn’t going to do it, then don’t create yet another field that doesn’t get queried.
#7 – Complex Nurture Streams
If you are a B2C marketer, then you can stop reading this. For the B2B people, I have seen crazy complex email marketing nurture streams that took months to design and implement. Some won awards. At the end of the day, I was never able to prove that they outperformed just a good weekly content distribution email to the entire database. The cost in peoples time and maintenance for these complex streams was very high. When the person who created the streams leaves the company, good luck. Before you embark on this quest, have the team prove through A/B testing that this complexity is really worth it.
Conclusion
Some modifications to CRMs are a good investment. The vast majority are not. Downstream maintenance costs, poor documentation of changes and the workload placed on your end users ultimately makes the ROI highly suspect.