Showing posts with label Redbourn. Show all posts
Showing posts with label Redbourn. Show all posts

Friday, December 16, 2016

Ten CRM Case Studies for Charities

On the tenth day of Christmas, my truelove gave to me... Ten Useful Case Studies of How NFPs Are Using CRM Systems


Case studies are a useful way to see how charities and the NFP sector have implemented fundraising and CRM systems. The following are ten such examples (in alphabetical order):

NB For clarification: this list in no way indicates that these are the ten best or the only ten systems you should consider. There are many more and you can see a more comprehensive list of Fundraising Software and CRM Systems on my website.


Monday, April 28, 2014

The 3 top reasons why you should still consider traditional fundraising software

Old & New 

So much is written now - by myself included! - about the (now not so) new CRM systems (I.e. MS CRM Dynamics, Salesforce et al) that you could be forgiven for forgetting that there are still other options. But the good ol' traditional fundraising database package is of course still going strong (e.g. Raiser's Edge, thankQ, CareNG, Advantage Fundraiser etc), and it is still selling well (out-selling CRM?) and there are clear benefits for at least considering it if you are looking at a new fundraising database solution.

These are my top three reasons why you should still consider the fundraising database package:
  • The built-in fundraising functionality: this has to be number one. These guys have been selling fundraising databases before Salesforce was a twinkle in Marc Benioff's eye. And as such they have rich and comprehensive built-in functionality for fundraising. It's why they were created in the first place. And even the more thorough templates/apps which are now available for Dynamics and Salesforce are hard-pressed to match all the fundraising functions which the fundraising packages can offer - and some don't even claim to be more than a starting point. Some of them are getting closer of course...
  • The suppliers themselves: This is almost as critical as the functionality - in fact, sometimes I would put it above the functionality for a reason as to why you should consider fundraising packages. Because the suppliers have years and years of knowledge of working with charities; they have staff who will have hundreds, even thousands of hours of experience which they have gleaned from the NFPs they have worked with; they have the heritage of working with the sector; and many have hundreds, even thousands of existing charity customers who already use the software, have provided feedback (good and bad) and who, believe it or not, may actually even like the software!
  • Reduced risk of the implementation itself: Some of the more critical aspects of a fundraising database implementation are aspects such as direct debits, marketing selection processes, finance/donation structure, gift aid and so on, and these are the areas which the packages already have ticked and, as importantly, have implemented many times in many different environments. Even the better CRM systems still have limited exposure to such areas and are still learning. This does reduce risk. Equally, the wider functionality already available means you have a structure to the system and the implementation, you will be able to run your processes in proven ways and you won't just forget some functionality. Plus, the suppliers have done it all before many times and it's even quite feasible that some of your staff will even know the new system from other places they have worked.
All that said, and to keep things in perspective, I do realise that some of these benefits I am promoting could equally be seen as downsides by CRM suppliers, and some CRM suppliers could quite rightly point to their successes; so do remember I am just saying here why the traditional packages should at least still be considered...

Monday, February 03, 2014

What is the best CRM Database for a Small distributed charity or a solo fundraiser?

centre of the storm 
A couple of questions I am regularly asked are: "I am looking for a CRM/fundraising package for a small charity with no central office. So, no server and we probably need something to work across Windows and Mac." And it must be simple to use... Similarly, "What is the best database for a solo fundraiser?" So, I thought I should try to answer these questions here. I will address the 'small distributed charity' first as much of that applies to solo fundraisers too, and then add a shorter, second post with additional details on databases for solo fundraisers.

First: Get your main IT infrastructure sorted out
This is important. Especially if you don't have a central office, and the route you take may partially influence your decisions on which is the best fundraising/CRM system for you. So, first of all, if you haven't done so already, make sure your email system, file access, website etc are all part of a solid strategic approach.

Second: Remember, it's still important to know your fundamental database requirements
This is the same for any database procurement and just because you are a smaller organisation doesn't mean you should completely ignore it. So do document what you want the system to do, even if it's just in a brief Word document. That will help you focus on what is most important to you and you can then weigh-up the system options later. And remember, whatever database you buy, the data you put in it, the business processes and training you put behind it, and the fundraising strategy it is supporting are all more important than the software itself. You can have the best database in the world but it won't help if your data is rubbish, you don't adapt your processes and so on.

