IT for charities -
Guide to databases

This guide

The guide covers the following topics:

• Why have a fundraising database?
• Cost benefits of a fundraising database
• Options for software solutions
• Technical considerations
• Success factors in an implementation

Why have a fundraising database?

From a broad perspective, there are two general areas of benefits in a fundraising database: operational benefits and analytical or 'marketing' benefits. Operationally, a fundraising database must let you record details about your donors (and donations) and perform some standard functions (such as recording contact details/history, preparing acknowledgement letters, producing fundamental reports etc.) but it should also give you more knowledge about your donors and let you use this information to raise more money and reduce costs. It could help you plan ahead, monitor your fundraising activities or target specific donors/causes/campaigns. In many respects, a fundraising database is a marketing tool - you are, after all, marketing your charity to your donors and prospective donors. There are many specific reasons how a fundraising database can help you.

These are just a few examples:

• Information exchange within the organisation
• Simple recording of donor/prospect data
• Consistent data to improve enquiries/segmentation
• Recording the contact history with a person/organisation
• Campaign/Appeal analysis
• Production of financial reports
• Production of analytical reports
• Printing labels, Mail sort
• Printing acknowledgement letters and other (appeal) letters
• Database segmentation
• Managing and monitoring covenants/gift aid
• Managing and monitoring membership schemes
• Managing and monitoring events
• Direct Mailings
• Managing telephone campaigns
• Recording volunteer details
• Covenant/gift aid administration including the production of tax forms
• De-duplication
• Legacy management

Cost benefits of a fundraising database

Other explicit costs might include: producing appeal letters, labels, financial reports, database segmentation, faster entering of financial details, administrating covenants and relevant IR tax forms, electronic fund transfer for standing orders and direct debits. Implicit benefits are harder to put a figure on. For example, the fact that a fundraiser can check the database to find out if an individual contact is also a senior manager in another company they are dealing with, which could lead to further donations. Or knowing that another fundraiser in the organisation has recently approached a particular person for a donation, ensuring two people do not approach the same prospect. Other implicit costs might include: analysing past trends, analysing database segments, relationship fundraising, easy viewing of communication history, donor profiling, diary/reminder system ensuring appointments/calls are not forgotten.

Options for software solutions

• Commercial fundraising packages
• Contact Management software packages
• Writing your own database
• Bureau services (Outsourcing)

1. Commercial fundraising packages

Some of the main reasons and benefits for choosing a commercial fundraising package are:

• They are written specifically for fundraising. There are many necessities and areas of fundraising which mean that standard 'contact management' or 'sales & marketing' databases may not be applicable to fundraising (e.g. donations, covenants, relationship fundraising, legacies etc.) and the view and methodology of fundraising also often requires a unique solution.
• Why re-invent the wheel? If there is a solution pre-written, why start trying to write your own or 'work around problems' of another software package.
• Experience of other fundraisers. The fundraising databases are used by other charities and fundraisers that will mean you will benefit from their previous experience and requests for functionality in the package.
• Cost: It is often cheaper than writing your own system. This can be a contentious issue (!) and is covered in more detail in the sections below. But for charities with sophisticated requirements this is far more likely to be the case than for smaller charities that might only have simple needs. If a small organisation does have a volunteer or employee who does know how to write a PC database then some of the costs can be saved.
• Speed of implementation. A pre-written system does not need to be designed by yourselves and you should be up and running far more quickly than writing your own.
• Support. Most commercial packages offer support hot lines and with support staff who should understand fundraising and their packages.
• Future-proofing. Most commercial packages offer 'maintenance contracts' where you can pay a set amount each year and receive enhancements and updates of the package. This can be quite a benefit if a company keeps on top of the latest technology, as it will mean you can always have the latest available system.
• User groups. Many commercial suppliers have a user-group where you can exchange ideas and add to a 'global voice' to talk to the supplier in case of generic problems.

