Multiple Constituent Groups, One Database? How to Track Everyone Who’s Anyone to You

Since most organizations don’t track just one type of constituent, the idea of a single database for all of them—donors, volunteers, clients, email subscribers, advocates and everyone else—is something of a holy grail. The ability to easily see how all your constituents interact with your organization, and with each other, makes for an attractive, ideal vision of what a database should be. 

In reality, a single constituent database usually means some sort of compromise. If your nonprofit tracks a wide variety of constituents but doesn’t need very deep functionality in any particular area, it’s feasible. But if you need to keep tabs on more complex data—like tracking stock gifts from donors, matching volunteers with volunteer opportunities based on interests and availability, and the case notes, histories and outcomes of the mental health services provided to clients—you’re not likely to find a single system to fill all your needs.

If there’s not much overlap between particular constituent groups (for example, your clients aren’t likely to be donors, and your donors aren’t likely to become clients), there may not be enough of an upside to a single database to make it worth your while. For many organizations, multiple systems can be a better fit.

But how do you determine which is the right solution for your nonprofit? We’ve designed a short exercise to help you decide. 

Know Your Audience

The first step is to identify all the constituents you deal with on a day-to-day basis. These are the people you need to track. It’s likely you’ll have not just donors and clients, but volunteers, alumni, event attendees, partners, press contacts and other groups. Include them all.
Then, choose the constituent group that’s most important for your organization to track—we’ll call them your “Critical Constituent.” For most organizations, this will probably be either donors or clients. (If you have two or three key constituents, you can repeat the exercise for each, but choose one to start with.)
For each of the other constituent groups you identified, determine:
  • Their relationship to your Critical Constituent—how likely are people in one group to be in the other? Might they move between them?
  • The complexity of thedata you need to track for them in addition to what you’re already tracking for Critical Constituents—the basics, like name, address and contact information, is probably the same for both, but there’s likely to be additional information.
Using donors as the Critical Constituent for our example, let’s compare them to volunteers as the other constituent group. Are volunteers likely to become donors, or vice versa? Might a volunteer also be a donor? Neither scenario is unusual for many organizations, so we could call these two constituents highly related. As we consider other constituent groups—press contacts, for example, or legislators—we’re likely to find far less overlap.
Next, let’s consider the complexity of the data we’ll need to track for volunteers that we don’t already track for donors. This might include the types of projects they’d like to help with, when they’re available, and their history volunteering with the organization. Because there are more than a few additional fields, this falls somewhere between medium- and high-complexity, depending on the specifics.
Once you’ve defined how complex and related each constituent is, plot your constituent groups on a chart for a look at your overall constituent picture.

Read Between the Lines

What can you learn from this constituent picture? Let’s say your groups mostly cluster toward the right side of the chart.  This means you don’t have extensive additional needs on top of what you already track for Critical Constituents, and tracking them all in a single database almost certainly makes sense for your organization. You should be able to customize a database optimized for your Critical Constituents to fit everyone else, too.
But what if you have a cluster down in the lower left hand corner that shows you have some difficult-to-track constituents that aren’t particularly related to your Critical Constituents? 
You’re unlikely to find a system that effectively supports substantial functionality for both types of constituents, and given how little they relate to each other, there may not even be much benefit in trying to shoehorn them into a single database.
In this case, you’re probably better off with more than one database—but how many do you need? Remove the Critical Constituent from the equation and repeat this exercise just for the constituents grouped together in the lower left hand corner. Are they related to each other? Do you need to track similar data for each of them? Again, if they don’t overlap significantly, more than two databases might make sense.
Things get more complicated if you have constituents floating in the middle of the chart, or even worse, in the upper-left corner. If that’s the case at your organization, start weighing the possibilities and tradeoffs. It might prove difficult to incorporate these constituents into the same system as your Critical Constituents. Is it worth the effort and expense? Consider whether multiple systems can be integrated so key data flows from smoothly between them through an automatic data feed. Integration is often expensive and complicated, but it can be a great solution to thorny data problems like this. 

Wrapping it Up

The vision of a single database is attractive, but the reality might be neither practical nor cost-effective for your organization. Should you track all your constituents in the same system? Only if it makes sense for your particular situation. At the end of the day, that’s not easy to know.
If there’s a compelling reason to combine everything, and the benefits outweigh the risks and cost, the dream of a single database is a viable possibility. But achieving that dream requires some strategy and forethought—otherwise, your dream of a single database might just become an implementation nightmare.

Read our case studies illustrating this article, which was originally published in the December 2011 issue of the NTEN:Change journal


Outlook Integration I'm reconciled to the idea that I may not be able to have one database for all needs, but I do have two questions: (1) Is SalesForce powerful enough to fill this need?; (2) If nothing can fit the bill, the alternative I'd like would be to have a simple database to manage just contact information (not interactions) which would integrate into the back-end of my Outlook Exchange (Office365)...Is that possible?