Just as for-profit businesses track information about customers,
mission-based organizations (nonprofits, non-governmental organizations or
NGOs, public sector organizations, civil society organizations, etc.) must
track information about people too: volunteers, clients, potential
supporters, current donors, potential donors, students, ticket-buyers,
event attendees, etc.
The following database-related advice is especially designed for the unique needs of small mission-based organizations. Staff at these organizations have to stretch existing resources a long way, and may not have the resources to hire a full-time database manager or even a short-term consultant, let alone purchase specialized database software or send employees to computer training.
Not everything in the following tip sheet will be appropriate for your database; field names vary, as does the information you want to track about customers and clients. Accompanying each "what to do" part is a "why" part that I hope will help you tailor these suggestions to your database.
This advice comes from the many years I've spent creating and/or managing databases that track people and their activities, be it what tickets they buy, how much they've contributed to an organization in time or money, or if they've received the latest brochure. This advice is further enhanced by continued suggestions from nonprofit mailing list and soc.org.nonprofit newsgroup participants.
Inputting names into a customer database is not enough to keep database
information up-to-date; database managers should also set a regular
maintenance schedule, to make sure addresses are accurate, there are no
duplicate records on the database, etc.
These suggestions for regular duties to keep a customer database "clean" are certainly not everything that needs to be done; just basic guidelines to get you started -- and, I hope, get you thinking about other things you can do. Note that field names vary from database to database; also, be sure to check out the companion tip sheet to this one, Customer Database Principles.
Who do you track on your database? Is it your clients? Potential
customers? Program participants? Donors? Board Members? Volunteers?
Students?
And what is your target area? Is it people in your city? Your county? A
multi-county area? The entire state? People working in a particular
profession?
Before you start making changes to a database structure or the way information is obtained, make sure you can answer the above questions -- and make sure that other core staff members agree with your answers! Aside from the fact that you don't want to waste time tracking information that no one will use and that will take up valuable space on your computer, database managers should remember that the information they track serves different staff members with different needs.
This tip sheets identifies the following fields as the "core fields". You will probably have a lot of information about an individual record on your database (a theatre, for instance, would have ticket sales information and donation information about each person on the database). But the core fields are the ones that you need to generate mailing lists or "to call" lists:
Getting the above correct may mean printing out a report and asking another staff member to go over the information; for instance, the Executive Director or her/his assistant review the Board of Directors information and forward any changes / additions / deletions to you.
The Board of Directors and special committees at your organization are usually your VIPs -- the most important people you call or to whom you mail literature. Complete and correct information about these people makes your organization look efficient and conscientious; incorrect information can offend a big supporter.
Taking too much time to get rid of duplicates on a database can lead to a lot of confusion when you are trying to look up information about an individual. De-duping once a month will make it easier for you to determine which record to keep and which to discard.
Removing Someone from the Database
In most cases, you should never remove someone from your database, even if
that person requests it, unless it's a duplicate record; instead, create a
category that notes people who do not want to be contacted. Why? What if
that person is removed, and later, a board member asks if that person, who
is a friend, is on the database. You say no, and you put the person back
on -- and get an angry call later from that person asking why you
contacted him/her when he/she specifically asked you not to.
Another example -- a key supporter leaves the company where you were sending his or her information, and the company won't give you forwarding information. You remove the person from the database, instead of flagging them not to receive mail until the correct address is found. A board member then could ask if that person is on the database, and you would say no, and the board member would wonder what kind of database manager you are anyway, not having such an important person on the database. If you flag the person instead, your answer would be "Yes, but that person recently left Acme Systems and hasn't received information from us since last month. I don't have a forwarding address. Do you have information?"
However, you should regularly remove duplicate records from your database, as well as people who have moved outside of your targeted area, are deceased, or have had a bad address in your system for a year or more.
The soc.org.nonprofit newsgroup/Nonprofit
email community's FAQs (frequently asked questions and their answers) has
more information about Purging Mailing Lists
These tip sheets may also help you:
my home page
To know when I have developed a new
resource related to the above subjects, found a great
resource by someone else, published
a
new blog,
uploaded a new
video,
or to when & where I'm training or presenting, use any
of the following social media apps to follow me on any of
these social media platforms:
Disclaimer: No guarantee of accuracy or suitability is made by
the poster/distributor of the materials on this web site.
This material is provided as is, with no expressed or implied
warranty or liability.
See my web site's privacy policy.
Permission is granted to copy, present and/or distribute a limited amount of material from my web site without charge if the information is kept intact and without alteration, and is credited to:
Otherwise, please contact me for permission to reprint, present or distribute these materials (for instance, in a class or book or online event for which you intend to charge).
The art work and material on this site was created and is copyrighted 1996-2024