Initial Thoughts on ThankQ's Acquisition by The Access Group

The Access Group (Access) have just announced that they have acquired fundraising database supplier, ThankQ. These are my initial thoughts on what this means to ThankQ users and to the UK NFP sector as a whole.

• Access' have existing NFP solutions which are already used by 500+ UK organisations but they do not have another "CRM" system which they sell to charities (although they do sell GoldMine, but that has fewer applications for NFPs). So at first sight, ThankQ could fit well into their portfolio. And because they don't have an existing fundraising database system, they won't be migrating ThankQ users to another system they already sell. So, that would seem to suggest they see it as a system they will continue to support. Which should be good news for ThankQ users.
• One of the potential issues which ThankQ did have as a company was that, despite their sales success, they were still a comparatively small company with lower staff numbers and a much lower turnover than their key competitors such as Blackbaud, IRIS et al (let alone Salesforce and Microsoft!). So they didn't have the same money or resources to develop their software as per their larger competitors. So, if Access are serious about incorporating ThankQ as a system which they intend to continue to promote to the NFP sector, then it might be that they could invest more to a larger R&D budget to the software. In which case, that could really help ThankQ and its user-base.
• Of course, one of ThankQ's main plaudits as a company was its flexibility and approach, which it was able to follow as a small, independent organisation. It will be of high interest to ThankQ's existing and new customers as to how that now pans out. I wouldn't see any reason as to why Access would necessarily change the fundamentals of that, but it would be foolhardy to think that they wouldn’t want to introduce some of their own methodology and culture to their new group member. Like any acquisition, we shall have to see what is good or bad about that.

But how does this impact the UK NFP sector as a whole in terms of fundraising/CRM database suppliers?
ThankQ are (were) certainly one of the more successful, completely independent companies who purely sold just one fundraising database, so it didn't take a futurologist to predict an acquisition could eventually happen. And of course what we have seen over recent years are the larger players in the market buying their competitors; Blackbaud, IRIS and ASI being the obvious examples as well as others like TSG and Miller Technology. Some products have remained within these companies' portfolio but others have not, or have not had the same commitment to their on-going development. Which in some instances has meant less choice for charities.