• Cost. Almost all the fundraising packages listed on the "IT For Charities" web site cost thousands of pounds; plus support, training and any new hardware required. They can be/seem expensive in terms of actual outlay.
• Functionality. Can the package really do what you want?
• Over-complex. Does the package do far more than you will ever require? This is a common complaint about all packages in many industries. (On the other hand, better to do too much than not enough?)
• Inflexibility. How adaptable is it for you to adjust the package to your own requirements? Can you add your own fields or write your own reports? And how easy is it? What about the future when your requirements might change; will the package still be able to meet your needs?
• Companies can go bust! It is rare but companies can go bust, in which case you are left with an unsupported system with nowhere to go for enhancements.
• Enhancement requests. Just because you ask for an enhancement you will not necessarily get it. Commercial companies often tend to add new functions only where they feel it will be beneficial to more than one specific client (or, if we are sceptical, where they feel it will increase sales.)
• Compatibility. Less of an issue these days, but you need to ensure a package is compatible with your existing or planned software and hardware. And can it transfer data in and out to your word processor and so on.

2. Contact Management software packages.

A contact management database is just that: a software package written to let you record information about your contacts and how you contacted them. There are many packages available from simple and cheap 'shareware', through to more sophisticated commercial packages and very expensive sales & marketing solutions. Some are oriented towards specific markets (such as sales) while others are more generic to general contact management.

Some of the benefits of a contact management system are:

• Cost. You can buy contact management software for hundreds of pounds (or less - or more!) as opposed to the generally more expensive fundraising packages.
• Pre-defined fields and functions. All contact management software should come with many useful pre-defined fields such as name, address, telephone numbers, note fields, contact dates and so on. These can be very useful for many fundraisers. Many will also come with some simple pre-defined reports and functions such as transferring data to word processors.
• User defined fields. Many of these packages also let you add your own fields, which might possibly be used for your more fundraising-oriented data.
• Ease of use. They can be simple to use, either because they don't need to offer much and/or because their fundamental functionality is straight forward and they are written for a wide number of applications. Not always true of course.
• Good start-up solutions. They can be good for a start-up charity, which may want to move on to more specialist fundraising software later on. If this is the case, then it is immensely useful if the contact software can 'export' all its data out of its database so you can transfer it into any new package at a later date.

• Not written for fundraising. An obvious but important remark. If you buy a contact management package then it is not likely to be written for or oriented to the type of work, which fundraisers require (e.g. donations, covenants, relationship fundraising etc.)
• Donations. This is obviously a fundamental aspect of fundraising and most contact packages will not have donations as a pre-defined field. This may not be a problem if, say, your organisation mainly receives a small number of large donations (corporates, trusts etc.) but if you receive many smaller donations then you need to decide if the package can record them in a useful manner; useful usually meaning that you can report on them easily.
• Covenant management. Likewise, clear areas, which contact management systems, are extremely unlikely to cover.
• Little analysis/database segmentation. The cheaper contact software may not offer much analysis, as you would want to have it. Can a package analyse/segment by any field?

3. Writing your own database

Benefits of writing your own database can include:

• Simple. If you are a small charity with simple requirements then it may well be that you really do not need any of the sophisticated requirements offered by commercial fundraising packages. It is not difficult to write a fundamental database with name & address information, basic recording of donations, a few simple reports and an export function to a word processor for writing letters. It can and has been done successfully many times.
• Cost. Again, if you do want the simplest of databases and you either have an employee or a volunteer who already knows how to write databases, then the cost can be kept down.
• Designed for your requirements. There may be cases where you have to have something written for you because you have specific requirements, which a commercial package cannot match. And you can have reports written which match your output requirements exactly.
• Not just for fundraising. For 'organisation-wide' (or "corporate wide") databases where you might want to hold information other than just fundraising all on the same database, then you could consider a database written especially for you. For example, if you also wanted the public's requests for information, detailed child adoption (or similar) schemes, internal data, cause-related information, research and so on.
• It is yours to change. If you do get someone to write a system for you then you will also probably have access to the database structure and 'source code'. This means that if there is someone in your organisation who knows how to program this database then they can change it as and when you want it changed. And potentially far quicker than with a commercial package where they need to consider the affect of any change on all their customers.

