Why Do we still need so much training for Fundraising and CRM systems?

 

Over the years, there have been many promises about how we would need less and less training on our new fundraising and CRM systems, but in my experience, most new database implementations still require a fair amount of training. So why is that?

(First things first: there are whole books and thesis written about the best way to provide training on IT systems, so I have considered this blog post for just a few top level points - if you want to dig down further into the area then there is plenty more reading out there.)

We do have to remember that a fundraising or CRM database is not like a word processor or smartphone app. Fundraising/CRM systems are sophisticated and large applications, and, critically, they are also at the heart of our business operations and all our processes. So whatever we are implementing, they are going to take more time to learn than other software systems.

Secondly, because these systems are so sophisticated, flexible and broad-ranging, the administrators and database managers are going to require in-depth training and that isn't going to take a short time. There will almost certainly be multiple days training for such people.

And then we have the 'end-users'. Clearly this is where the bulk of the training needs to happen. And this is the area where we might be able to fine-tune and streamline some training courses for these people. Many vendors and organisations have moved on from the 'day 1, day 2, how to use our system' type training, and are realising that training the users around their particular business processes and specific instance of the system is a better way to do it. However, except for the very simplest of needs, even that is going to require a bit of time. And, as I said before, because in effect we are not just training on the software but reviewing the business processes too, and the users are having to understand how they have been impacted with the new system, then all that will add-up.

Which is why there is still so much training needed for most implementations of fundraising and CRM systems!

And a final word on some vendors: if you get a software supplier who tells you that you/your users don't need any training "because the system is so simple/intuitive…", then take that with a pinch of salt. If that's the case then not only must the software be so simple to use that anyone can start to use it without any problems or asking any questions, but they clearly also know all the new processes without any training either. Sorry - I can't see that happening.

Just what the heck IS a 360 degree view?!

 

"We want a 360 degree view of our supporters," or "We can offer you a 360 degree view of your supporters" are much-loved expressions these days. By charities and by CRM vendors. And when it's said, everyone nods their head earnestly and agrees, Yes, that's exactly what we need. And why wouldn't you? It sounds great! But does everyone really understand what they mean by a 360 degree view? It may sound simple/obvious (?) but is it really?

Let's have a look at a few definitions I found with a quick online search:

• Experian: "A 360 degree customer view gives a full picture of your customer and is essential for your organisation." Essential? Ooer.
• Aberdeen Group: "Buyers [donors] benefit from better service and efficiency, and sellers [fundraisers] derive improved loyalty and, inevitably, more repeat business from established customers." Okay, that sounds better.
• 360degreeview.com: "The 360° Customer View creates an integrated view of the customer – right across your enterprise. It gives you a business framework for integrating, enhancing, managing, and analyzing customer information, and allows for customized, phased implementations that deliver measurable business benefit." Wow, that sounds amazing!
• Purple Vision: "Everything you know about each supporter in one place." Ah, good - nice and simple.

So are they all saying the same thing? Well, yes and no. To answer that we probably have to first ask two fundamental questions: Why do we want a 360 degree view? And then, What data are we actually storing in order to provide one?

So, why would someone want a 360 degree view?
One of the most common data - and thus fundraising - issues for a charity is that there are so many data silos in an organisation; i.e. multiple databases and spreadsheets. And therefore, we can't see every contact point (often called "touch points" if you're being data-cool) which a donor or supporter has had with us.

And if that is the case, then: we might be contacting them without knowing specific things about them; we might contact them inappropriately; different people might contact them without knowing a key point about the supporter; multiple people might contact them at the same time for different reasons and risk losing, say, a key donation; we might not be maximising the most we could get from a supporter; we might not be keeping up with data protection/FOI requirements; we might not be able to analyse a supporter/groups of supporters as comprehensively as we could do - and as importantly as all that, we might not be treating the supporter as they would like to be treated.

These are all good reasons for potentially wanting a 360 degree view.

So what about the data itself?
But even if we want a 360 view and we know why we want it, then what should that view show? Does it really have to show "everything" about a supporter? And even if it should do, can it?! Can we ever see/collect all contact points?

I guess, ideally, yes it should show everything - that is the only way to really see a "complete" picture of a supporter. But how do we really know we are collecting everything? Is everyone in the charity entering every interaction with every supporter? Unlikely. Or even if they are, then it could well be on a local version of Outlook, a spreadsheet somewhere, a third-party online database.

I should also clarify "everything". A 360 degree view does not necessarily mean creating one behemothic, single database which is your only database where you store all your data. Very often, a 360 degree view (almost by definition of "view") will just contain key data sourced from multiple databases within your organisation - just enough to ensure it can do... whatever it is you are trying to do with the 360 system.

