Getting to the Truth of one database
One Database to rule them all.
One Database to find them.
One Database to bring them all
And in the darkness bind them.*
A beloved former boss of mine once asked the best question I’ve even heard and may ever hear about databases: “Which database is going to be the Truth?”
Others may call this the database of record, but the Truth is far more evocative. It encompasses “which database will have all of our people?”, “which database will have all of our donations regardless of source?”, and “which database will be the arbiter and tie-breaker for all constituent record issues?”
This is a necessary pre-condition of donor knowledge. You will not have true knowledge of a constituent of all of your data isn’t all in one place. And working on donor information without the backend systems to back it up could be a waste of time and effort.
If you are like most nonprofits, you are either laughing or crying at the discussion of one database. You likely have a few different donor databases by donation type. Then you have records of people you serve, your email list, your event attendees, and so on.
And, sadly, some of them are necessary. Some databases do things that other databases will not do. You may not be able to run your direct mail program out of your online database or vice versa.
So here are some steps you can take to get all of your information in one Truth even if there are multiple databases behind it:
Purge unnecessary databases. And I mean purge them. Ideally it should be as if your unnecessary database displeased Stalin: it just disappears from history, incorporated into other people’s stories. To do that:
- Ask whether another database can do what this database does. If so, bring the data over and train the relevant parties. The good news is that often the rogue database in question is just an Excel spreadsheet that can be directly imported into your database of choice.
- Ask whether another database can do what this database does with modifications. Rarely is something perfect initially. You will likely have to create reports for people that they are used to running, but if you are bringing them into a good database, that’s a matter of business rules and set-up, rather than technical fixes.
- If not, ask if the person can do without what the database can’t do. You’d be surprised how many things are done because they have been done rather than for any rational reason.
Assuming that you have some databases that can’t be replicated in one big happy database, decide what database is going to be the Truth. This should have the capacity to store all of your fields, run reports, and do basic data entry. If you are keeping your direct marketing database, it doesn’t need to be able to run a direct marketing program. But it does need to have the capacity to do the basic functions.
You may say that you don’t have a database that can fulfill this function. In that case, I would recommend what I call a Traffic Cop database. This is a database that you can inexpensively put in the center of multiple databases and get data to and from the other databases. It’s job is to make sure every database knows what every other database is doing and existing to pull out duplicates and host change management.
Now, sync the databases to the Truth database. Sometimes you may be fortunate and be using a database that has existing linkages. For example, if you have decided that SalesForce is going to be your Truth, there are some pre-existing syncs you can get from their apps. If not:
- Start by syncing manually. That is, export a report from one database and import it into the other. Then, reverse (if you keeping a database, syncing it has to go both ways). This will allow you to figure out what fields go where and more importantly how to translate from one database to the other (e.g., some databases want the date to be formatted 01/18/2016 and woe be unto you if you forget the zero before the one; others may not having a leading zero or have month and date as separate fields or the like).
- After you have your process down, you can automate. This can happen one of two ways: through the database’s APIs or through an automated report from one database that uploads to a location followed by an automated import from the other database. Both are viable solutions — you would generally prefer the API solution, but you do what you have to do.
- Make sure you have an effective deduplication process. It almost goes without saying (and if it doesn’t, check out our PSA for data hygiene here), but data can get messy quickly if you don’t have these in place.
Here are some of those common objections and the easiest replies:
- Cost: “how can we afford to take on a database project?” Answer: how can we afford not to? The lost donations from people calling you up asking for a refund and you have to look through five different databases to see where they donate. The extra time to try to reconcile your donor database and financial systems. The data that you won’t be able to get or use for your direct marketing and the lost revenues from that.
- No direct marketing constituents: “I don’t want X (usually the people we serve) to get hit up for donations.” Answer: We won’t be able to guarantee they won’t get a solicitation unless we know who they are. We rent acquisition lists all the time and these people could be on there.
- We’ve already invested in this other database: Answer: point them to this Wikipedia page. It’s easier than trying to explain sunk costs on your own.
- Provincialism: “We have database X and it works fine for us.” Answer: actually there are three answers for this one. First, start elsewhere. Usually, someone will have a database that isn’t working for them and better you start with them, who will then start singing the praises of both you and the Truth, than with the people who like where they are currently. Second, usually, there is an “I wish we could do X” list somewhere that will make it worth this person’s time to switch. Third, go to the highers-up with your business case. By this time, you hopefully have some happy converters and some results from your direct marketing program (e.g., “we can put the year someone started with us on their member card now!”) to share.
Hopefully, this helps you get to your own version of the Truth.
To preview the original blog go here.