• They are not pre-defined. As stated above, it is a common misconception that you can simply buy a database package such as Access, Paradox, FoxPro, Cardbox and so on, and that is all there is to it. All these packages are simply tools, which let you write your own system, but you need to add everything to it: fields, lists, screens, functions, reports.
• Design. You have to design your entire system. This means thinking about all the data, which you want - or might want - to hold. It means meetings with users, planning, writing a specification, designing fields/screens/functions/reports and checking to see if you have thought of everything. If you are getting a company to write a system for you then if you forget anything at this early stage then they are highly likely to charge you more later if you want to add/change anything.
• Cost. Again, although it can be cheaper than buying a pre-defined package, there are many cost considerations. For a start, if you are considering getting a commercial company to write a system for you then this really can be expensive. They may well charge for feasibility & design as well as programming and no programmer worth their salt will be less than several hundred pounds a day; and it will take many days of their time. Even if you are writing the database 'in-house' (i.e. having your IT staff write it) then all the above issues can add up.
• Time. Writing your own database can take a long time and one of the sad facts about the computer industry is that projects always seem to take far longer than expected! This is not just a truism.
• Support. Who will give you support after the package has been written? What about help screens? Or a user manual?
• No future proofing. This in itself can outweigh many of the advantages of writing your own database because, once you have written it, then a little later, technology (and your requirements) will change and you may be left with an out-of-date database. If you want it changed or updated then back come those costs all over again.
• Database querying/reporting. One specific issue of writing your own database but where you want other people to be using it involves querying the database. Many packages do offer 'graphical query interfaces' but they are not always user- friendly and can require a degree of technical comprehension on a user's part. This is one of the most common complaints of any user, not just in fundraising - that their database can record data okay, but it is very complex getting the data out.

4. Bureau services (Outsourcing)

• Cost benefits for high levels of transactions. If you receive many donations then it may well be worth investigating the costs of a bureau service in receiving, inputting and even sending acknowledgement letters for them, as opposed to what it would cost you in-house in terms of computers, salaries, people and time.
• Internet connection cost benefits. Some bureaux offer the facility so you can link to the bureau through the Internet via your ISP (Internet Service Provider). This means you only pay the price of a local call.
• Other cost benefits. You won't have to pay for expensive hardware or software in- house and their maintenance and upgrades, specialist IT support staff or system development.
• Up-to-date technology. The bureau will be investing in its equipment and software.
• Ease of set-up. You should not have any complications of setting up the actual database.

• Actual cost. Some bureaux are quite expensive; often far more than a top level fundraising software package. And there is also the cost of setting up the communications links between your offices and the bureau, and the on-going phone/leased line charges.
• Not having data in-house. This is probably a conceptual issue rather than a true disadvantage but it might be important to some organisations. In many instances, to all intents and purposes, you can use your data in the same way as if it was in- house. It does mean you are reliant on the bureau ensuring their hardware is always available and you should discuss how they manage possible hardware failures (and fault tolerance).
• Speed. With the latest technology, speed is becoming less of an issue but you need to be clear about how good performance will be. And this can mean high costs.
• Communication breakdowns. It is possible, although getting more unlikely these days that you could find you are unable to connect to your bureau if there is a problem with your communication links.
• Security. Both in terms of having your data held away from your offices and as far as stopping security violations of your communications links.

Technical considerations

