Customer Database Principles

Version: June 19, 2012

A free resource for nonprofit organizations, NGOs, civil society organizations,
charities, schools, public sector agencies & other mission-based agencies
by Jayne Cravens
via coyotecommunications.com & coyoteboard.com (same web site)

Customer Database Principles

Note: this web page content is no longer updated.

"Customer Database Principles" was the very first tip sheet I ever posted to the Internet, back in 1994 (to a USENET newsgroup), and it's still as popular now as it ever was (yes, I've revised it more than a few times).

Just as for-profit businesses gather data about customers and potential customers, to build a population of buyers for their products, mission-based organizations (nonprofits, non-governmental organizations or NGOs, civil society organizations, public sector agencies, schools, etc.) must track information about people too -- current donors, volunteers, clients, potential donors and volunteers, ticket-buyers, event attendees, students, etc. -- to build ongoing support their programs and services. Capturing this information is crucial for an organization to show the impact its programs, to measure how people are perceiving the organization, and to show the gaps regarding where and how the organization's messages are being communicated. Every department of your organization relies on databases to fulfill their goals as well.

The following basic database advice is designed especially for the unique needs of small mission-based organizations with very limited staffing and funds. Employees and volunteers of 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.

This advice also comes from the author's point of view that the best designers of these databases are the users -- the people who input and manipulate the data as part of their jobs. That means volunteer coordinators and development directors and office assistants should direct the design, rather than senior managers and IT professionals. That doesn't mean your receptionist has to learn programming, but it does mean that your database designer is going to be talking to him and her and letting that person make design decisions, recognizing that this person is the person that will use it the most, for instance.

Not everything in the following suggestions will be appropriate for your database; field names vary, as does the information you want to track about customers and clients.

This advice comes from the many years the owner of Coyote Communications has 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, ways they have volunteered, or if they've received the latest brochure. This advice is further enhanced by continued suggestions posted to various online discussion groups.

If you are new to database management, review the Basics of People Databases, which includes

Database Terms
"Flat" and Relational Databases
How Databases Are Joined
Shopping for Database Software

Good People and Good Systems = Good Database
The value of a database comes not from a computer program, but from the information that is tracked. The most important component in a good database system is people who understand the importance of gathering information and of thinking proactively, and who are dedicated to keeping information up-to-date.

Please note that regular data entry and maintenance may significantly change your present organizational procedures, depending on who enters the data, what the scale of operation is, and training requirements. It is of the utmost importance to support the person(s) who maintain the database (i.e. the people who input the data). This should be a priority job, not an after thought or a "when-you-have-time" task, and not something to think about late in a database adoption process. Without full and initial support of this person or persons who will primarily input and manage the data, your database, no matter how well designed or how highly thought of it is by IT experts, will fail to meet your organization's needs.

Who's In Charge
If you have under ten (10) staff people, only one staff person should have the responsibility of inputting, changing or deleting information to the central database. This cuts down on duplicate records, information conflicts, etc. If more than one person is inputting information, you need to create a category that will track who inputted what. However, EVERYONE should contribute information for the central database; all staff members have a responsibility to provide important names, address changes, etc. for the database.

Universal Access
While one person may be in charge of the central database, everyone on the core staff should have at least limited access to it (looking up phone numbers, generating and printing reports, etc.).

Capture Everyone
Your central database should GROW. That's part of its purpose! If you are a small organization, then everyone/anyone who calls, comes to a meeting or event, asks for information, is sent material about your company, etc., should be put on the database. Those people are the best audience to approach about volunteering, donating, attending an event, etc., because they've already voiced an interest in your organization.

In addition, you should be tracking in what projects/programs people are interested, how they are hearing about your organization, how many hours they volunteer each month, if they received your latest newsletter, etc. This doesn't take an elaborate system -- it takes staff members who understand when and how to capture information on the phone, via a sign-in sheet, etc.

Develop systems that everyone can and will use to capture this information, and make sure this information is inputted in a timely manner -- a good rule is that new information is inputted into your database no more than 48 hours after it was received by the organization.

(also see Keeping Volunteer Information Up-to-Date for specific tips on how to ensure volunteer information is inputted regularly and kept up-to-date)

Tracking Information
No organization measures its success by the number of people who are in its database(s). The value of a database also doesn't come from a computer program. The value of a database comes from the quality of the information that is tracked. The most important component in a good database system is people who understand the importance of gathering quality information and of thinking proactively, and who are dedicated to (and fully supported and empowered in) keeping the information up-to-date.

