Do you really need real-time integration?

 

For some reason, when users request integration it often seems to have to be "real-time" integration. This may just be because 'real-time' is a bit of a buzzword, or because it is used without really being fully understood, or it may be because someone (a salesperson?!) once told them they simply had to have this... But if you quiz them more deeply then I would suspect that very few applications which charities run have to truly be "real time".

And the reason that is important is because real-time = really more complex and expensive.

First off, it is worth defining real-time within this context: real-time for a charity could be when, say, someone makes a donation on your website and then that donation is transferred 'immediately' into your fundraising/CRM system. But even here, 'immediately' could be several seconds which for us as a charity pretty much is real-time - as opposed to, say, a share-price system or a car's ABS system which has to react within nanoseconds. The important thing to note is what real-time does not do which is that it does not simply pass the data to a 'queue' of similar transactions which is then transferred into your CRM system sometime later using a 'batch process' of some sort.

So, if we consider this definition, then when do we as charities really need real-time integration between another system and our fundraising/CRM system? The above example of online donations or event registrations is a good case in point: if a donor was to phone your supporter care team within moments of making an online donation then maybe real-time (or near real-time) would be very important. But although I know that scenario does happen, it's rare. And there could quite feasibly be a simpler, cheaper workaround for that such as your supporter care team having access to, say, a web portal to your online donation/event management system. I'm not saying that is definitely the best approach, but it should be considered if a real-time option is prohibitively expensive or complex. If it's not - and actually, these days, such real-time integration between CMS and CRM is increasingly more straight forward - then go ahead, knock yourself out with it.

But I would really question the need for real-time for many other applications. For example: if you are only getting a handful of online transactions a day and no-one needs to know about (or is available to know about) them instantly anyway; if you have a fulfilment house processing your campaign cheques; if you are receiving files from CAF; and so on. In those instances, it is probably perfectly acceptable to have batch process integration. And batch integration doesn't have to be daily, which is how it is often thought of. If it is automated then it could be every n hours etc. But it will (almost certainly) be a lot easier and cheaper to implement and maintain.

The CRM Alternatives to Salesforce and Dynamics for Charities

 

Salesforce and Microsoft CRM Dynamics are both great solutions but when considering 'generic' CRM systems, it is easy to think that they are the only "CRM systems" available to UK charities, which of course is not the case: there are dozens of similar(ish) systems on the market - and there are of course fundraising database packages. That said, there are some CRM systems which are either more oriented towards the NFP sector or where a supplier has specifically created modules for charities, or where one or more business partners have taken the sector seriously enough to have made an impact with what they can provide, and it is those systems which I thought it would be useful to list here for awareness:

• CiviCRM: CiviCRM has been designed specifically for the NFP market with appropriate functionality and ethos, and is almost certainly the NFP sector's leading open source CRM system, offering collaboration and joint development. And because it is not oriented at just one "type" of solution for charities (i.e. not just service delivery, not just case management, not just fundraising, volunteer management etc) it has a degree of flexibility similar to that which the CRM solutions also offer, if maybe not quite so in-depth. It has a great ethos for charities, and an ever-growing and broadening community using it and supporting other users. And by its very nature it tends to attract users and developers who believe in not just the software but the whole open source approach. But the fact it is not driven by a commercial organisation means that when statutory or regulatory requirements change, then a user and/or the community needs to get the software updated to manage that.
• Workbooks.com: Workbooks has gained several UK clients in the membership sector and are offering their solution to charities too. It is a web-based (SAAS) solution designed for small and mid-size businesses, so in terms of solution size their NFP offering should fit many charities. Unlike Salesforce/Dynamics, they (primarily) sell direct to end-user organisations.
• SugarCRM: Sugar has an open-source and a paid-for commercial offering and has had some adoption with charities and the public sector, partly due to its cost structure but partly because it is a decent system with an especially good interface. It can be hosted or run on-premise and is sold and implemented through a partner network. It has perhaps not made inroads into the sector quite as much as the other systems.
• NetSuite: A large, CRM vendor in the US, they have created NetSuite.org which is the corporate citizenship arm of NetSuite. They offer product donations, pro bono programs and social solutions to charities and NFPs. Not yet as well adopted in the UK compared to North America.
• Siebel and Oracle: For the largest charities…
• And a few others which I know some charities have used:
• Zoho: Free and paid-for versions of their CRM and other online apps.
• Sage CRM (what was ACT! years ago) has a Windows and a SAAS solution. 
• Highrise CRM: SAAS software from the people who brought you Basecamp (although more oriented to contact management and maybe service delivery than fundraising).

