Fundraising and databases aren’t always easy friends. Databases, after all, are binary – every data point is essentially a combination of yesses and nos, trues and falses. Fundraising, other hand, exists in gradients and increments, in the kind-of/sort-of world of relationships, affinities, and transformations.
Ask a database vendor the right way to do things, and their response is more than likely to be “it depends.” That’s not because they don’t know the database inside and out, but because the best fundraising databases, right out of the box, will only ever approximate your organization’s business practices. How you have overlaid the database software on your fundraising culture is likely to be very specific to your organization. The best vendors know that what is good enough for you may in fact work only for you, and what works best for someone else will never fly in your office.
That does not mean that there aren’t any database “best practices.” Just that these “best practices” won’t be data entry rules or query prescriptives that a vendor simply hands over to their customers. The most basic thing to keep in mind is to keep your data consistent: coded, simple, retrievable and reportable, and to follow common sense.
Consistent data is more easily queried, makes data entry quicker, and keeps the post office happy. Consistent data follows a set of rules, like the rules for addresses, which can mitigate the need to make ad hoc decisions leading to sloppy data.
Coded: Codes and table-driven data entry drives data consistency while eliminating error and saving time. At the very least, your database should have a set of fund codes (and, yes, how you build those codes will depend on you!), constituency codes, codes for any “type,” “status,” and “category” fields you have elected to use, rating codes and many more. A general database “best practice” is to limit who can create and edit those codes, and to be sure the codes themselves follow a set of rules in how they are structured.
Simple: Keeping those codes simple will have a great many pleasant ramifications for you. Think about the state codes used by the post office: why type “Wisc” when “WI” will do the trick and is enough to distinguish Wisconsin from Wyoming, West Virginia and Washington? Simple coding structures will have a small impact on the size of your database, but more importantly they will make reporting, querying and data analysis much easier.
Reportable and Retrievable: Perhaps most important, consistent data is more easily reported on and retrieved. A general “best practice” rule to help you develop consistent data entry procedures is to always think first of how you want to get the data back out. What reports will you want from the data you are entering, and how will you want the data on those reports to be selected, sorted and formatted? Will you be creating mailing lists or other data segmentations based on data elements your constituents have in common? Will you want to do data analysis and data mining – will your data allow the use of wildcards, can calculations be performed on it and/or scores derived from it? Will you be pulling database fields into mail merge documents, how will you want those fields to look, and will you be applying conditional formatting in your mail merge? For any of these data retrieval needs, how do you need to have data located in different areas (tabs, code tables) of the database to interact?
Common Sense: But it is also important to use common sense when developing consistent coding and data entry rules. For example, if executive bios are always entered in a Note field with a description or type (pulled from a code table) of “Exec Bio,” they can be easily included in a database report or profile based on that common, consistent data element, and the report can be designed to locate the bio in the same place for every constituent. If you have also developed database rules governing the data entry of those executive bios, a pile of profile reports will be easier to read – the data will always have the same basic types of information in the same place. On the other hand, you may not be capturing executive bios all that often, and they may never be reviewed in a large group. In that case, you may not want to spend the time and energy to develop a standard format to capture the data, and the time and energy to enforce data entry which subscribes to those rules. In that case, the database rule you may wish to develop is to copy the bio from the source, to include proper attribution and the date captured, and to spend a minute or two editing it for clarity. Enforcing data consistency must always be tempered by common sense and informed by your fundraising culture.
Finally, a key component of consistent data entry is to decide which fields and tabs in your database are used to capture which data elements. The more complex your database is “out of the box,” the more difficult that decision making process can be. Plotting out how you foresee retrieving the data is the most important first step. One more fundraising database “best practice” which can help guide those decisions is to distinguish between the data elements which describe your prospect and the data elements which describe the prospect’s relationship to your organization, and to use those distinctions to design where each data point should go. My next post will explore these differences and how they can help you develop database rules and procedures for your organization, and where else you may want to turn when you need help and your vendor says, “it depends.”