Develop your systems of tracking "people" information based on how your staff wants to use information about clients, volunteers, donors and potential audiences. The first step in deciding WHAT information you need to track is to find out what each staff member wants to be able to do with the database. Fund-raising staff may want a list of volunteers each quarter who have also made financial contributions; the executive director may want to occasionally see what city and county officials have attended your organization's events; the marketing staff may want to know to know weekly who or what referred people who call your organization. If you don't know what staff members need out of your information-tracking systems, ASK.

Deciding what information needs to be tracked will help you decide what fields to create to track information about people in your database(s).

Limit the Number of Databases You Create
Few nonprofit organizations have people who fit into only one category: volunteers can also be donors, clients/customers can also be volunteers, media representatives may also attend events, etc. The more independent databases you create, the harder it is to cross-reference information, and the more likely it is that you will have "competing" information -- for instance, updating the address on one database for a donor but not updating the information on another database where the person is also listed. For instance, if a board member moves, you would have to change his or her information on several separate databases. It's not time or cost-effective.

You should either have only ONE central database system for tracking all people and organizations involved with your organization (or that could potentially be involved), OR, all of your databases need to be able to "talk" to each other.

Your accounting staff may need their own for vendors, bills and payroll; your program manager may need one to track projects and their progress; your marketing staff may have a press-tracking system they want all to themselves; and various staff will have their own personal databases (electronic address books) to track certain contacts. But anything that relates to your membership, customers, volunteers, donors, potential supporters (including city & county officials), event attendees, etc. should be kept in one, centralized database system (you can have different databases for each of these, but the information should be joined; read more about what this means in The Basics of People Databases.

The Information Needed Most
What information do you need from people and organizations now, and what information might you need for the future? Only you can decide what categories of information your organization needs -- just remember that a good database serves all of your organization's departments: program, communications, resource development, volunteer management, etc.

Here are some basic, general suggestions for information categories for a people database:

first name
last name
salutation (Mr., Mrs., Rev., Honorable, etc.)
name tag first name
(if name tags are generated from this database, this is an important field -- someone who wants their mail addressed to "Stephen" may want to be verbally addressed as "Steve", for instance; or, someone from another country may want to be addressed by what people in the "West" would consider the last name)
postal mailing address fields
(including one for city, one for state, one for zip; maybe one for country or county, depending on your organization's focus and outreach)
day phone
evening phone
fax phone
e-mail address
ethnicity (for statistical tracking purposes only)
birth year (for statistical tracking purposes only)
date entered into system
(this should be an automated field)
date information was last updated
(this should be an automated field)
affiliation/agency/company
type of affiliation/agency/company
(do you need to be able to pull a list off of your database of city officials? newspaper reporters? program managers at arts organizations in your area? corporate CEOs?)
participation category/ies (event attendee/project involvement/donor/volunteer/etc.)
originally referred by
(heard an ad? by a board member? saw your Executive Director present at the Rotary Club?)
do not send mail/ do not contact category
(for former members/customers who do not want to receive materials; see below as to why this category is important, rather than removing someone from your database)
dates of financial pledges made for each year
dates those pledges were received
total financial amount an individual has given for your organization
skills a person has offered your organization as a volunteer
hours an individual has volunteered with your company or for specific programs
program interests of everyone in the database, in case they want to donate time or money to a specific area of your organization
times an individual is available for volunteering with your company
expenses for volunteers and employees (mileage, meals, etc.)

Again, the above are just general, basic categories. Every organization, department and program is different. For instance, some organizations may need the date of birth of participants and potential participants, to show what age groups they are reaching.

Also, other information will need to be tracked about volunteers and clients as well, and this may not be in the "records" database. For instance, you will want data that shows volunteer impact beyond just number of hours contributed; number of hours does NOT show program impact! You need feedback from surveys of volunteers, staff and clients, testimonials from all three of these groups, and other qualitative data!

Be Able to Sort Information
A good computerized database should allow you to sort and view information in a variety of ways. For instance, you might want to generate:

An alphabetical list of education representatives who attended your Fall fund raiser
Personalized letters to donors who have contributed more than $100
A sheet of mailing labels for a particular city or county, sorted by zip code
A phone list of people interested in a specific activity by your organization
A list of volunteers available to be involved with your organization on a specific day or time

Frequently Update
Always give many opportunities for the database to be updated - staff members should review portions of it periodically to make sure information is correct, a well-connected community leader could review a portion of it to make sure everyone who should be on it is, etc.

Keep Design Ownership In-house
The staff member who is going to use the database most (input information, run reports for other staff, etc.) should be involved in the design of your computerized database, or the selections of specialized database your agency might purchase. If you use an outside consultant or agency to design a database, you can create a dependency that can sometimes cut into productivity; imagine having to make an appointment every time you need to add a new field of information to the database, and you get the idea. Having staff directly involved will prevent this over-dependency.

If you must use an outside consultant, make sure that person builds the database on a simple software package and trains at least two staff members in how to alter the database design and structure as needed, so that you are not completely reliant on the consultant; or, again, make sure the staff person(s) who will use the database are directly involved in the purchase of a specialized package.

There are many simple computer database programs that don't require you to upgrade your computer to install, and that can be easily designed to track donors, volunteers, ticket-buyers, clients, staff, projects, etc. Designing a database in-house can be as simple as taking a couple of classes or looking at other organizations' information tracking systems. And there are LOTS of online discussion groups and free information sites for users of the most popular database programs, customer relationship management (CRM), content management systems (CMS) out there.

Even if you decide to use an outside consultant, it is a good idea to look for yourself at other organizations' information tracking systems, to get an idea of what qualities you do or don't want. The same is true if you do have to go with a specialized software package. Coyote Communications has a tip sheet on what to look for when shopping for software that can help you make the right purchase.

Security & Privacy
A computerized database should have security levels for different levels of use (one for inputting information, one for designing screens, one for viewing confidential information, etc.). This ensures confidentiality as needed, and prevents those staff members who don't know how to use the system from making a big, unintentional mistake everyone will regret later.

Also, you need a written policy regarding privacy for those who are in your database. How confidential is this information? Will any of it be shared with other organizations, or published in your annual report? This written policy needs to be communicated to ALL staff at your organization, and communicated to those who provide you their information.

Backup Your Information
If your database is computerized, backup the database at least twice a week. Keep these backup copies in a safe place (some companies buy fireproof safes to store copies; others store the backups at a different location). You should also set criteria for when to destroy (copy over) or reuse these copies.

Removing Someone from the Database
In most cases, you should never remove someone from your database, even if that person requests it; 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.

Success Can Increase Workload
The better the report that a database generates, the more demands you will receive for additional reports. Be prepared for the success of your data tracking and reporting system to lead to more tracking and reporting needs. In fact, staff members who may not understand the value of the database will, upon seeing the kinds of reports it can generate (number of donors that are also volunteers, number of donors in a particular geographic area, and so forth). Keep track of who is asking for what reports, and report on this in your own work progress reports/at staff meetings, so the value of your database (and your own work with such) is further emphasized to all staff.

Think About Interactivity
Don't think of your database as merely a group of people waiting to hear from you. They want to talk back to you -- and maybe to each other. Invite everyone on your database, through your communications with its membership, to subscribe to your email newsletter, subscribe to your blog, subscribe to any RSS feeds you provide, etc. At the very least, you should have an online discussion group at least for all current and previous volunteers.

These tip sheets may also help you:

Keeping Volunteer Information Up-to-Date - no software can input data on its own; how do you ensure volunteer information is inputted regularly and kept up-to-date?

Overview of Databases
- Database Terms
- "Flat" and Relational Databases
- How Databases Are Joined
Customer Database Regular Maintenance
Free Help With Databases & Software
Importing Information Into a Database
Choosing Specialized Software
(label-making software, volunteer management software, project management software, fund raising software, etc.)
To Base and Back Again
This is a series of tutorial articles that follow the creation of a database designed to serve as a birder's log, tracking birding field trips, bird sightings, etc. It's a great tutorial for anyone creating a database (not just regarding birds) using a database program from NeoOffice, OpenOffice, LibreOffice, Microsoft Office, or other similar programs.

Return to Nonprofit Tech & Tech4Good / Tech4Impact Resources

Quick Links

my home page

my consulting services & my workshops & presentations

my credentials & expertise

my research projects

my book: The Last Virtual Volunteering Guidebook

How to Support This Web Site & My Work

contact me or see my schedule

Free Resources: Community Outreach, With & Without Tech

Free Resources: Nonprofit, NGO & other mission-based management resources

Free Resources: Technology Tips for Non-Techies

Free Resources: Web Development, Maintenance, Marketing for non-Web designers

Free Resources: For people & groups that want to volunteer

linking to or from my web site

Coyote Helps Foundation

me on social media (follow me, like me, put me in a circle, subscribe to my newsletter)

support my
work

how to support my work & this web site

Disclaimer: No guarantee of accuracy or suitability is made by the poster/distributor. This material is provided as is, with no expressed or implied warranty.

See this 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:

Jayne Cravens
& Coyote Communications, www.coyotecommunications.com

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).