Basic Customer Database Principles

Summary:

Suggestions from a long-term contributor to the FAQ.

Answer:

Jayne Cravens, jcravens@coyotecom.com, started a
list of database tips in response to questions to the soc.org.nonprofit
newsgroup and USNonprofit-l mailing list in 1994. This is the November 1996
version of that tip sheet:

This tip sheet deals mainly with customer/client/donor/volunteer databases,
either on computerized or on index cards, used by not-for-profit
organizations. Not everything in this tip sheet will be appropriate for
your database; field names vary, as does the information you want to track
about different people.

Good People and Good Systems = Good Database
A practical, simple, adaptable database comes not from a computer program,
but from people who understand the importance of gathering information and
of thinking proactively, and who are dedicated to keeping the information
up-to-date. The first step in putting together a database is to find out
what each staff member wants to be able to do with the database (a phone
list of everyone who has called to volunteer for a particular project, a
report that identifies people who donated money to your organization in the
last quarter, a list of all city and county officials, etc.). Based on how
they want to use the database, you will create and add fields to track
information about people in your database.

Limit the Number of Databases You Create
The more databases you create, the harder it is to cross-reference
information. Under this system, if your board member moves, you have to
change his or her information on several seperate databases. It's not time
or cost effective. You should have only one for tracking people/customers.
Your accounting staff may need their own for vendors, bills and payroll;
your program manager may need one to track projects and their progress;
etc. But anything that relates to your membership, customers, volunteers,
donors, etc. should be kept in one, centralized database.

Capture Everyone
The purpose of your database is to GROW. 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, because those people are the
best audience to approach about volunteering, donating, attending an event,
etc., because they've voiced an interest in your organization already!
Develop a system that everyone 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.

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
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 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 database, everyone on staff should
have at least limited access to it (looking up phone numbers, generating
and printing reports, etc.).

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

• first name
  
• last name
  
• salutation
  
• name tag first name
  
• mailing address
  
• day phone
  
• evening phone
  
• fax phone
  
• e-mail address
  
• ethnicity
  
• date entered into system
  
• date information was last updated
  
• affiliation/agency/company
  
• referred by
  
• contribution(s) (include date given)
  
• participation category/ies (events attended/project involvement/etc.)
  
• do not send mail category
  
  (for former members/customers who do not want to receive materials)
  
  *if nametags 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.
  

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
  

Basic Overview of Databases at http://www.coyotecom.com/flat.html
includes tips on what to look for in database software, should you be
looking to buy such.

Frequently Update
Always give many opportunities for the database to be updated - staff
members should review 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.

Design It In House
If at all possible, have your computerized database designed in-house by a
staff member who is going to be using it a lot. If you use an outside
consultant or agency to design it, you 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. If you must use an outside consultant, make sure that
person builds the database on a simple software package and trains you or a
staff member so that you can alter the database design and structure as you
need.

There are many simple computer database programs, and even word processing
and spread sheet programs now come with database functions. Designing a
database in-house can be as simple as taking a couple of classes and
looking at other organizations' information tracking systems. Even if you
decide to use an outside consultant, its a good idea to look at other
organization's information tracking systems, to get an idea of what
qualities you do or don't want.

Security
A computerized database should have security passwords 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.

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 targetted area, are
deceased, or have had a bad address in your system for a year or more.

See Database Maintenance Tips, at http://www.coyotecom.com/db_main.htm
l for a lot more information on how to maintain your database.

Free Help With Your Database
In addition to tutorials and printed support material that came with your
database software package, companies often provide free online bulletin
boards and automated fax libraries where users can get more specific or
updated answers for database questions. Call the particular company to find
out if they have such a service, and use it to search for answers BEFORE
you call technical support. There are also Internet discussion groups, called Usenet newsgroups,
centered around discussing the use of particular types of database
packages. Participants in the groups are software users just like you,
although many are often advanced users. Here is a list of known database
newsgroups as of November 1996:

comp.databases

comp.databases.adabas

comp.databases.gupta

comp.databases.ibm-db2

comp.databases.informix

comp.databases.ingres

comp.databases.ms-access

comp.databases.ms-sqlserver

comp.databases.object

comp.databases.olap

comp.databases.oracle

comp.databases.oracle.marketplace

comp.databases.oracle.misc

comp.databases.oracle.server

comp.databases.oracle.tools

comp.databases.paradox

comp.databases.pick

comp.databases.progress

comp.databases.rdb

comp.databases.sybase

comp.databases.theory

comp.databases.visual-dbase

comp.databases.xbase.fox

comp.databases.xbase.misc

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

Permission is granted to copy and/or distribute this tip sheet without
charge for non-commercial or educational purposes if the information is
kept intact and without alteration, and is credited to:

Jayne Cravens

Coyote Communications
Services for Not-For-Profit Organizations and Public Sector Agencies

jcravens@coyotecom.com

http://www.coyotecom.com

Jayne Cravens wrote to: usnonprofit-l@rain.org on 17 Sep
1996 on the subject of Volunteer Database Software

FYI, I have four tip sheets re: databases on my Web site (
http://www.webcom.com/jac/), that
use learnings both from my own
experiences, and things posted to soc.org.nonprofit:

*Overview of Databases, which includes:

-Definitions of Database Terms

-The Difference Between Flat and Relational Databases

-Shopping for Database Software

-How Relational Databases Are Joined

*Database Principles

*Customer Database Regular Maintenance

*Importing Information Into a Database