• Database size and users. Your database should be able to handle a far higher number of records and number of users than you currently have. Both in case of potential expansion on your behalf and in general as it is worth avoiding the use of a system, which you are pushing to its very limits.
• Industry standards. MS Windows is still the industry standard. If you want to diverge from that, make sure you are comfortable with doing so; you can get hardware support and enough software applications. Windows can also help 'future-proof' any database development and most people are familiar with its interface.
• Relational databases. This means that you only need to update a data item in one place for the system to update other 'linked' records. (For example, if someone changes their surname, you should only have to edit that information once and the system should update any other instances of the name automatically).
• Record locking. Ensure that record locking does not mean that two users cannot do two different tasks at the same time on the same record (e.g. run a report when another user is updating a record).
• Internet. Is that important to you?
• Security
• Customisation?
• Inclusion of PAF (Postcode Address File)?
• A report writer for ad-hoc/specific reports
• The ability to query ('ask a question' of) the database on any item of recorded data
• BASC?
• Export / Import facilities? Client/Server. It is probably also worthwhile explaining very briefly what client/server technology means and what its benefits are: With client/server technology, the workload is split between the PCs (the client) and one or more larger computers (the server) on a network. The data is still stored on the server(s) and requests are sent from the client to the server but, whereas in a traditional network environment all the processing is then done on the client, in a client/server set-up the processing is split between the client and the server.

• Performance. With correctly specified hardware, speed should improve, sometimes dramatically so.
• Scalability. If a database is based on client/server technology then there should be no significant degradation of performance regardless of the size of the database or the number of users.
• Robustness and data integrity. It includes functions, which protect your data from accidental damage. The main issue with implementing a client/server implementation is that the server needs to be a very powerful machine with plenty of memory, and hence more expensive. Each application will require its own specifications.

Success Factors in an Implementation

The following points are worth considering in any database implementation to help a smooth and successful process:

• Management Support. Top-level management need to support the project. This means that it will get the budget it requires and people will have the time and training they need to ensure the project succeeds. This probably means senior managers being involved in some way from quite early on so they understand the key benefits, which a new system will bring to the charity.
• Training. Far too many projects fail because there is not enough consideration given to the training required. There needs to be careful investigation and discussion to find out who needs to be trained in what, and there needs to be the budget to cover that training and potentially more in case the system expands or people leave.
• Project plan/team. This will depend upon the size of your database, the number of users and the complexity of the project, but it is good practise to have a project plan and team in place, with checkpoints along the way to ensure you are keeping up with your original timescale.
• Organisation-wide use. For a fundraising system, you do not want just one person using the database, partly because if they leave/are ill then no-one can replace them, but probably more importantly because an organisation which uses information gathered on a fundraising database more widely will benefit far more.
• User-friendliness. If a system is not user-friendly then users will not want to use it and the whole project may fail.
• On-going support. If you are using an outside supplier then make sure they can offer the support you need. (Talk to existing users). And if you are having a system developed for you by your own IT staff then make sure they will also be on-hand to guide you through any problems, especially when you first go live.
• 'Garbage in, garbage out.' A well-worn phrase, but a worthy one. If you end up having inconsistent or incorrect data input then you couldn't get accurate or worthwhile reports from the system. Ensure that there are as many automatic data input checks as possible.
• Your own measurements of success. What makes a project successful? Only you can say for your own database. But, as was said at the beginning of this guide, ultimately you will want to be increasing your revenue. So you can therefore measure success by recording higher fundraising and lower costs, but you might also want to measure it in other terms, for example: increased awareness of your donors, increased awareness of your charity, better feeling amongst your staff, happiness in using the system, and so on.

Other fact sheets in Organizational planning
Fact sheet index

Email a question

Copyright of Alba Fundraising Ltd or the individuals or companies who contribute to this website. This material may be copied and distributed freely on the understanding that no profit is made from doing so.

Disclaimer: No payment is received from suppliers, companies or individuals for publishing their details on this website. The information is offered by those in the fundraising arena and whilst we try to make every effort to ensure the integrity of this information, Alba Fundraising Ltd cannot be held responsible for any inaccuracies, or any loss or inconvenience that may be caused by using this site.

home | resources | fact sheets | services
site map | download the site
Alba Fundraising Ltd.
Tel: 44 (0) 7775868768, Email: alba@alba-lewis.demon.co.uk
Web: www.professionalfundraiser.org.uk

Web site design by Vivid Interactive.