I read a post on the Idealware blog today that had the title ‘Multiple Constituent Groups, One Database? How to Track Everyone Who’s Anyone to You’ that laid out a nice method for analyzing the relationships between different groups of constituents and then went on to conclude:
‘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.’
I’m writing this post to rebut this argument from the perspective of a non-profit that is moving to do exactly that – create a single database for managing multiple groups of constituents – and some suggestions for how and why other non-profits should consider doing exactly that. In fact, I would argue that your default position should be to use a single database and only consider having an additional one(s) in extreme circumstances.
Back in June, I posted about how we’re currently using Salesforce.com at Citizen Schools and laid out the different types of constituents that we’re tracking in the system (current staff, volunteers, staff alumni, current students, student alumni, leads for potential staff). Since that post, we’ve brought all of our donor infomation into Salesforce and also begun tracking key district and school partner contacts as well. We’re currently planning on bringing all other constituencies under the Salesforce umbrella over time.
So what’s the value proposition for bringing everyone into one system. Here are a few important ones:
- One system increases reduces training costs by providing a single interface for users. Forcing users to move between different systems to accomplish tasks is inefficient and confusing. With multiple systems, users need to concentrate more on where they are working and switching between applications, rather than just logging in to the system and working in it all day. Additionally, given the number of ‘hats’ that typical non-profit staff wear, having one system allows all users to know how to use that system to access data even if it’s not their primary job, or to transfer within the organization and not have to learn a new system on top of new job responsibilities.
- Having all the data in one place gives us the opportunity to reach out to different constituencies as needed. Earlier this year, when Americorps funding was threatened in Congress, we needed to reach out to all of our constituencies with a call to action. Because we did not yet have all of our donor contacts in Salesforce, the process of gathering the list to do our outreach was significantly more complicated. A single source allows you to segment your lists much more effectively rather than having to pull segments from multiple systems and then compile.
- Reporting from one system is vastly simplified, particularly when it comes to getting data for funders. You’ve had to deal with it, a proposal for a funder that wants to know everything about your business, from number of (clients/students served/etc) to the number of donors and revenue data for the last ten years. One system makes it easy to get at that information.
- Finally, constituents are rarely static; they have a history with your organization and their relationship with you will change over time. A client may turn into a donor, or a donor to a volunteer, or a volunteer to a key advocacy or policy connector. Maintaining their history in multiple systems means you never have a complete view of the constituent’s relationship with your organization, which means that anyone trying to do outreach to them is operating at a disadvantage. Additionally, building and maintaining integrations between systems is a complex process, taking resources that are either hard to come by, or if available, could be better deployed adding business value (I know this from experience).
So how does Salesforce.com (or another single database system) allow this to happen. To me, the answer lies in the flexibility of the platform. Fundamentally, regardless of the complexity of a constituent’s information, there is a core set of data (name, address, email, contact/do-not-contact status) that’s going to be captured. In Salesforce, this would be maintained in the Contact object (and most of those types of fields are already built in). Your additional data would be reflected either as additional custom fields on the Contact, or as related records (for example multiple records of a constituent’s volunteer experiences). The wonderful thing about the Salesforce platform, is that all of this configuration can be done without writing a line of code or involving your technology team/person/consultant. When you need to add fields, it can be done in minutes, by anyone with the requisite administrative access and training, rather than relying on your overworked tech folks.
‘But’ you say ‘I don’t want to have to see empty fields of volunteer related data when I’m looking at a client record!’ Never fear, Salesforce allows us to define different views of the data by creating different page layouts for different types of records. Additionally, these page layouts can be limited by a user’s role and security profile, so you can segment access to data within the same system. This works really well for reporting, as you’ve got your core data accessible from one location, as well has having your constituent type-specific data accessible to authorized users.
You also gain the advantage of having one interface with a common set of tools and usage conventions to learn, accessible to any computer, smartphone or tablet with access to the internet. Increased accessibility and ease of use reduce barriers to adoption and usage, which in turn leads to better data completeness and quality. Try getting that with all of your multiple systems!
Penultimately, there’s the question of cost. Salesforce gives you your first ten seats for free and offers a substantial discount for all additional add-on products. This can still add up to a substantial amount for a large roll-out, but when you compare the costs of purchasing or building multiple systems, hosting them internally or externally and maintaining them, you’ll find the total cost of ownership equation to be in Salesforce’s favor.
Finally, there is a vibrant ecosystem of add-on applications on the Salesforce AppExchange, many free or discounted for non-profits, that can be used to enhance your organizations processes, as well as a solid core of consulting partners who can assist with more complex implementations.
To sum up, there may, in fact, be cases for having more than one system, but you should evaluate the business case very, very carefully and truly assess the costs (dollar, time/efficiency and opportunity) before heading down that path when compared to the costs and benefits of the Salesforce option.