Can I Use Microsoft Access for my Fundraising Database?

As I am asked this question regularly, I thought it would be useful to give my thoughts in this blog. So, the short answer to this is yes, you can use Access for your fundraising database, but that doesn’t mean you necessarily should. As I have blogged before, if you want a fundraising database then my initial response would always be that you should look to see if an existing fundraising package could meet your requirements, and frankly, I would be surprised if one couldn’t for the vast majority of charities and NFP organisations.

But if you are determined to develop your own fundraising database, then yes, Microsoft Access can of course do the job – as can other similar development platforms such as Filemaker and MySQL.

And as much as many people (love to) criticise Access, it isn’t that bad a development platform, it can be simple to create a comparatively simple database and if you only need to use it within one office for a few people then it can do the job. There are some templates available on the web which can get you started, there is a book which might help you, written some years ago by Peter Flory on how to build a fundraising database in Access or similar systems, and because it is so widely used, a benefit of Access if that if you have a bespoke database developed by one person then, in theory, someone else could help you change/further develop it at a later date. Indeed, there are many independent Access developers who do regular work with charities. That said, it is never easy picking up someone else’s program unless it is extremely well documented, both within the code and outside.

But be aware of its key shortcomings too: it isn’t really suitable for large volumes of data (even tens of thousands of records can affect system performance), it isn’t automatically web-enabled (so you can’t access it from home or remote offices just like that) and of course it still requires all the design and development work which any bespoke system would. So it isn’t free!

So I repeat, yes you can use Access for a fundraising database but please consider all the other options first.

What does make CRM software user-friendly?

In almost all ITTs I have helped with, the client has asked that “the database software must be user-friendly”. But what does that really mean? Is it such a personal thing that no database package can ever be fully user-friendly for all users? And who should it be user-friendly for? Just the end-user or the database manager/technical staff as well? Can we really define user-friendly? Well, I’ve seen a few CRM packages in my time, the good, the bad and the really ugly, so these are my top requirements for user-friendly database software:

• Screen layout

o       This is generally what people think of when they mean user-friendly. Clearly, screens (forms) should not be too busy - don’t cram fields together on one screen, keep it ‘clean’, keep common fields together on one screen/tab, don’t use really small fonts. It’s all common sense but unfortunately it isn’t always that common.

o       Screens should ideally be customisable for different users/types of users. This can really help: why would the DM manager want to see the same fields or menu items as the volunteer assistant? And no end-user wants to see all the hundreds of icons which the database manager needs to see, so don’t display them to such users.

o       List columns can be changed by users using click-and-drag. A very specific point, but databases inevitably have lots of forms with lists of records and ‘one to many’ type entities (which when clicked on, show much more information behind them); so if a user themselves can simply change what is important to them on such lists, and continually change that if their requirements change, then that can really help user-acceptance.

o       Not a clunky look-and-feel. Okay, that’s hard to measure and a little obvious but I have seen some dreadfully clunky systems even in the last few years and there is nothing more off-putting as a first impression.

• Overall navigation

o       Standardisation and familiarisation. There is little reason not to use a standard approach for the look-and-feel of a package’s general navigation. Whether it’s the familiar Windows/Mac environment, an “Outlook look-and-feel” (e.g. MS CRM), the use of browser/hyperlinks, good use of double-clicks, and increasingly, the ability to click-and-drag a la Google maps/finance graphs etc.

o       Consistency across the whole package. Please!

o       The ability to add ‘bookmarks/favourites’ (as per web browsers) so that, rather than having to remember which 4 clicks are needed to get somewhere, common functions and records can be accessed from a user’s front/home screen – especially on feature-rich databases and those with multiple screens and icons.

• Customisable terminology. Users love to see terminology they are used to. They don’t want a field which says ‘region’ if their organisation uses ‘areas’. They don’t want a ‘donor analysis & performance report’ if they run weekly ‘donor update’ reports. There are limits, of course, and packages are still packages, but the more an organisation’s own terminology and language can be used, the more user-acceptance you are likely to get.

• Automation: automating tasks can be extremely beneficial. Mostly in processes (e.g. when sending a mailshot, the ability to do the mail merge and update the communication history on a donor’s record – all using one click), but also in terms of data integrity; if you enter ‘Mr’ on a supporter’s record, then surely the gender should be ‘Male’.

• Simplicity when creating queries/reports. This is one area where the trade-off between sophistication and simplicity may be difficult. It should be possible to use a GUI to create simple ‘list’ type reports, and I like the ability to make reports parameter-driven so that a user can learn how to use just one report but run it against multiple sets of records or for multiple scenarios. But when it comes to more sophisticated requirements, there is no getting away from the fact that a report needs to be created by an experienced/database-savvy individual – but hopefully they can make that available as a simple report for the end-users. No SQL for end-users, please.

• Intuitive. This is the second-most common request by organisations, that the software “must be intuitive”. But this is so different for different types of people, for different levels of skills, for people with different experience of databases and so on. I would say that if much of the above can be met, then the intuitiveness of the software should follow. But that doesn’t mean you won’t need training…

• Other points:

o       Simple integration with other packages: Word, Excel etc. Yes, great. One-click to make a report into a Word or PDF document; right-click to export to Excel.

o       Speed? A lightning fast database won’t make the software automatically user-friendly, but a slow database sure can make it feel unfriendly.

o       Easy to update. One for the technical guys and support staff (and implicitly the end-users): if software updates can be centrally deployed rather than having to go round each PC with a CD…

o       Small, specific features can really help. Just a few examples: the ability to drill-down in reports (to further levels of the report or even into supporter records), predictive text on drop-down fields, simple moving between records/opening multiple records at the same time, colour coding for specific records/statuses. I’m sure you can think of others. 

o       Help screens? Even better if they are customisable by a client. Good error messages?

It is interesting that when considering much of the above, one does need to consider the pay-off/difference of user friendliness for end-users as opposed to database managers/the technical staff. It may take a database manager some time to make the database terminology correct for their organisation but it will help the end-users enormously; they may need to create multiple versions of a form for different groups of users, but it should cut down on their support calls. 

And what of the future? Is the iPhone generation going to change the way CRM databases can be used? Is touch-screen the future? Or voice control?! Basically, if the software is simple (okay, that’s still subjective), customisable and follows standards then that’s a good start, and our desire to minimise everything to the size of a mobile phone should still reflect that.

A CRM Database Doesn’t Mean You Can Now Do CRM

This is a brief, simple message: just because you have a CRM database does not mean you can automatically "do CRM". CRM (Customer Relationship Management) is not about software – CRM is a policy and a practise and a whole culture – not (just) a database. In fact, it is possibly one of the most abused terms in the IT industry and has been used to describe so much software that a few years ago had a completely different moniker.

That said, the good news is that if you are a NFP organisation then it is highly likely that you already practise good CRM – if you look after your clients, manage your donors, communicate well with your supporters then you are more than half way there. I believe that, in some ways, charities have been ahead of the commercial sector for years in terms of “CRM”, as charities have always known how important it is to look after their supporters and stakeholders.

So, yes, a good database will of course help your CRM strategy. It should do loads of things for you: keep contact information up-to-date, enable you to understand your supporters better, help you communicate with them better, in a more targeted and efficient way, record their correspondence with you, record all their activity with you, mean you can interact with them online and offline and store centrally all such interactions, allow you to allow them to tell you what they want to hear from you…

But don’t let any software vendor tell you that if you buy their database then you will immediately, magically be able to “do better CRM”. It is your organisation and their approach which defines that. The database will help but CRM database software will not automatically implement CRM at your organisation.