A volunteer database system basically does three things:
In doing these things, it provides the following capabilities:
You want to know of the people with key interests or abilities you need, so you can pull in specialists that may be unable to participate in just any event. You want to know who you haven't contacted yet, so you can continue trying to reach them. You want to know who to contact by email, who to contact by phone, and who is best contacted by one of their friends.
A key requirement of this system is that it be foolproof, easy to use, and quick to enter data into. The reason is simple: Either you're going to be doing all the data entry yourself and you want to get through it as swiftly as possible so you can get back to other work, or you're handing the data entry off to other volunteers who may not have very sophisticated computer skills and will either be making mistakes or bugging you if they run into problems.
To emphasize the importance of speed-of-entry, if you can enter data for 20 potential volunteers per hour, and you get one real volunteer for every 10 potentials, that will each put in a couple hours time, then you're investing 25% of your resources into volunteer data entry. Minimizing the amount of data entry time per potential volunteer means a larger proportion of time that can be invested into more useful pursuits. As well, getting better data into the system may help you focus your time into the people most likely to want to volunteer for your event, saving you time on the phone and on teaching people how to do things. This directly increases the productivity of the organization, and enables it to focus on the things that will help achieve its objectives.
The Democrat's Access database tool that I used in the 2004 election did well as far as speed of entry, compared with a web app, however it certainly could have been better, and it had the usual quirks that all Access tools tend to have. It allowed looking up an individual's name, so you could check to see if the volunteer was already in the system, allowing you to simply update their record instead of entering a new record for them. Unfortunately, it was common to end up with different records for Bob Smith, Robert Smith, Becky Smith, and Bob and Becky Smith.
Also, often you're entering data from hand-written logs, and sometimes the name is too illegible but the phone number or address is clearer; if you can search on those fields sometimes you can put them together with their record.
Data comes in from a variety of sources. We had a lot of data that appeared to come from excel sheets or other databases. For Access, we entered this data by hand, but I think ideally it should be easy to export a copy of the data into a comma-separated-value format and load it into the tool. Voter registration data can also be obtained from the state on a periodic basis, and should be able to sync up to the database (so you can check and correct registration changes, address/phone changes, etc.) Importing and exporting masses of the data to and from the tool is critical for intercommunications and for growing the database.
It was common for volunteers to have conflicting events or situations that would prevent them from helping out. For example:
These rather complex preferences must be reduced down to a set of easily entered and easily managed status fields to associate with the record. Sometimes it's enough to simply know they won't be available for the particular event you're calling about. In other situations, such as for key volunteers, you may want tighter tracking.
The most important output from a volunteer management system is a list of volunteers worth contacting. With this list, the user can contact and recruit people to help at a given event.
Where a Volunteer Management System surpasses a plain old spreadsheet or mailing list is its filtration capability, that enables narrowing a large list into a smaller, more manageable list. Ideally, these will be the people most likely to want to come help, with the most likely chance of being available, and with the right skills for the job.
An obvious question is if volunteer database software already exists? A bunch can be found on SourceForge; most are incomplete or haven't published source code. Of those that have, most are too specific to their areas of focus (search and rescue, dog adoption, etc.) to be of much use:
Of those, h4hsf-vol looks to be the closest to suit our needs. It's a PHP/SQL application. The project that created it is defunct, though, so we're on our own to carry it forward. We'll probably end up completely rewriting it anyway, so it's likely for the best.