Database Best Practices, continued (It Depends, Part II)

In my last post, I discussed some best practices for the data entry in fundraising databases: keeping your data coded, simple, reportable and retrievable, and using common sense to guide your data entry decisions. And I promised to explore how you decide where to store specific kinds of data, and where else you can turn for specific solutions.

Most database packages will offer lots of fields, tabs and tables for you to populate with rich data about your constituents, gifts, memberships, volunteer jobs, contacts, events, etc. Some databases offer optional modules to track special events, grant proposals, and other information, and most databases will offer a number of “user-defined fields” (UDFs) – fields you can label and define to accommodate your specific business practices. And all of these options can be overwhelming.

So, begin with the easy decisions, the sorts of decisions which involve nothing more than coding your data so that it is easily reported and queried. This includes where and how to enter names, addresses, salutations, and gifts. Locate the place to flag anonymous donors; if one does not exist, use a user-defined field and select one which is easy to locate. Identify a user-defined field to store the name your donor wants to be printed in the annual report (if that applies to you). Then document these decisions and do not waver from them.

Will you ever need to query and report on all gifts to a fund by year? Or on every gift to a particular fund? Probably – and so you will need to decide whether to embed your fund codes with dates – OP14 – or if you can query using a gift date range. If you do use embedded dates in your fund codes, keep those dates consistent. That way you can query and report with wild cards to find all the gifts to the Operating fund – OP* – or all the 2014 gifts – *14.

Some of the most important data will be captured in your contact reports and moves management. Most fundraising databases will have a dedicated area for this data – for example, in The Raiser’s Edge it is kept on the Actions tab. The information you enter here not only creates an archive of your prospect’s relationship with your organization, it can also provide a rich trove of data for later data mining. The easiest way to approach coding contact reports in your database is to follow the solicitation cycle (identification, qualification, cultivation, solicitation, stewardship) and/or the grant cycle (letter of intent, proposal, progress report, final report). Don’t forget to have a few loose categories for those gray areas! Many of the contact reports you enter will begin life as calendar ticklers for meetings, phone calls, proposals and reports. Once the meeting or phone call takes place, or the proposal is submitted, don’t simply close or complete the record. Take the time to record what happened in a Note field – your database should provide a way to tie Notes to the contact report.

As I said, your contact reports can be data mined to great effect. Want to find funders for a new initiative? Think of key words tied to that initiative and search the notes in your call reports. For example, if you are building your first soccer field, search the call reports for mentions of soccer. This relatively simple query will find soccer parents, former soccer stars, perhaps even identify prospects who loathe soccer. Something which came up in casual conversation years ago, before soccer was ever on your radar, could suddenly become the key to finding a major donor! But that won’t happen if you don’t record the notes in the first place.

In my last post I also promised you some other places to turn for help:

  • Want to find a local consultant and your search engine just isn’t producing any results? Try an advanced search on LinkedIn, using the name of your database as the key word, and narrow the results with your zip code. It’s not necessarily the slickest tool, but you should find a few names to connect with, who may not have a website that would show up in search engine results.
  • Have a specific question but you don’t know where to turn? Join a listserv and post your questions. Gift processors often turn to FundSvcs, prospect researchers to PRSPCT-L, and data analysts to Prospect-DMM, but there are listservs for every aspect of philanthropy, and many can be found on Most listservs will let you lurk before you post, and this is a great way to discover tips and resources you may not have thought of on your own, and new people to connect with.
  • Use social media. Join a relevant group on LinkedIn – something tied to your database vendor, or to your niche in fundraising – and post your question. Tweet your question.

Each of these approaches has the potential to widen your professional network. And, perhaps the next question you see will be one you can answer!


It Depends…..

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.”