What’s the best way to store family and household information on your constituents in your nonprofit database? Constituent data, especially personal data pertaining to prospects, donors, patrons and friends is often stored differently in an advancement database than it might be in a typical for-profit business customer database.
Most small companies keep records for customers as completely single entities. There is usually very little effort to recognize family members or spouses living at the same home address because it isn’t all that necessary. This makes sense in most cases because customers often make purchases as individuals, not as couples or families.
But for non-profits, this can lead to wasted mailings and annoyed donors.
Let’s considered what happens if spouses Roger and Mary Smith both frequent a local (privately owned) auto repair ship. If Roger Smith brings in a 1994 Toyota for new tires and Mary Smith later drops off a 1996 Chevy for an oil change there usually isn’t a strong effort to find out if those two people are married. There’s no real reason to. Both services are individual services performed on individual cars owned by individual people. One person, one transaction, one car.
If the auto repair shop wishes to mail out a coupon for a free car wash Roger and Mary may both get a coupon sent to the same house in their name.
In the world of Advancement Services most experts recognize that people who donate money or volunteer their time do so with the knowledge or backing of the entire household. Whether it’s being a parent of a student at a non-profit college, supporting your local community theater or even just giving $10 through a charity direct mail piece, both adults in the household are often involved. It makes sense to recognize the entire household (or at least the primary decision makers) in a household or family when it comes to soliciting for and promoting your organization.
So how should an Advancement Services office organize spouses, families and households in a database? There are three basic scenarios that I’ve seen:
Option 1 – Each Record is an Individual, No Households
Good For: Small organizations with limited staffing or a simple constituent database.
Positives: Easy to maintain – one address for one person.
Negatives: Difficult to identify family groups. May increase postal expenses with double mailings and likely to bother households who don’t want multiple mail pieces.
Some organizations are only concerned with individual people and never even try to keep track of households. Mailing companies can remove duplicate addresses for direct mail solicitations (reducing postage costs) and there’s the added bonus of not needing to worry about marriages, divorces, family changes or anything else other than where each person might live. This system also makes it easier to keep other personal data more accurate such as cell phones and email addresses, though you could have some information on one spouse’s record that doesn’t get shared on the other record when it should be (home phone, a son or daughter, etc.). One person’s record holds all the contact information that’s known for that person. Our auto repair shop in the example above would use a system like this.
Option 2 – Each Record is A Couple, All Households
Good For: Small to midsize organizations that are more “family” centered. Religious institutions and nonprofits that deal with families on a “household” or “home” level might also choose to keep track of households rather than individuals.
Positives: Creates less overall records, easy to contact a full household.
Negatives: Difficult to split out individuals in a household if needed for querying purposes. Changing households sometimes becomes tricky.
Here’s the exact opposite scenario of keeping records. Each record in the database stands for one “household” or family. So we might have a record for “Robert Smith” and if we later find out he is married we would change the record’s name to “Robert and Mary Smith.” If they had two cars then both cars would be tied to that household. This system has some advantages in that you reduce your number of duplicate addresses that you mail to, you have less records to technically maintain and it’s easy to find information for one person (just check the person’s entire household record).
On the downside, you lose a lot of flexibility with this. You can’t easily solicit individuals. You can’t easily recognize certain people as being more important than others in a family or relationship. And when families break up or change it often requires making new records and then splitting combined data out into the two individual records.
Option 3 – Each Record is an Individual, Connected by Households
Good For: Mid to large organizations with a professional constituent database and professional database management staff.
Positives: Easy to switch between individuals or families with mailings and queries. Offers the most flexibility for a growing organization.
Negatives: More constituent records to maintain and more complexity between those records. Sometimes have the choose an arbitrary “head of household” record.
This is a mixture of the two other options. It’s the most complex to maintain, but it’s also the most flexible when it comes to being able to use your constituent data in a meaningful way. In this data structure each and every individual is kept as a single record, but there’s an added “relationship” which ties the two people together and often identifies a primary person in the household. This is also called householding, marrying or simply joining individual records together into one family unit.
You can avoid duplicate mailings to the same household by filtering on the household relationship rather than the individuals. If you happen to have two family units living in the same household (perhaps a couple shares a home with their married child) then both those family can receive one mailing to the same address.
When you have a record for each adult individual in a household you have to constantly be updating relationships, marriages, shared addresses and other information that regularly changes. Likewise, if you are using prospect scores (and you should be!) then you will probably want to make sure that both spouse records have the same score. Yes, maintaining this sort of system is more difficult and requires a greater effort and attention to detail. That being said, there are many, many advantages to this system.
You can solicit individuals (think of Alumni Offices where one spouse is an alumnus and the other is not) or you can solicit couples (invitations to a Gala Dinner and Dance). You can maintain household data such as mailing address and home phone number, but you can also enter personal cell phone and email addresses for individual records. If you currently have a record for Robert Smith and learn that he was recently married you can simply add a new individual record for Mary Smith and then join or marry them together, linking them into a household. If they get divorced you can simply remove or put an end date on the marriage link and they will be contacted and solicited as individuals again.
In my experience a lot of organizations still use the first and third option, with a lot less non-profits and fundraising institutions choosing to use the second scenario any longer. Twenty years ago a lot more organizations were commonly grouping families into a single record, but as fundraising databases have grown more sophisticated and more user-friendly over the years there is no longer a real reason to stick with this model. Some smaller organizations may start out with the household data model, but they generally move to an individual record system once they grow to a certain size.
This is where a dedicated advancement services staff really makes a difference. They would be people who can professionally handle this data complexity and ensure consistency in how your records are coded.
I’d love to hear of other options and the problems you face with maintaining household records. What householding method does your organization use? Does it work well? Let us know!