Configuring vs customizing data in your CRM

Welcome to my weekly LinkedIn newsletter! Connected Fundraising Weekly will be my way of providing easy-to-engage insights around donor behavior, fundraiser enablement, and technology. I hope you enjoy the content, and please share if you think someone would benefit from what I'm writing!

One of the most exciting yet potentially damaging ways a database can be implemented is by changing the parts of the system that either come with it or choosing to make new sections. Many off-the-shelf CRMs are going to have some standard settings for the fields that they give you as well as the options within those fields.

In a previous newsletter, I covered some of the ways that nonprofits can think about configuring their tagging system for segmentation and audience-building purposes. What I'm going to do is take that a step further and focus on an individual's record and what I think a nonprofit can do when thinking about the personalization of its database to its mission.

This comes down to a question I keep seeing come up:

How can I customize it?

You need to ask a different question first:

Should I configure or should I customize?

Configuration vs. Customization

The primary difference between configuration and customization is what is being modified in the database. Most off-the-shelf CRMs in the nonprofit sector are going to have people-focused records that then have a standard set of fields within them.

Database Field Basics

Let's take a look at fields in a little bit more detail because I think this is one that really gets overlooked when people are thinking through their database. When you have a field, that is a part of a record within the database that tells you a piece of information specific to that record. An example of this would be a person's first name.

Within the field, you then can have options for how the field is set up. A person's first name is typically going to be an open text field that allows anything to be put into it. Open text fields can be either short or long in the amount of information that is allowed to be put into them (e.g. character limits). First name fields are typically going to be short because if it had the option to have a lot of information put into it then it's going to look really weird when you're putting it into a mail merge.

Yet, there are other options for how fields can be set up. You can have a checkbox that has many different things that you can choose from at the same time. You can have a radio button that forces the user to only choose one of many options. The field could be forced into a specific format, such as being a date field on a calendar.

Field structure is going to become extremely important when we talk about configuration versus customization.

Configuration

So let's go back to the core question of what's the difference between configuration and customization. It comes down to the field itself.

Let's say you are going through the sales process and you're allowed to take out a trial of the database itself to test it out.

So you get into the database and you want to set up a test record. When you go and enter the basic information into it for your test record, there may be some required information that you have to enter and there's no way to change this.

But what about other things, such as a prefix field? It may be a drop-down of options. And within that drop-down, you may be allowed to change those options. Yet, the actual field itself is something that you can't touch when you go to the primary settings that the database administrator has the ability to change.

This is the simple definition of configuration. You have standard fields within the database but you can change them to personalize them for your needs.

Things like what you call relationships in your database, salutation and prefix fields, and gender fields are examples of flexible configuration.

Customization

Let's say for the purposes of our thought exercise today, you are an animal shelter. You look throughout the trial database settings and you see nothing that really speaks to the understanding that a person not only adopted an animal but what the animal's name may be and the date that they may have adopted the animal.

We are now into customization territory.

Customization of a database is when you are allowed to add fields or (with certain vendors in the market) entirely new data objects to the system. For our sanity, we are only going to talk about adding a custom field to a person's individual record.

Custom fields can be pretty great but this is also where things can go haywire. When thinking about custom fields, ask yourself what is the intention of why you need to add a custom field. Look at how you were going to name the custom field, how you are going to choose to configure the custom field, how you were going to report on the custom field, and how you are going to actually use the custom field in things like communications.

I really want to stress that if you are going to name a custom field literally the same thing as something else already in the database then you are setting up your database poorly.

Custom fields are some of the best tools in your toolbox for creating a truly personalized donor experience, but they need to be thought out with care.

How to configure your database like a pro

No matter what, your organization should be mapping out what experience you want donors to have when they interact with any potential for donating. So let's start simple and think about online donations.

Understanding how your online donation form interacts with the fields in the CRM is a critical first step. Reviewing how different fields that are standard with the database flow from a form into the administrative back end is an easy way to start.

What is the standard information that you always want to collect from somebody? Then see if there are ways that you can configure those standard fields to ensure that it speaks to the audience that you actually serve.

Example - will you be doing anything to celebrate a donor's birthday? If you have a stewardship touch point around a birthday, such as sending them a happy birthday postcard, then consider adding birthday to your online donation form as an option and seeing if you can configure the form to let the donor know you are collecting that information because you will send them a special message.

How to customize your database like a pro

So let's continue using our birthday message example. What happens if you review your database and for some reason, birthday is not an option in the standard fields, but you can add custom fields from the back part of the CRM into an online donation form.

Explore if you can configure a date field and then call that date field Birthday. You then have created a custom field that has a useful purpose within the database itself.

And since your organization has taken my advice and performed a full audit on how custom fields can be reported and messaged around, you are now good to go.

This is a vast oversimplification of an extremely important part of database management, but I've seen too many databases go awry because this part of their operations has not been fully thought through.

Let me know some of your favorite honest-to-goodness custom fields that you rely on for stewarding your donors around a retention strategy.

Are you going to be at?AFP ICON next week? I have printed copies of the Neon One donor report that look absolutely stellar. Limited time run so let me know if you'll be in Vegas next week and I can hook you up! I'll even autograph it to decrease its value.