CRM data is a prime example of the “garbage in, garbage out” concept. The better and more well-thought-out your database fields are, the more value they can have to your customer’s journey and business overall.
In this post, we will share 3 ways to supercharge your CRM data. Even if you are familiar with some of these ideas, we encourage you to read between the lines a little more closely.
The devil is in the details.
Automation is merely relationships at scale. This means when it comes to customer journey automation every tiny detail that you miss is amplified. Since any CRM is a set of data tables under the hood, the foundation for these details starts at the database level and extends from there. While it may not be the sexiest and most thrilling work, sitting down and meticulously digging into how you design the data fields in your CRM is the true mark of a professional. When you have a meaningful and designed-for-scale database this enables better automation and internal workflows. In other words, everyone will be happier 😊
Supercharge Your CRM Data #1 – Use The Proper Data Types
There is a bit of wisdom that says something to the effect of, “If all you have is a hammer, every problem looks like a nail.”. The lesson is that if you only rely on one particular tool, in this case, a hammer, you will approach all solutions through that lens which means you will likely miss out on the best possible solution in certain scenarios. When designing your CRM’s data fields, you need to keep this in mind and use the proper data types per field.
Your CRM is programmed to understand different data types and is built to leverage that understanding. When you use the proper data type for a custom field, you can take advantage of the various distinctions around that particular kind of data. For example, when it comes to calendar dates, in your CRM you can search across a range of dates to pull segments of your list and run various reports.
Now, let’s say you want to store date-based information such as the last purchased date. You would be wise to create a proper Date-type field rather than setting up a Text-type field to hold the same information. Why? This means you can pull segments of your list based on a range of last purchase dates. Conversely, if you were to use a Text field to store the last purchase date, the CRM would NOT be able to pull a range of customers who purchased within a particular period. As far as the CRM is concerned, even though a human knows the data in that field means a date, from the software’s context that field is merely a bit of text.
The same thing goes for Number type fields. Let’s say you also want to store the total number of purchases someone has made in their lifetime. This would best be done using a Whole Number type field. Now, you can search the database for a segment of customers with a particular number of purchases. Or more. Or less, depending on why you need that data. If you were to use a regular Text field to store that number you run into the same issue as before. Even though the human knows that the field is storing the total number of purchases, the CRM only relates to that data as a piece of text.
Even custom Text fields are not all created equally. Sometimes, you only need a word or two as a piece of data. Other times, you need full sentences. In those cases, you will want to use multi-line text areas.
You might be thinking, “Well, they are both text so the CRM context doesn’t matter”.
While the CRM context is text in both cases, there are usually different character limits. In other words, a regular Text field will have a smaller character limit than a multi-line text area. When you need to store whole paragraphs, you want to use a larger text box. Especially if that data field is going to be used for internal workflow (see the User Experience section below).
As a general rule, when you are creating custom data fields in your CRM, using a regular Text type should be the backup choice. If you can use another more accurate type of data (Currency, Yes/No, etc.) you’ll want to do that every single time.
Supercharge Your CRM Data #2 – Be Meticulous About Designing The Fields You Merge
One of the most basic “magic tricks” you can pull off with a CRM is merging record data into communications and processes. You know, being able to start your emails with “Hello [[contact.first_name]]…” and then the email that gets sent out has the first name in it. That kind of stuff.
As with most magic tricks, the mechanism behind the illusion is often quite simple. What sells the “magic” is the showmanship and misdirection around the mechanism. Doing data merges effectively is the same principle. The actual act of merging data is simple. Making sure the merged data is clean and seamless is what sells the personalization.
When you merge in the standard CRM fields that come out of the box with the system, there usually isn’t much to worry about. Those fields are already using the proper data type (Tip #1 above). If you are going to merge those into a communication or process, as long as the data itself is clean, you don’t usually have much to worry about. For example, unless someone has their first name in all capital letters in the database, you can safely merge the first name into an email without issue.
The challenge arises when you need to merge your custom database fields. For example, if you are selling cars, you might want to have a custom CRM field with the car’s make and another field with the model AND THEN you will be using this information in follow-up.
How you design these fields is critical to making sure that merges work seamlessly. Generally, you want to minimize the possibility of human error as much as possible. Keeping with the recommendation from tip #1 that a text field should be the backup type of data, when doing custom fields for merge purposes you want to see if there is a way to have fixed values. Continuing with the car example, instead of having a text field for the make, you can have a dropdown field with Honda, Toyota, etc. However, doing fixed values for all possible models would be unreasonable. In that case, you would likely have to rely on a text field.
Even if you are using fixed values, you need to make sure those will merge properly into a communication or process. Which means you need to factor in things like capitalization. Let’s pretend that you have a coaching program that does both in-person and virtual coaching. If you capitalize those values as “In-person” and “Virtual” in the field, that might look goofy when merging into an email.
For example, “I look forward to our Virtual meeting tomorrow”. The fact that virtual is capitalized for no reason is weird. If you know that you want to directly merge in the field value, you would be wise to simply have “in-person” and “virtual” for the field options.
Sometimes, you HAVE to use a text field or a capitalized fixed value. And that’s ok. In those cases, do everything you possibly can to ensure that the human using the field KNOWS their entry needs to blend into a message seamlessly.
The Follow Up Intro has to be a multi-line text area because this is always going to be unique to the mentoring call. However, the context of the follow-up email around the field tells the user that their entry will be a separate section, which means they should be using proper grammar and full sentences.
Or, if you are using a fixed value, you might have to use some dynamic messaging content to condition a capital to a lowercase. Which, IMHO, is worth the effort. Good automation does not feel automated. So if you have to do a small bit of programming to guarantee a message or process is presented smoothly, that will ensure the best possible experience.
The same goes for date-based fields. If you need to merge a date to a message or process, you almost always want to condition that information into a human-friendly representation of the date. For example, instead of saying “Your appointment is confirmed for 05/31/2024” (which sounds like a robot), you would be much better off with the message saying “Your appointment is confirmed for May 31st”. It simply feels better!
As a general rule, when you are creating custom data fields that you KNOW are going to be merged into a communication or process, do everything possible to ensure that data is going to look good after being merged. Whether that means factoring in capitalization or conditioning on the data to display nicely.
Supercharge Your CRM Data #3 – Organize Your Fields For The Best User Experience
All too often, we have seen clients that have wonderful, amazing automation from the client side. But the experience for their team inside the CRM leaves something to be desired. If you ignore the internal User experience, you are missing half the equation. (Side-Note: We do provide consulting services if you want help streamlining your internal user experience.)
The easier a User can navigate and understand all the custom data in your CRM, the better. This means that when adding custom database fields you need to take special care to how the fields themselves are named AND how they are organized.
Look this following cluster of custom database fields:
There is no rhyme or reason to what these mean, nor how they are organized. There are also redundant fields with the default CRM-provided fields such as Country and Person Type.
You’ll notice that many of these fields are single lines of text when some of them probably could be a fixed value dropdown (e.g. practice management software and person type). Also, while there is a # of locations, that is not an actual Number type field, so we are losing out on being able to use that data in a meaningful way. There also appears to be a few different groups of fields here all bunched up together. We have some appointment data and results, referral things, a general ‘How can I help?’ field, a sales process field, etc.
If this person’s team needed to find data quickly, how easy do you think this would be for them? (Answer: not easy)
Even more of a problem: how easy do you think it would be to on-board and train a new member of the team? To train up a new team member, would require a lot of tribal knowledge from the existing team. Which doesn’t scale.
Conversely, look at this well-organized set of meaningful custom fields:
Not only are the fields clustered with meaningful headers, but every field type is also meaningful based on what the actual data is, and the names clearly explain what each field is used for. For example, “Number of Lifetime Purchases” is an actual Whole Number field so that the CRM can be segmented by number of purchases. There are also a few Website type fields (with the blue arrow) so that way Users are one click away from relevant endpoints outside the CRM.
How much easier do you think it would be for Users to pull data from this set of fields? So much easier!
To provide the best User experience, you would be wise to be thoughtful in how you cluster your fields and design each field name with care. If the average person on your team cannot simply read the name of the field and understand what kind of data they should expect to see, you have done it wrong. The devil is absolutely in the details here. For example, look at the field name “Latest Monthly Retainer Report”. By subtly starting with the word “Latest” that gives critical context to the User that this field is overwritten each month.
When you are creating custom data fields you need to design the names and organize them with a User-first approach! Do not get lazy here simply because a client or prospect will never see this part of your business. You owe it to yourself and your team to make these fields as easy to understand as possible.
Free Resource – Download Our Database Structure Planning Tool
Whenever we are building automation that requires custom database fields, we follow our advice!
We developed a database structure planning tool to ensure that there is one source of truth between the team when building the automation. This tool ensures that we clearly define the field organization, names, data types (along with any fixed values), and where these fields show up, if applicable.
You can also use this tool to audit your existing custom fields by documenting what is so in your CRM. Then, you can use that audit to improve your CRM data.
👇 Get Your Ready-To-Use Database Structure Template Below 👇