So it has to be said (unless there is some other reason for Access' acquisition of ThankQ, or unless Access are now about to go on a spending spree and buy other similar systems - and I have no reason to believe that either of those issues is the case) that this acquisition should be no bad thing for the sector. A good database should hopefully remain a good database and a strong competitor but possibly now with more investment. I hope I'm right.

The Challenge of Secure Communication Records in a Single, Shared database

 

Most database systems can record contact/communication history with your contacts, prospects, donors, benefactors et al. i.e. letters/emails, meetings, phone calls, services used etc. But what if your organisation and security needs mean that only some of your users should only see some such communication records?

Let me give 2 examples:

• If John Smith is a major donor, then you will want your major donor fundraisers to be able to see the communication record of the important meeting you had with John last week; but what if the detail in that meeting was so sensitive that you don't want fundraisers in other teams to be able to see it?
• Or, what if you are using your database for benefactors as well as donors, and what if Jane Smith is both a donor and a benefactor - thus, if you add a communication about Jane which only your charity's "Services' users" should be able to see, maybe a Counselling Session she attended, then how do you stop the fundraisers from seeing the fact she attended that session?

Now, some database systems offer functionality around security so that they can completely hide such communications from specific users. However, if you completely hide all such communications, then what about the following case: a fundraiser opens Jane's record and because he can't see that Jane had 3 communications in the last month with your charity's service users, he thus has an incomplete picture of Jane's interaction with you and might therefore approach Jane with insufficient or inappropriate knowledge.

And if they can't see the total communication history, and you are basing any appeal letters, event invites on recent or total communications made, then such analysis may be skewed.

So, how do we show all database users that some sort of contact/communication was made with a donor/contact, but only show relevant users the details of such communication?

It isn't necessarily as easy as it might first sound. Many systems have "one line" (summary) overviews on a Communication History form showing all communications at a 'top level', and then you drill-down (double-click) into each instance to see the details of a particular communication made. So at the most basic level, you want to stop some users from being able to drill-down into the separate communications where they are of Type X etc. This might be possible in some databases.

But taking this a step further: if you, say, have the communication "subject" or communication "type" on that one-line overview, even those few words might tell the "wrong" users too much about that communication - especially in the example of where donors and benefactors are all held on the same database; in that instance, even a subject such as "Counselling Session" might be considered inappropriate for fundraisers to see.

So, ideally, you want one user to see a view where the subject/type is the full details, but another user should only see that "some form" of communication was made but not the details. That can be trickier than it sounds for database developers.

So I throw this question out to you all: if you use a database where this problem has arisen and has been resolved, then do let me know how in the comments below. Or if you are a database supplier who has got around this problem, tell us how in the comments below. Or if you have ideas/thoughts on any of this, or further examples of similar issues, again, add them below. I'd love to hear more.

Should We Be Buying Fundraising Software Anymore?

The case for not using fundraising software per se...
It is highly likely that on your fundraising database, you will have donors or prospects who also have at least one other "type" of connection with your organisation. e.g. they may have bought products of some sort from you, they could be a ticket buyer, they might be a benefactor, a trustee, a volunteer, a subscriber/user of your website and so on. In which case, you may also hold their details on another database as well.

So if that's the case, then should we really be buying fundraising software anymore or should we be buying an organisation-wide system which can manage all this information?

Because the problems with having "isolated" fundraising databases include the following:

• They only store fundraising-related information about your donors/prospects and so you don't know about their wider engagement with your charity. In which case you don't have the full picture which means you might not be getting the most out of them - or helping them as best they want to be helped - or you might be communicating with them inappropriately.
• You might be writing to or contacting them at the same time as someone else in your organisation is also doing so - you can't manage an organisation-wide communication strategy or central contact management if you don’t know and can't control what other teams in your charity are doing.
• Having isolated systems (fundraising and other) engenders the "But it's my data…" paradox and problem. (Why a "paradox"? Read my previous blog post on what to say when someone says "It's my data"...)
• It is harder to do organisation-wide data analysis and marketing.
• And if you do want to "integrate" systems - make different systems "talk to each other" - then sadly that really isn't as easy or as cheap as you might hope or be lead to believe. Even integrating two databases is tough, let alone multiple systems.

On the other hand...
But if it is that simple, that obvious, then why is there still such a market for fundraising software and why don't all charities start to use a single, centralised database. Unfortunately, it isn't that simple.

• Specialist functionality: Fundraising needs specialist functionality in their database, from income processing, Gift Aid and managing direct debits, through to relationship management and prospect research. And other areas of your charity will need specialist functionality in their databases too: trading, websites, management of your services/service delivery and so on. And one, central, large database system may not be able to manage all that - or if it can, then can it do so with the same high levels of functionality that 'best of breed' systems can do?
• Data/database/organisation/change management. Having one, large database makes data management and change management a lot more difficult, involved and time-consuming. If you only have fundraisers to think about then any change or new data item only needs to be considered for them. But if you have more teams and users, then it will be far more work when considering and then implementing any such changes. Similarly: where would the database management reside for a charity-wide system? It probably isn't appropriate for fundraising to manage such a broad database and, often, IT aren't really the best people to do this sort of thing. You could have a dedicated "CRM" department but that's probably only cost-effective and practical in larger charities.
• Budgets/Organisation policies. Many charities have budgets specifically for each particular department so if you want to buy an organisation-wide system then that needs to be addressed.
• It's hard work! Organisation-wide systems take a lot of work, time, effort, resources, discussion, buy-in and money. And often present a riskier proposition.
• They aren't always appropriate. For some charities, it might be appropriate to completely separate the departments and functions and thus the databases. I think this is getting less common but it could be the case. Of course, even if it is right for one organisation, that doesn't necessarily make it right for another. Organisation size can play a part - smaller charities might actually find it easier to create a single, central database than larger NFPs.

But still - will we buying Fundraising Software? Should we...?
Having said all that, none of the above are necessarily reasons not to consider an organisation-wide database, they just need to be understood and planned for. And if it is the right route for your organisation and you can plan for and implement it successfully then it could well offer you significant benefits.

It's also true that some of the 'traditional' fundraising database suppliers are getting smarter and are offering systems which can manage more (much more in some cases) than just fundraising functionality. That may well be an option for some charities.

But in the meantime, whilst we are still working around some of the issues listed above, we will still be buying fundraising software at least for now.

Learn what your software can do before customising and changing

When implementing a new database and you're at the stage of defining the final specification with your supplier, it is often tempting and exciting to ask the supplier to customise the software for your precise needs or for an especially fancy piece of functionality. My advice: unless it is a "business critical" operation which you have to have customised for you or unless you can show real benefits from doing it - wait. Hold off. Don't do it just yet.

(By the way: by "customising", I mean more than merely "configuring" the database - I mean that customising would mean the supplier would need to make bespoke changes for you, write code which would change it from the norm etc. See my "Keeping it Vanilla" post for a more detailed discussion/definition).

Why? Because, as I said above, this is a time when you are (understandably!) excited about the new system, but it is also a time when you may therefore decide to request functionality which isn't really going to add that much value but which may add significant financial investment… Yet at the same time, it is quite likely that you don't yet know the new system you are implementing, at least not at any great detail, and even if your supplier does (well, we hope they do!), then conversely they may not fully understand your needs. (And of course they may be quite happy to accept a few extra pounds/dollars for that extra piece of custom work…)

Instead, add such ideas to a list, learn more about what the software can do and then, once you really know the software, then you can decide if you really want to invest in that extra, whizzy functionality. Because what you might find is that either that function is not quite so important as was first envisaged, and/or you can achieve 80% of what you wanted just by configuring the database yourselves for free. Plus, you will keep the initial implementation simpler, quicker and cheaper, with less risk and you can approach it in a far more structured way. And you can then move on to your Development Stage of the project and really start to add value and benefits where you really now know what you want.

Keeping Changes of Database Supplier in Perspective

 

If you are considering the procurement of a new fundraising database package and you talk to another charity about what they use, then you may well find that they have migrated from one "recognised" fundraising package supplier to another. e.g. to or from companies such as ASI, Blackbaud, IRIS, ThankQ and so on. Or indeed, if you peruse internet discussion boards, then to and from CRM systems such as Microsoft CRM, Salesforce and SugarCRM. As such, you might therefore wonder why someone is no longer using the very package which you were considering buying.

My message is: don't necessarily worry, find out more about each such situation and don't lose sight of the more important factors in any database implementation: the data, the people and your business processes.

Of course, if you find patterns of desertion from one system then that could be an issue (and there are indeed one or two suppliers who I would be more concerned about if you told me you were buying their software now), and if you do find no-one who can give you good feedback about supplier X then that should at least make you think twice.

Equally, there could be good reasons for a charity to move to a new supplier: their 'old' database might not be appropriate for them anymore (e.g. they could have grown out of it, changed technology platform); in-house skill-sets may have changed; the supplier's costs might have escalated significantly; the supplier may have been selling, or now be selling multiple systems and therefore have dropped support for one database. Or the 'old' supplier might not be providing perceived value anymore, might not be releasing new versions, might have cut-back severely on support.

But all too often a new system is purchased for reasons not truly central to the database software itself: a new senior manager might arrive at a charity and prefer database X; there could be loss of faith in the 'old' database when in actual fact it was more down to the poor data, lack of training, lack of investment, a great database manager leaving and not being replaced etc etc; there could be a misunderstanding or lack of knowledge about the capabilities of the old database; an out-of-date version might be being used; or a charity's IT infrastructure might be so poor that the old database is running so slowly that any modern database would struggle…

And with the more successful database suppliers, if even a small percentage of their clients are unhappy, then that will be more visible to the market compared to a smaller supplier who might only have one or two users jump ship over time.

So consider carefully if you hear about a charity moving between fundraising systems and you are thinking about buying the database which that charity just dropped. Try to understand why that charity replaced their old system, who was involved with that decision, how long ago - what they learned from the process. Talk to as many such other charities as you can and get a broader picture. And remember that whatever system you buy, the software is still only one part of the success of that new database.