Monday, November 05, 2012

Do Generic CRM systems make "Volunteer Developed" databases a viable option now?

Volunteer Corral Building 
Historically, I have never promoted volunteer developed fundraising databases (as much as I respect the time, effort and great intentions of such volunteers). i.e. taking MS Access, SQL Server et al and creating a fundraising system from scratch. But with the recent availability and flexibility of the generic CRM systems (MS CRM, Salesforce, CiviCRM et al), I am wondering if there is now a new 'volunteer developed' model which smaller charities can instigate.

My concerns historically about volunteer-developed databases are based on fundamental issues with such an approach. For example: volunteers may not understand fundraising or fundraisers' needs and thus not design systems in the most appropriate way; volunteers may not be around tomorrow to maintain, change and improve their databases; volunteers may not provide on-going support or training; the system will probably be a bespoke development and will therefore only provide what the charity wanted at that time; and the underlying database may need to be upgraded but without anyone to do it.

And equally important, such approaches are almost always re-inventing the wheel. Traditional fundraising packages have been available for 20+ years, and even if some are expensive, with fundraising packages such as KISS Software costing from only £100, why would you consider bespoke development for small charities' fundamental fundraising needs. Indeed, I know many NFPs who have started with volunteer-developed databases but have found such systems stopped being useful, even to the extent that they found they stopped using them any more in their organisation.

However, as per my introduction above, with the 'new' generic CRM systems, this may be something we can now review.

The reason for this is because of the cost structure of these systems and the central core of their data models. Cost-wise, the software prices of CRM systems such as these are very low indeed; e.g. CiviCRM is open-source, Salesforce offer NFPs 10 licenses for free, Microsoft offer heavily discounted pricing for charities. And thus the majority of the costs are in the database implementation. And if a volunteer can therefore configure such systems for a charity's needs (hence avoiding/reducing some costs) then some of my previous concerns about volunteer-developed systems may be negated completely or to a large degree. i.e.:
  • These CRM systems have a standard structure which means that fundamental contact management requirements are already there, and thus reporting and mailing functionality is taken care of.
  • These CRM suppliers will (for the foreseeable future) certainly be providing upgrades, bug fixes, improvements to central functionality/technology platforms and so on.
  • Even if the volunteer stops volunteering for your charity, the wide adoption of these CRM systems - within and outside the NFP sector - and their standard approach, should mean you can find someone else to help and support you. And there are many online discussion boards which can supplement such support too.
I should add that there are caveats to this approach: it is probably still best suited to small charities with low budgets; I would ideally want such volunteers to be "configuring" the systems as much as possible as opposed to "customisation" (i.e. no heavy coding - instead use the system's in-built tools and third-party apps as much as possible - "keep it as vanilla as possible"); and get them to document whatever they do for you.

And it still doesn't fully negate the need for them to understand your fundamental fundraising needs. Some of these systems will have some fundraising functionality but it won't be the same as buying a traditional fundraising database or even paying for one of the ever-increasing "fundraising templates" you can now get for these CRM systems.

And this approach is, still, to a degree re-inventing the wheel. But only to a degree. And certainly nothing like developing an Access or SQL Server database from scratch.

So, as much as I realise I may be setting myself up here, I think that now, for the first time for some time, for smaller charities with low budgets, using a volunteer for such database developments may again be a viable option.

2 comments:

Martin said...

As a former developer of fundraising systems, I can think of several very good reasons why volunteer development is a bad idea: Gift Aid, Direct Debits, Standing Orders, VAT, ..

Ivan Wainewright said...

Hi Martin, yes, you're right that that "re-inventing the wheel" can indeed be a good reason not to have a volunteer create a database.

However, that is partly why I think that the new CRM systems offer something different: systems like Salesforce have third-party apps for requirements such as DD processing, CiviCRM has a Gift Aid module, MS CRM has various templates for fundraising/membership requirements, and so on.

So if a charity can find a volunteer who understands and can configure one of these databases, then additional options like these can mean they can use their skills to enable such modules/options.