You also need to bear in mind just how much time and effort you can or want to allocate to managing your CRM/fundraising database. Remember that all systems will require some initial work, regardless of what the salespeople say! You will have to consider the configuration, maybe data migration, how and where you are going to store your data, how external data files will be loaded, how training will be done, how you will maintain look-up tables to ensure good data consistency and so on. And even though you are a small charity, there could still be a number of people who might well want to access and use your database, especially if it is not just for fundraising. In which case do remember the need to have someone who is data/database savvy so that they can manage these issues.

All that said, I do realise that for many small organisations, your requirements will be similar and comparatively fundamental, so I will use that assumption in the rest of this post. Plus, I am restricting examples of systems to those which should be within the budget of a small charity.

Oh, And it Must Be Simple to Use...
This is possibly one of the most frequently used statements which small (and large!) charities use. So it is important to realise that CRM and fundraising databases are not as simple conceptually as Excel, Outlook etc. They will take time to learn, they will need some looking after and the likelihood is it will cost money to do all that. Sorry. There is no easy answer to that. Software is getting easier to use and more intuitive but at the end of the day some of that is still down to individual preferences and interpretation. Just don't under-estimate the work involved in getting going if you haven't used a CRM system before.

Two technological approaches: Hosting and SAAS
Fundamentally, you have 2 technology approaches which may influence which databases you consider, and which technology is right for you will partially depend on your IT infrastructure. 1

SAAS stands for Software-as-a-Service, where a supplier provides a database which you can access as simply as gmail etc, and from any browser without the need for any additional software. Most such solutions are only offered this way (with a few exceptions); i.e. not with an alternative "on premise" option.