As I said above, there are of course many other CRM solutions including a number which appear on Gartner's Magic Quadrant which do well in the commercial sector but which (to my knowledge) don't have any charity implementations. It will be interesting to see if any such systems start to also move into the sector and if any of those in the above list can challenge Salesforce and Microsoft CRM with leading sector offerings.

Why CRM Systems Are Like Icebergs for Charities

 

There is no doubt that the adoption of the generic CRM systems like Salesforce and Dynamics is increasing amongst charities and NFPs. But in comparison to the commercial sector we are still learning about the use of them. And in comparison to traditional fundraising databases (Raiser's Edge, thankQ et al) we still know less about them. Consequently, although there are definite benefits which the CRM systems bring, there may still be issues which we don't yet know about.

Bring on the iceberg...

My iceberg theory…
The fundraising database packages have of course been around for many years. Many organisations have implemented them, many people have implemented them at multiple charities and of course the suppliers have huge experience of them. And they have a more defined scope.

So we know many of the potential risks and issues with such systems (as well as the benefits of course) and when we start an implementation we can attempt to plan for and mitigate such risks. And even though there will inevitably be new risks/issues which occur during an implementation, I could have a good guess at some of the areas that some of those might occur within.

Whereas the opposite is true for the CRM systems - at least in the specific and critical area of fundraising. Because although there are of course existing charities who have implemented Salesforce, Dynamics et al for their fundraising needs, in comparison to the fundraising packages the number is still low. And those that have done may well have used different approaches to each other and very different configurations of such systems.

This is partly because of their newness, but also because of their flexibility, options, configurability and the breadth of functionality in the base platform. You (we) don't learn that overnight. And even as you do learn the system, so we have to apply that to get the best out of them for sophisticated and sometimes significant fundraising requirements.

And it isn't simply a matter of therefore finding an experienced CRM system supplier because they will also only have limited exposure to implementing their system for fundraising at charities and NFPs.

Hence the iceberg…

Because if it is true that 90% of an iceberg is underwater and thus we can't see it as we approach it, then the same could be said of CRM system implementations. In fact, it could be worse. Because at least we know that we can only see 10% of an iceberg above water, whereas actually we have no idea really as to how much of the "CRM iceberg" is submerged below water, waiting for us to hit it as we plough through the sea of implementation. I hope that in practise that we do know more than just 10% of what the potential risks/issues are, but I can't say for certain right now.

Whereas, with fundraising packages, one can almost turn that on its head (an inverse iceberg?) and say that we probably do know 90% of the potential risks/issues which could occur in a typical implementation of such systems.

So what can we do to plan the safe passage of the good ship CRM?
The good news is that although we may not know exactly what is coming to potentially scrape our bows as we sail past, we can have a good stab at knowing the sort of areas in which any issues might impact and thus even if we can't put a final mitigation plan in place for such risks, we can start now to consider how we should plan for them.

What do I mean by that? Well, let's take a complex income processing scenario. Maybe we know that our ideal requirements can be met by CRM system X only through customisation and coding. In which case, we can watch carefully as we start down that route, plan to take it slowly, test as we go along, re-test as we add further functionality, actually go-live with limited functionality and then build on that, and always have a back-out plan which might mean, say, that if we do find it is getting too complex/costly, then at least for the implementation we will decide to simplify the system itself and substitute the ideal functionality with off-line or manual processes instead.

Similarly, if we find that record volumes are causing a problem which we didn't know about for data migration, then we may decide to initially just migrate more recent data and then transfer older data more slowly over a period after we go-live. Or for gift aid claims, we could even have a third-party package ready to do some initial claims if we do hit a nasty bit of ice. And so on.

And overall we can follow good practise for any CRM implementation: get our requirements straight, make sure it is all documented for client and supplier, manage scope-creep, don't let shiny new whizzy stuff take you off down a path which you don't need to go down (at least not on day one), insist on good project management (internally and with the supplier), never forget your operational needs, look for true benefits and so on. Keep it all as simple as possible.

Reeling it back from the simile…
I realise that I am wandering off down the iceberg simile a bit too much, so let's reel it back to finish this post. What I am really trying to say is that we must not forget that some of the fundraising implementations already done on these CRM systems are still pioneers in their own way. We can do as thorough procurement processes as possible, we can learn as much as possible from commercial organisations who are more experienced in their usage and their business partners/suppliers, and we can learn some things from other charities who have already started to use these systems, but because of their sheer size and capabilities we must keep our eyes open and be ready if we hit a problem that we just hadn't thought of. Be ready for this as much as you can, and if that does happen then hopefully it will just be a slight scrape on our midship and we can avoid replicating the Titanic…