So do you really want one?
Could be. Their potential benefits can be great. And don't let my last few paragraphs stop you from trying to create your 360 degree view if you do decide it is right for you! Even if we can't definitely say we are collecting everything, then that isn't a reason not to try to set-up a 360 degree view if you see the benefits of having one for your organisation and your needs. Just be aware it might not be everything. Start-off with what you know and build it up as you find more sources, more people who might use it and as you identify more benefits from doing so.

Finally, assuming you do have multiple systems at your organisation - highly likely no matter how centralised you try to make a centralised CRM/fundraising database - then there is always the technical challenge of actually achieving a 360 degree view. That is not always as easy as one might hope.

Should I change my processes to match the database or make the database change to match mine?

 

This is a very common question I am asked: When I get a new database, should I change my processes to match the database and how it works, or should I make the database change to meet our processes? My views have actually changed on this over the last ten years and my own beliefs are now as follows:

First, It Depends...
First, there are a few "it depends" factors in this answer; the most important being:

• Why your current processes are as they are. In my experience, there are three common answers when I ask "why do you do process X that way?": (i) "I've no idea, we've always done it that way…"; (ii) "Because the current database makes us do it that way"; and (iii) "We've thought it through carefully and this is the best approach for us". Sadly, the latter answer is rare and the first two, and a combination/variation of those is more likely.
• Legal issues; e.g. gift aid, monitoring restricted funds etc. In these instances, the processes are going to have to reflect what is legally required anyway (although even here there could well be different ways to approach some of them).
• The type of database you are implementing; i.e. fundamentally whether it is a vertical-sector (traditional) fundraising database package, or if it is one of the newer breed of generic CRM systems. Although this difference is blurring a bit as I will explain below.

Why Wouldn't You Review Your Processes?
Secondly, when you implement a new database, whatever you buy, reviewing your processes is one of the most useful things you can do. As I said above, unless you already know you are in the "This is definitely the best process for us" category (which is rare), then this is a great opportunity to review why you do something, how, what's good about it, what's bad, what takes time, what could be automated, what you don't need to do and so on. And then you can take all that knowledge to the database implementation so that you can review the best way forward with your new system.

What if you are implementing a Traditional (vertical-sector) Fundraising Database package? e.g. Raiser's Edge, thankQ, Redbourn etc.
Many of these systems have been designed and adapted with many years of experience of what the NFP sector requires. And most which are still being sold today (if not all) are still selling and being used because they do the fundamentals perfectly well. And therefore, if you are buying into them as a software package, as a system, then it would seem to make sense to me to adapt your processes to how the packages have been designed. If you aren't going to do that, then why have you bought that package in the first place? There may be tweaks to do, but I wouldn't recommend changing the systems themselves except for the bare minimum and definitely within any parameters which the supplier suggests.

What about "generic CRM systems" such as Microsoft Dynamics and Salesforce, which you are implementing from a "vanilla" version (i.e. 'out of the box')?
These systems will give you an incredible amount of flexibility - which unfortunately is a double-edged sword. On the one hand, that means you can probably adapt the system to whatever process you prefer (within reason), so if your process review identifies some potentially great benefits by doing a process a whole new way, then this might be a great opportunity. Although that will also have the potential of higher cost, longer time, more arguments (sorry!) and a more complicated system than you might have needed. You need to be very good at keeping a lid on the amount of change you plan. And also: if you can do (nearly) anything then where do you start?! How will you know if your new process really is the best approach? How far should you go when changing the database system? And if you end up with vast swathes of changes then do not underestimate the Change Management you will need to introduce to your organisation. 

What about generic CRM system with a "fundraising/membership template"? e.g. Supporter360, Silverbear.
There are now quite a few "templates" which suppliers have created to sit on top of Dynamics and Salesforce in particular. In this instance, you are probably somewhere between still being able to change your processes if you really want to, but because the templates will have their own starting point, it would still be sensible to be using them as a starting point for reviewing your processes. Otherwise, as with packages, why buy them?

So What Is My Final Answer...?
My personal belief is to keep change as simple as possible, to use the software as it is supposed to be used as much as possible and if necessary, to start simple with the changes and fine tune them (or change them more dramatically) over time. i.e. Unless there are good reasons not to, adapt your processes to the software.

As I've discussed before, it is only after you really get to know your new software that you will truly understand what it can do, how and the benefits it can bring, so I wouldn't advocate spending huge amounts of time and money on it until you know what you really want from it.