Hosting is similar but one-step removed, where your database will be "hosted" on a remote server in a secure data centre somewhere (i.e. you still won't need a server in your own office to make this work). This is usually done for software which has not been written specifically to run directly through a browser and thus it still needs to be stored on a specific server somewhere. Thus for hosting, a supplier will most likely host the database on the supplier's own server and you access it remotely from your office/home. (Additionally, most such suppliers will also offer clients the option of letting you install their database on your charity's own server).

In theory, you could take any fundraising database and host it on your own server anywhere - but to do that, I would recommend that you need to have taken the IT infrastructure route which already supports that. i.e. you are already using a company to do this for some/all of your other files/software applications.


Examples
Examples of SAAS databases are Salesforce, Microsoft CRM Dynamics, Workbooks and companies offering 'templated' versions of these. Plus, fundraising systems such as eTapestry or DonorPerfect.

With hosting, you have a wider option of solutions. As I mentioned, you could look at almost any database, but some companies already offer Hosted solutions as part of their portfolio, mostly through third-party partners; e.g. CiviCRM, Advantage NFP, thankQ. (Remember these are products more applicable to small charities - there are many more options for larger organisations).

And if as a small charity you have more severe budgetary issues, then the following posts I have written before might also help you: What should you do if you really have zero budget for a new CRM or Fundraising database? and Why Free Software Doesn’t Mean Zero Cost.



1. More technology-savvy readers will no doubt realise I have greatly simplified these descriptions, so please forgive any gross over-simplifications! If you feel I have really misrepresented anything then please let me know by email or in the comments below - thanks.

Sunday, August 15, 2010

Database Options: Packages, Bespoke and Generic CRM (part 2)

If your organisation believes that you have a unique requirement which means you have to develop a bespoke database then this blog post challenges you to consider if this really is the case. In the first part of this post, I detailed my beliefs on the pros and cons of packages vs bespoke systems vs “Hybrid CRM” solutions. And in this second post, I lay out a process which you can use and consider if you do believe you have a unique requirement.

Find out if your requirement is really unique
First of all, you need to find out if what you think is a unique requirement really has not been addressed by other charities using alternative systems or methods. I realise this can be hard to do so here are a few ideas:
  • Talk to other charities like yourselves - or even not like yourselves - but who you know went through a similar exercise
  • Talk to database suppliers and consultants (email me! I’m happy to help if I can) and ask their opinions. Database suppliers in particular will probably be delighted to speak to you about what they could do to help.
  • Look at not-for-profit technology resource web sites for leads and different approaches: itforcharities, TechSoup, LASA's NFP Suppliers Directory, VolResource
  • Visit trade shows
  • Post questions on web-site forums and email discussion lists
  • Ask your employees of their experience at previous charities
  • And, of course, search and browse the web
If you find your requirement is partially unique…
If this is not an oxymoron, just how unique is your requirement? Is it just different data you need to record? A handful of additional fields? One extra entity? Partially different functions? A different process?

If you find this is the case then consider the following options:
  • Consider using an existing package but with customisation. Consider if a database package can help, even if it means customising/bespoking it and/or if it means almost meeting your requirements (see below).
  • Consider using functionality which wasn’t initially made for your requirement – although this does come with a caveat: don’t wander too far from the original aim of the software or future developments in that package may not support you.
  • Try changing your processes. Packages are often designed so that they work best with processes which work in a particular way. Ask yourself if your processes are really the only way you could do things, or could you fit them around a package’s approach?So how can you find out if a database package can do this for you? As above, get the package suppliers into your office and ask them – there’s nothing they like better than the thought of a few extra pounds/dollars for doing such work…
In fact, some database packages are pretty good even for bespoke work. Blackbaud’s Raiser’s Edge has its API module, Care from IRIS has offered web services and bespoke/customisation for years, ASI Europe have just announced new web services for their system, and Ciber UK provide Ascent which is good for customisation. And ESIT has taken ThankQ, essentially, historically a fundraising/membership package, and done some great bespoke customisations on functionality on all sorts of areas outside that; very impressive. Even at the lower end of the market (cost-wise) Redbourn have offered additional work on Advantage Fundraiser. Please do note all these are just examples and other database suppliers might also provide similar approaches.

Often, package suppliers are very happy to offer bespoke/customisation work which can form a new module for their system, so although it may start as bespoke work, it will be offered to more charities later and thus become part of their standard system. Quite a common path for many suppliers. Maybe you could even share the development cost with other organisations and/or with the developer? ITSorted and Centrepoint Computer Services are just two examples of companies who have used this approach.

“Hybrid CRM” Solutions
One of the most exciting, new options of recent years for organisations with some unique requirements are to use one of the CRM solutions such as Microsoft CRM, SalesForce, CiviCRM, Pivotal, ODM from Gallery Partnership and so on.

As discussed in the previous post, they are designed to be used across a range of industries. SalesForce’ AppExchange has proven extremely popular and Microsoft now has a similar offering and has approached its future releases with XRM (the idea that you can extend CRM significantly beyond its original goal) as one of its core ideas.

How important is technology?
I do appreciate that one issue for many organisations is that web access can offer so much benefit for integration, roll-out, remote access, home users etc that the technology platform can be extremely important. Unfortunately, some web applications are not as functionally rich as Windows packages. So if you can find a Windows package option but not a web-based solution, but that technology is key for you, then at the end of the day it will come down to business benefits. Would you gain more from having a Windows package and possibly running it across Citrix/Terminal Services, or would a web application with slightly less functionality be better for you?

If it’s really unique after all…
But if you really do find you have a unique requirement, then try asking the following: How much does it really matter? What would the impact be if you couldn’t have such a function? Or only partially have it? Is it a nice-to-have feature or really business critical? Is it for fundraising or service delivery - i.e. who does it affect – you or your clients?

Could you use a package for 80% (90% etc) of your requirements and accept that you can’t do everything perfectly for your final 20%? Does only that final 20% (10% etc) need to be managed elsewhere in other ways? Could the package still help with 50% of your unique requirements (e.g. recording contact information and contact made with those contacts but maybe not a specific issue aside from that) and could you do the other 50% on another system.

At the end of the day…
Of course, at the end of the day it is entirely feasible that you have a unique requirement and will decide that your best approach is to develop a bespoke system, in which case, go for it. But I hope that by considering the package options first you can thus rule them out and have a true business case for your development project.