We’re going to unsubscribe you, unless...

I received a clever email today (at least, I think it's clever!) which has the subject line, "We’re going to unsubscribe you, unless..." At first, because the subject text drew my eye, I thought it must be spam, but then I looked at the sender and realised it was from the British Library (BL), who I am a subscriber to. So why was it clever? Well I think it was smart because of the following:

First, interestingly, "mild panic" set in. (Well, okay, not quite panic, but you know what I mean). What was I going to be missing?! What was I about to be unsubscribed from without me knowing? So I opened the email. And once my heart-rate had returned to normal, I realised it was the BL informing me that because I hadn't opened one of their regular emails for some time, they were going to unsubscribe me unless I specifically clicked on a button to remain subscribed. And I quite liked that. It made me wonder initially why I wasn't opening their emails and if I did really want to continue to be subscribed. So I clicked and did re-subscribe.

Why even do this?
Now, I guess some people might question why the BL bother doing this. After all, each email only costs a few pence to send so why not just keep me on the list. After all, one day I might open it and take some action. Which is how I know many fundraisers see such email lists. The more names the better. Never mind if it isn't really what the supporter is interested in reading anymore, and never mind that the open rate is 0.00-whatever. Just keep sending everyone the emails just in case…

However, personally, I think this is a great exercise in promoting supporter choice, which is something I quite believe in. Surely it makes more sense to only be sending emails to people who want to receive them. Surely it provides a better ROI - after all, even if each email only costs a few pence to send, thousands of such emails will add-up each time they are sent, and they are likely to be sent many times during the year. So the total cost will add up.

And, by getting people to re-confirm their subscription, by definition you have someone who has taken a positive action to remain interested, and that in itself could be an interesting segment to approach. Now you know something more about them. Maybe you could send them an initial "welcome back" email with a particular message or options to take? Maybe they could be allocated a different customer journey? As yet, I haven't received anything like that from the BL but I will wait to see. (I was also slightly disappointed that the email click-through was to a generic page on the BL website rather than a 'Great, thanks for doing that - now have you thought about…' type page).

The Technical SideOf course, to do this, it takes one critical technical thing: an email marketing system (EMS) which can monitor if someone doesn't open an email; and alongside that, a database - whether within the EMS or in a separate CRM - which the marketers can query in order to find out which people they should target with such a message - which people have not opened x emails within the last y months/campaigns etc. And of course, a database where, if I am subscribed to several different emails from the organisation, then it needs to be able to not blanket unsubscribe me but just opt me out of this specific email campaign.
It’s a great example of the digital world with a smart database and with some savvy marketing users coming together to try this out. Kudos to the BL.

Is there any place for the Long ITT anymore?

 

The short answer
No.

The only slightly less short answer
No, except when you have to, such as OJEU or similar requirements.

The Full Answer
Okay, let's address this question properly. First of all, what do I mean by a "Long Tick-box ITT"? Well, pretty much as it sounds: it's when you devise hundreds and hundreds of questions, mostly about functionality, and ask suppliers to respond to your Invitation to Tender (ITT) document by asking them to tick a box which says if they can meet that requirement. Often, this will be a MoSCoW method (or similar): Must have, Should have, Could Have, Won't. (Never underestimate how much IT loves its acronyms and pseudo-acronyms). And then sometimes one asks if they can do it 'Out of the box' or 'with customisation' or 'not at all' - or similar. Thus, the suppliers tick these boxes, you add-up their scores, sometimes weight the questions with more/less importance and hey presto, we have a winner. Or at least a short-list which you can then invite in for a demo.

But it's really not as simple as that. In the first place, suppliers have been known (shock horror) to stretch the truth when ticking boxes and interpret a question so they can say yes they can do it when maybe they can't really... And in some ways, that's understandable as writing such questions so they are non-ambiguous can be difficult.

Plus, completely understandably these days, 'generic' CRM suppliers can probably say with (almost?!) complete honesty that they can do all almost all of a CRM ITT's requirements because their systems have been designed for exactly that flexibility. But that still doesn't mean they are necessarily right for you to buy.

And it doesn't tell you anything about how they would do it, or if they do it well, or if they understand the question and so on. Okay, so some of that can be addressed at a software demonstration but by that point you may have knocked out a good option (supplier) without knowing it, or you might find a supplier is actually completely inappropriate for your organisation or requirements. It's just a non-efficient method.

In fact, the time it takes for this whole process is a looooong time. A long time for you to create the initial document, a long time for the supplier to answer and a long time for you and your colleagues to read all the responses and mark them.

Couldn't there be a better way of using your time? In my opinion, yes. Personally, when I help charities with a procurement, I prefer more 'open' tender documents (aka RFP - Request for Proposal), asking for more expansive responses, possibly with the inclusion of process diagrams and a more interactive approach with the suppliers all round.

And I'm not completely against including a few lists here or there in the RFP of specific requirements which you must have - especially where they are especially important. But I don't ask suppliers to tick each bullet point.

Clearly, there is a lot more to the whole procurement process than just the above - but super-long ITTs? No, not for me. I don't think they help you select the best supplier for you. Which is ultimately what you want.

Should organisations choose a CRM platform before a supplier?

 

With the emergence of the generic CRM systems and the reduction in the number of viable proprietary fundraising databases, an interesting question is arising: should charities now be choosing a CRM platform before even looking at which specific supplier/partner they want?

It is a process which some companies in the commercial sector have already been practising for years. For some companies, they will decide first on whether Salesforce, Microsoft Dynamics, SugarCRM etc are the best fit for them, and only then will they search for a specific partner who can help them implement a new CRM system on that chosen platform.

For charities, however, at least until recently, because the options have primarily been about comparing different proprietary fundraising database suppliers (e.g. Blackbaud, thankQ, Redbourn, ACS etc), this has not been an approach we have taken. That said, there will of course have been some technological decisions: the system must be SQL Server, or it must be Oracle; it must be dot net or it must run on Linux etc. Or even, it should be open-source. And so on. So it's not a completely alien idea.

It's just that with the new CRM systems, the platform choice can be far more "business-oriented"; i.e. if we do decide that platform X is the right solution for us - and if that platform is one of the generic CRM systems - then we now have the choice of talking to numerous companies about how they would implement that, looking at whether we want a templated version or start out-of-the-box, develop in-house or with a partner, and so on.

But additionally, if as a charity you do want to be considering a platform first, you also need to consider the proprietary solution as one of those platforms - and (probably) not just one such solution but the concept as a whole. As I have discussed many times in my blogs, there is no simple right and wrong as to whether you should select a traditional fundraising database or a CRM solution. If you do select a proprietary solution then you will (almost certainly) implement it with that system's software author and that has its pros and cons. If you go with a CRM solution, then using a business partner of that software author (or even doing it in-house) also has its benefits and downsides.

Personally, at the moment, I think choosing a platform first is a difficult approach to take for all but a few, probably larger charities who already have a detailed, well thought through technology plan and IT strategy. Especially at an early stage in a procurement project when you are still trying to understand the differences, the benefits of all solutions, the impact on your organisation and so on. I think there would have to be clear reasons for you to only look at the traditional fundraising databases, or decide not to look at those at all. You might dismiss one option or one supplier etc as you progress your procurement, but I believe you need to understand what all options can offer before going solely down one route. So at the moment that will usually mean keeping them all in the hat until you are ready to shorten your choices to the final few.

The Importance of Report Designers during CRM Implementations

 

On one project I worked on, not long before we were due to go-live, there was some concern that a specific, highly important report could not be produced because of the fundamental, underlying design of the CRM system. And it made me wonder how this could have happened - that such an important factor had not been fully considered until that point. It turned out that the reason was because when the database was being designed, the report designer - i.e. the person who creates the reports, not the software - had not been consulted when they could have provided invaluable input.

When I thought more about this, my first reaction was to think that this should hopefully be a rare occurrence. One would trust that in most instances, whoever was designing the database - whether a person, a team, a company etc - would know the key reports which were required and would thus design the database so that such reports could be created. Plus, in classic systems design, one often starts with asking what reports and information are wanted and thus we work backwards to work out what fields and data need to be recorded in order that such reports can be created.

However, with larger or more complex implementations, with projects with larger teams, and also with the new CRM systems which now offer so much more flexibility with their design, I've realised that such a requirement could easily slip through a hole. It is quite feasible, if the correct person is not consulted, that a database could be designed without true understanding or consideration of some reports. Or perhaps understandably, whoever is designing the database was told by a 'third party' as to what a report needed to show, and thus they hadn't got the full picture.

This issue can also be exacerbated when a charity is implementing a new database where no-one in the charity necessarily has the in-depth experience of report creation on that system. (By the way, in this instance the charity may have to hold their hands up to accept their share of guilt as this isn't necessarily something which should be aimed purely at the supplier...)

So my advice:

• when designing databases, do make sure reports are considered early in the design phase;
• engage the relevant report designers as soon as possible, and if you don't have one in-house then consider contracting one even for a short period to do some 'sense checks' early on; 
• introduce a specific 'report workstream' in the project so that reports, outputs, mailings et al are specifically considered at all times; 
• and don’t underestimate the time or importance of this factor.

After all, if we can't report on the data or get the data out of the database in a useful format, why are we using the database in the first place?

Good Database Managers Know When to Say No

 

It is quite an art saying No. Especially when you are a database manager and your users are continually asking you to do this and that and everything else, and you know that, yes, that latest request is technically possible (as opposed to something just not being possible at all) but, business-wise, data-wise, policy-wise, it is the wrong thing to do...

So, do you say No in such instances?

I applaud any database manager who does say No when they truly believe that it is the wrong approach to take. But it's a hard thing to do. ^†

Of course, what I hope a database manager can say sometimes is, "No, but…" i.e. no, what you are asking should not be done that way, but on the other hand, you can do it this way. And then hope that most users will understand and appreciate that. An example is how someone might ask for a new field or new code table to be added to a database, when you know that it is better practise to extend the use of an existing field/table.

But it's harder when the question doesn't necessarily have such an easy answer. e.g. Can we add a new screen to show data item x to department y… Can we import these z records from another system…

Both may well be possible technically. You might well be able to create a new form so that department y has a specific view of some data, but if that means that they won't see other relevant data which they should be aware of, or if it means it will be much harder to maintain in the future, then you might need to say No. And although you can explain why not, there isn't such an easy answer to what they can do instead - it might just be that it shouldn't be done full stop.

Similarly with importing records from another database. What for? Who will use them and how often? Will those records still be on another database - if so, how will you keep them all up-to-date? And so on. I have seen countless systems littered with useless records which have been added some years ago just because someone had the bright idea of doing this one particular project…

So stick to your guns, database managers. Remember what Zammo said (for those old enough to know what I'm talking about…)

---

† BTW, for any fundraisers reading this, who feel that their database manager is always saying No, then I feel for you too! They might be doing so for good reasons, but it could of course be a bad database you have or even a not so savvy database manager…
 

Not blaming the client: the supplier's responsibility when implementing CRM systems

 

Every now and then on database implementation projects, I'm aware of suppliers who try to pass the buck once too much and maybe try to overly blame the client when the project isn't going well. And I have one fundamental issue with this: the supplier is the expert who will have implemented dozens and maybe hundreds (thousands?) of similar systems - the client will hopefully only do this once every five to ten years. So doesn't the supplier have an additional responsibility?

Now. I do realise that it isn't quite as cut-and-dry as that. I know of charities who have blamed the supplier when things have gone wrong, or accused them of things when I am pretty sure that the supplier would never have advocated such an approach. Or the charity itself should have considered something, requested something, put something in place or, most commonly, committed more and/or more appropriate resources to the project. And yes, it should be a partnership between supplier and client. So I completely accept that the supplier cannot be and should not be responsible for all aspects of the project.

But I do get annoyed when a supplier blames far too much on the client. Or when they do not explain things better to a charity, when a supplier goes off down a route of development which clearly isn't appropriate for a charity, or when the charity is expected to 'sign off' design issues early on in an implementation and when the implications of any decisions are not truly understood by a charity - and yet the supplier should have the experience to really emphasise more to the charity just what they should be doing and what might happen if they don't do that. And if the charity still decides not to follow their advice, then fair enough. But the supplier has to take some responsibility.

The trouble is, as I said above, if a charity is only implementing a fundraising database/CRM systems once every few years, and even if they are employing a database manager or similar who has maybe done a similar implementation once or twice before, they still won't have the experience which the supplier has. So how can they really understand the full implications of any decision unless the supplier makes it really clear to them?

On the other hand...
So if I am saying all this then it is probably only fair if I also address one question which a supplier could quite understandably ask me: if a charity does ignore their advice then what should I do? With the extreme question, should we even walk away from the project?

Clearly one hopes it is a rare thing for a project to reach such a point that a supplier has to consider this. I have had a wee rant above about what I believe suppliers should do, but I also hope that most of the time - with good, reputable suppliers - this just means that if they do see a charity doing things the wrong way then they at least discuss this with the client. If necessary, one might want to pause the project, try to get it back on track, work out how it can be managed better (by both sides?) as it continues, but I would hope that all such considerations are held before anything more drastic is done.

And walk away? There would of course be all sorts of contractual issues, unless one side just accepts the lost income, but it is an interesting ethical question. I'm sure we would all prefer that the supplier - and client - worked hard to turn the project around, but yes, maybe there is a time when it is right to sever ties mid-way through an implementation. But that's tough.

Trying to avoid this in the first place
So what can we do to try to avoid reaching such an impasse? The first thing the charity can do - and possibly the supplier to - is undertake a through procurement and, if appropriate, an immediate design/discovery phase after that with the preferred supplier. This may open up areas which are currently misunderstood, show other areas which need to be hammered down, raise issues of resourcing, budget, responsibilities etc. I know several suppliers who insist on such phases now in CRM projects.

Designated project roles can also help; a project manager on the client's side is of course important and even a Solution Owner role might be another answer; early and comprehensive training of the project team could help; documentation showing deliverables and responsibilities; or documentation full stop can help. If we have good, agreed, well structured documentation showing what has been requested, agreed, designed, planned, deferred and so on, then that in itself can help prevent (some of) the 'but you said...' issues.

Even implementing using agile project management can alleviate some of these issues, although I have equally found that agile can be an excuse that just because a decision was made a few sprints ago, now we have to change it because 'new requirements' have come to light, when in actual fact it was just a poor decision/recommendation in the original sprint...


But I still sometimes have to come back to the supplier's responsibility as well. As I say, they are the CRM experts, they are the ones who know what has gone well and gone badly before - and those that understand this will be the good ones who will succeed in the sector. And we all know how important reputation is in the sector. That alone should be enough to encourage them to uphold this approach.

CiviCRM: A great example of Open Source Benefits for Charities

CiviCRM is almost certainly the NFP sector's leading open source CRM system. And if you want an example or two of why this is, then, aside from its standard functionality, the following should explain a lot: Just recently, Leukaemia and Lymphoma Research, who use CiviCRM, wanted to integrate Civi with JustGiving and so they developed an integration piece to do this - and they have made that available for free for all other users of CiviCRM. Prior to this, the recent HMRC Charities Online gift aid update meant that changes were needed to the existing CiviCRM Gift Aid functionality, and again, Leukaemia and Lymphoma Research developed the changes required and made them available to the Civi community. And even before that, when there was no Direct Debit processing or Gift Aid functionality available in CiviCRM, a third-party Civi partner, NFP Services, developed these features - although they did this as part of a paid-for development - but thereafter, those functions are now available to all other Civi users.

And if a CiviCRM user wants a new function which hasn't yet been developed in the core software then, although they can of course enhance the system in-house as Leukaemia and Lymphoma Research did, or pay a developer to create that for them - and there are a number of CiviCRM approved service partners here in the UK as well as worldwide - they can also add it to the 'Make it Happen' campaigns on CiviCRM's website where ideas can be put forward and multiple Civi users can contribute in order to fund the development.

This shows the appeal and benefit of CiviCRM to some charities: collaboration and joint development (as well as good software). And shows the all the great things about the Open Source community - and yet it also highlights some of the dangers too.

The benefits are clear: open source is free software, although please remember that it is just the software which is free; the implementation, developments, training, data migration, any consultancy/project management etc, and of course the hosting or in-house servers, all cost money. And it has a great ethos for charities, and an ever-growing and broadening community using and supporting other users. And by its very nature it tends to attract developers who believe in not just the software but the whole approach.

But the fact it is not driven by a commercial organisation means that when statutory or regulatory requirements change (as highlighted above), then a user and/or the community needs to get the software updated to manage that. And although the software is constantly being developed and enhanced, it doesn't have the same financial clout which some of the larger commercial CRM suppliers have and as it isn't a dedicated fundraising database then there is a different incentive to the 'traditional' fundraising database suppliers. Of course, this approach is the very thing which encourages some organisations to use CiviCRM (!) and as it states on Civi's website, "CiviCRM’s development roadmap is primarily generated from the ground up".

CiviCRM has a lot going for it. It is one of those systems where it feels there should be a natural, cultural fit with the NFP sector. It has decent functionality and it is growing its user-base here in the UK. It isn't a "traditional" fundraising database system, but neither is it a "generic" CRM solution (a la Salesforce, MS Dynamics etc). What it is is a "CRM" solution which has been created specifically for the nonprofit sector, and as such, with in-built functionality specifically created for charities. 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's unlikely, of course, that CiviCRM will ever be as big as the major CRM players because it is sector-focused).

And all this on a platform which is flexible and where even non-technical users can create reports, add features such as new fields (and tables), adapt forms and so on. Try that on some other systems…

When I discuss different database options for charities, I often pigeon-hole software suppliers as "traditional fundraising database solutions" or "generic CRM solutions" - CiviCRM is neither but that is no bad thing, and if you are considering a new CRM system or fundraising database then putting CiviCRM on your radar could be well worth it.

The need for The Solution Owner role when implementing CRM systems

 

For many years, I have discussed and promoted the need for a Project Manager (PM) for organisations who are implementing new fundraising databases and CRM systems. But I've been very aware that, sometimes for mid-size installations and definitely for large implementations, that there is an additional role - or skill-set - which is required and which goes beyond what a traditional PM would normally offer, although sometimes it falls on the PM. Which is the need for someone to become a central 'hub' to the project in terms of understanding the holistic solution - not the PM aspects. i.e. The Solution Owner.

The key thing for such a role is that it should be someone who understands (or can learn to understand) not only the charity's requirements and strategies but fundraising/charity requirements more generally, as well as CRM, software and technology. The reason for this is because the implementation of sophisticated, flexible (and often expensive) CRM software systems is of course not just about the software but about building/configuring and using it with the people and processes in mind - and understanding the whole approach, design, dependencies and implications of design. Something I discuss constantly.

This means that when someone on the project, or a user or manager in the charity, has a question as to how the solution will work or how something fits in, or queries what will happen if we change something or what it will mean if something is left out and so on, then that person can be in a position where they can provide an answer - or know who they should ask in order to get an answer. It's a key need.

Ultimately, the role provides the charity with a central point of contact for design understanding and fundamental decision making and would usually also help provide requirements information.

Clearly this is not just Project Management. Historically, when I have done all this, I have called myself a 'Project Manager Plus'. But the more I have worked on implementing larger fundraising databases and with the new 'CRM' systems, the more I have realised just what a critical role this 'Plus' bit is in any such implementation (whoever does it!).

Recently, whilst working on one project, this specific role - the 'plus' bit - was described to me as The Solution Owner, and this struck a cord with me - it is indeed what I think such projects need. (On top of the project manager, business analysts, trainers etc, as appropriate, depending on project size and complexity).

One thing I should emphasise is that this is not a technical role, not a Solution Architect, nor a post-implementation Solution Owner (a role you do sometimes see advertised for), where it is more likely that it will need someone who is closer to the technical aspects of the system.

And as I stated above, the principle thing is that such a role should ideally be someone who understands the business - fundraising - and technology too. That way, they can help the charity and advise them on specific options as the project progresses.

I've also come to the conclusion that this is an especially indispensable role when implementing the (new) CRM systems where you can do so much with such systems and where it is not just a matter of configuring an existing vertical sector solution (such as a fundraising or membership package) - although it is by no means exclusively a requirement for CRM. Without such input, there is a real danger that you could go off down one route without understanding the implications, that you could over-customise a system too much when a simpler, alternative option could have been better, or you could lose track of just what is dependent on what and what interacts with what, which a central resource should be able to resolve. And the project team, client-side and supplier-side, will not have a single point of reference to help co-ordinate central requirements.

The Solution Owner is, IMHO, becoming a pivotal role for CRM and database implementations and is only likely to become more so.

CRM Dynamics template market for membership solutions already refining itself

 

I did some work recently for a membership organisation who wanted to buy a new database and they decided that Microsoft Dynamics CRM was the right solution for them. However, having decided that and having looked at one vendor of a Dynamics membership solution, their trustees asked them to review if there were other companies who could also provide a suitable membership system on Dynamics. Which, when I looked, was an interesting experience.

Just before I go on to what the outcome was, I should say that I think this sort of situation may start to become more common in the charity and membership sector. It may be that some organisations even choose a platform before even talking to a reseller - a practise which is certainly done in the commercial sector - but even if an organisation looks at 'traditional' package suppliers and CRM providers and plumps for CRM, then it will become far more common for them to be comparing at least 2 such business partners, or even more. And as long as we do this ethically and openly then this is no bad thing.

What my client wanted was a supplier who already had a membership "template" built on Dynamics for a UK organisation. They weren't a large or complex organisation so it made sense. And so I talked to a number of suppliers who I knew had or were planning to have such templates. And what I found was the number of options had shrunk considerably in the last 12 months.

For a start, several companies who used to sell such templates don't now. And I got some interesting feedback  from those companies as to why this is the case (NB I am paraphrasing here):

• We moved out of the sector - fair enough I suppose, although disappointing for the organisations who had already bought into them;
• We found that a template couldn't support everyone's needs - understandable from one angle but I'm not convinced that should matter so much if you have a good foundation and a solid approach. There is nothing wrong with starting with the basics and developing each installation differently and appropriately for each client;
• And even: Our solution wasn't as good as others on the market so we stopped selling it. Honest at least!
• There was also more than one who, tellingly, never got back to me when I tried to email or phone them…

Which means the market has shrunk to about 1/3 of the options I knew of a year ago, and I was left with only 3 suppliers who still sell UK membership "templates" for Dynamics: Excitation, Pythagoras and Silverbear. Additionally, m-hance offer a "modular" approach where they don't exactly have a template but do have different, appropriate modules they could provide for a membership solution; a perfectly sound approach too. Plus there were a couple of others who are still developing theirs.

What does this mean to you?

It shows that you need to take so much care when buying a new system such as this. Yes, one of the benefits of Dynamics (and similar CRM systems) is that if you do your initial implementation through company X, and then company X goes bust or you fall out with them, then at least you still have your Dynamics solution and you can go elsewhere for your support. But it’s not what you ideally want. Like any similar procurement, you want to buy into a company who is not just supplying you software but who is also going to be a good business partner for years to come, who can bring new things and ideas to the table, who gets to know how you work and who understands the membership sector. That's a real benefit.

You should also be aware of any Intellectual Property (IP) issues in such procurements. If a supplier is claiming IP on any of its software deliverables to you then what would that mean if you did want to move away from their support or if they did decide to stop enhancing their specific offering any more?

As a final caveat, I'm not suggesting templated solutions such as this are the only way to buy Dynamics for membership solutions, and I'm not endorsing the above suppliers. I can't say if they will still be selling their solutions in 12-18 months time. But the approach is certainly one option you can take. And I'm equally sure there will be other, new developments which could become good options in the future. The most important thing is to do a solid procurement and selection process and then you will be as sure as you can be that your final decision will be the right one.

How Not to Buy Software? The Astonishing Stats Provided by Capterra

Software resource portal, Capterra, has recently published a report on the findings from a survey they ran which examined how organisations make decisions when buying software - and it makes interesting and sometimes scary reading. For example, "1/3 of software buyers don’t demo any solutions before they make a purchase" and "another 22% just choose the first software they look at!" And very interestingly, "the more demos and options that software buyers considered, the less confident they were in their selection." Hmm.

And this survey included nonprofit organisations in its statistics…

Who gets involved with purchases?
The report details the types of staff involved in the buying process:

• CEO/Presidents were involved in 40% of the software purchases - and this level of person is most likely to be involved in software which includes "marketing" (read fundraising) and one of the sectors which they’re more likely to be involved in software purchases is the nonprofit sector…
• IT Personnel were involved in 55% of all software purchases. Although it does also say that one of the software solutions IT staff are most likely to be involved with is Database Management, which I hope means that more than 55% of database purchases involve IT staff to some extent…

Interestingly, the Most "Diplomatic" Software Purchases included CRM Software, where "job titles across all levels of the organization were equally represented in the software decision making process." I'm glad to hear a wider range of staff are involved in CRM purchases, but I'm not sure if I really want lots of people involved in the decision making process. (More about that in a future blog post...)

Of course, what is harder to quantify is what "involved" means for a purchasing decision. If it means being kept in touch and maybe ratification then that is very different to attending demos and making a final decision.

What do people look for in software?
One of the most interesting sections of the report is a table showing "The Most Important Factors in Software Selection". It's very interesting (some might say encouraging?) to see "Low price" and "Vendor's market share" so low in the table, and despite all the cloud-hype, "platform" is still only #9 on the list. Both "vendor responsiveness" and "software reputation" come above that - which shows how important the supplier itself is to the buyers.

Perhaps unsurprisingly, "Features/functionality" is listed as the most important factor. It's hard to get away from that. This is of course one of the downsides of "lists" like this - yes, functionality is important, and, for example, I often drone on about how it doesn't matter if software is/isn't in the cloud if it can't operationally support a charity - but I always encourage charities to consider features as just a percentage of a decision making process. Equally (more?) important are all the other issues such as supplier support, ease of implementation and so on. So it's not quite as simple as saying that the #1 factor necessarily outweighs others.

What can we learn from all this for a UK charity looking to buy new fundraising or CRM software?
Can a survey taken across a variety of industry sectors in the US also apply to CRM software selection for UK non-profits? Well, 50% of the survey's respondents have less than 100 employees in their organisation and 64% less than 500, so that's not so far off. And the "important factors" list tallies with my experience of UK charities' processes - not that that makes it right unfortunately. (And if you look at Capterra's website, then the Fundraising & Membership Software lists include names such as Blackbaud, Donor Perfect and Wild Apricot, so these are not insignificant companies).

But there is another table in the report which nicely sums up what organisations need to understand more, consider more and where they can do with help - and that is the Most Difficult Parts of the Software Selection Process table, which lists 3 key issues:

• Getting a clear picture of how well each possible software option could meet specific needs;
• Being able to make comparisons between software companies/vendors;
• Absorbing and understanding the information available about different software solutions.

This therefore shows what you need to be doing and considering when buying software. Which, I realise, can be easier said than done. Which is why I hope that posts elsewhere on my blog give guidance to how you can address such concerns. And there are other great websites with other useful resources such as LASA's Knowledge Base and TechSoup; and the various sector events held by the Institute of Fundraising, sector media and exhibition conferences, all of which can also help - look out for the free seminars at some of these. And use your peers too - the experience of other charities does help.

There are many more fascinating and enlightening stats in the report, not all of them so relevant to all the work we do in the UK fundraising/CRM software market, but still a great read!

---

You can download the full report from Capterra's website.

Salesforce and Microsoft Dynamics for Fundraising: Are We Nearly There Yet?

It's been over 18 months since I last gave my 'state of the nation' view on the shape of the (now not-so) "new" CRM systems in terms of their applicability to fundraising technology needs, and a lot has happened since; so here's my latest opinions:

Who's using Salesforce and MS Dynamics for Fundraising?
It's noticeable that even in the last 6-12 months, there has been a shift in the mindset of some mid-large UK charities which, for the first time, is starting to pay dividends for the CRM suppliers. It's well known that Barnardo's are the first large UK charity to be implementing Salesforce for fundraising, Greenpeace International are now doing so too, another national UK charity is implementing Microsoft CRM Dynamics for their supporter relationship management system with another to start soon, and Leukaemia and Lymphoma Research have been using CiviCRM for a while (as have MSF outside the UK). And there are more in the pipeline for all these systems. Plus, of course, there are many more NFPs using these solutions for non-fundraising applications.

So why now for larger charities?
Although Salesforce, Dynamics et al have been adopted by charities for several years for non-fundraising solutions, and although smaller charities have been using the systems for their fundraising needs, why are we now seeing the mid-large charities start to take this route? There are probably a number of reasons:

• There are naturally less such projects for the larger charities and those organisations that are/have been looking have taken until now to have made decisions - equally, such projects are not cheap, so there are of course fewer of them.
• It has still taken until recently for the sector to truly believe, and to have it really shown to them, that these CRM systems can provide the fundraising functionality they need - for too long, suppliers had just been saying "yes, we can do it" without any real supporting evidence or suitable background to make the larger charities comfortable. They aren't all there for all areas of fundraising but there's been huge steps.
• Inevitably, some charities have waited until someone else took the initial leap into this space, but with Barnardo's, Greenpeace and others now doing so, it makes it that much easier to see the benefits and possibilities.
• It has taken some time for the resellers and business partners (implementers) - not the software suppliers themselves - to show their credibility in being able to sell and implement these systems for fundraising. Not in terms of technology but in terms of showing the charities that their in-house fundraising knowledge, and how technology can be used for fundraising, is good enough to support such implementations. That said, I think this is still a challenge.
• The acceptance of the cloud is growing every day in the NFP sector, and there is less concern over security than there used to be. This has probably never been such an issue for IT staff at charities, but it did un-nerve trustees earlier in the cloud's evolution.
• Amongst the "templated solutions", the functionality itself has improved.
• The CRM software vendors and their partners are darned good at marketing!
• And last but possibly not least, some charities have grown tired of waiting for some of the traditional fundraising database suppliers to provide viable, cost-effective new releases and versions which they need for their fundraising. And there are definitely a lower selection of viable options now from such suppliers than there were some years ago.

So are the CRM suppliers having it all their own way?
Certainly not. The traditional fundraising database suppliers for large/mid-size charities, companies such as Blackbaud, thankQ, ACS (ex-IRIS) etc, have also been selling their software, some with good volumes, and so although the CRM systems are denting their sales they still haven't overtaken them. At least not here in the UK. And on the lower end, AdvantageNFP Fundraiser, Harlequin, even KISSS still sell plenty of systems.

Similarly, it is not just Salesforce and Dynamics who are selling 'CRM' systems. CiviCRM, a "CRM" system created especially for NFPs, is definitely growing in popularity here in the UK and even more so worldwide (and I'm going to be dedicating a blog to CiviCRM in the weeks to come); Workbooks.com are becoming an interesting option having recently made several sales to the membership sector; and I hear occasional things about Zoho and vTiger, but not that much. Sadly, SugarCRM doesn't seem to have made the inroads into the sector which I thought it might do (unless anyone can tell me differently?).

What's Next?
So what does all this mean now to other charities who might be looking to replace their existing fundraising database? Is it really any different to a few years ago in terms of what they can get or expect from 'generic' CRM systems?

Well, yes and no.

Yes it is different in that they won't be trailblazing (so much) any more, and they can hear and learn about other charities' experiences. Yes, in that (some of) the resellers and partners implementing these systems are more fundraising savvy now and should offer better professional services. And yes in that the cloud (which many CRM suppliers are tied to) continues to grow in acceptance and popularity.

But No, in that, at the end of the day, it still comes down to what is right for each charity depending on their needs, and the technology is just one aspect of any such decision. As I have expounded many times, there is no point buying a cloud-based solution or a whizzy CRM database just because it is that if it can't deliver what you need to support your fundraising operations. And that hasn't changed. There are still good, solid options for fundraising packages and there are good, solid reasons for charities to buy those, as well as CRM solutions.

I'm going to be blogging a lot in the coming weeks about some of these considerations, and some of the lessons I've learned when helping charities procure and implement both CRM systems and traditional fundraising databases, and those lessons are equally as important - more so? - compared to the software you ultimately use.

Finally, one last thought for now: I think the number of viable, good fundraising database solution suppliers has shrunk in recent years, especially for larger charities, and one great benefit the CRM providers have done is given charities a whole new approach which they can at least consider - and that is definitely a good thing, whatever they end up actually buying.

Why now may be the wrong time to be investing in Fundraising Software for larger charities

These are interesting times for large charities and their fundraising database needs. They are being stretched like never before in terms of delivering technological support to the fundraising teams and they are being asked to do things they didn't have to consider a few years ago - and being expected to deliver it.

But if that means that they - you - are considering replacing your existing fundraising database right now, then I would encourage you to think twice just at this moment.

Why? Well because the suppliers to this market are all in somewhat a state of flux. Take the 'traditional fundraising database' suppliers: Blackbaud are still selling The Raiser's Edge 7, which, although still provides solid functionality, is showing its age, and Blackbaud know they need to release some sort of replacement - or replacements - whether that is called RE8 or something else. But that's unlikely to happen quickly. Yes there is also Blackbaud CRM but that is probably still just for the largest users and still to really make in-roads into the UK market.

And two of their main competitors, thankQ and what was IRIS, have both relatively recently been acquired by other companies: thankQ by the Access Group, and IRIS by Advanced Computer Software (ACS). I think, in the long run, both acquisitions should be good news for their clients and prospective clients, but we are still in the early days of both takeovers, and they are still finding their feet in terms of business approach and in terms of their own next generation of software.

Which surely then means that the new (generic) CRM solutions should be the right thing to consider? Well maybe, but maybe not. They too are going through a few changes. Yes, they are growing their customer base (not quickly for fundraising applications, but steadily), but they both have their own challenges in terms of applying their technology and platforms to fundraising needs, and there is also the question of knowing which reseller or partner one should use if one does want to buy one of these systems.

Because there are a lot CRM partners out there. You could go for one of the big consulting firms, many of which have an arm specialising in, say, Salesforce and who have huge development skills and CRM backgrounds, but what is their experience of fundraising and working with charities? So think instead of a smaller, specialist partner, who knows, say, Dynamics and who also (says they) know fundraising. Could be good if you choose the right company but there are so many around and even those with some sort of track record in the sector still have minimal experience of implementing these CRM systems compared to the likes of Blackbaud, thankQ and ACS.

And we are all still learning about the CRM systems' true capabilities as of today - and what developments in CRM systems really means for us tomorrow as a large charity in terms of commitment, resources and budget.

So what do you do if you are a large, or even mid-size charity and you do need to replace your fundraising database now? Well, if you genuinely have a burning platform then you of course need to get moving. Or if there are other, genuine risks to the continued use of your existing system or you can positively show that your fundraising income is being hurt by using your current system (and I mean really show that - not just maybe, sort of just think that because it, say, can't "do social media"), then yes, again, you should start planning.

But if not, if you just think you might need to be moving soon, or you've heard that someone else has replaced their database with X or Y, then I would caution you to consider. I think that in another 12 to18 months, some of the above questions will be ironing themselves out. Blackbaud should hopefully be able to publicly give some timescales for their next steps, we will know more about the acquisitions of thankQ and ACS, and Salesforce and Dynamics should have more live sites up and running and actually doing their fundraising on their platforms.

Of course, in 12 to 18 months time, some other great unknown will raise its head and I'll be saying wait until… Nah, surely not.