Contact Management

 

Keeping track of your organization’s growing network of contacts can be a daunting task, but the better you keep this information organized, the more effectively you’ll be able to utilize it. There are many different categories of groups and individuals of whom you may keep track: members, email-list subscribers, donors, volunteers, allies, opposition, guest speakers, and vendors, to name a few. The list is extensive, and only becomes more complicated as your organization’s work progresses.

Many novice activists keep track of their contacts in simple spreadsheets. On the other end of the spectrum, large activist organizations utilize powerful CRM (Constituent [or Customer] Relationship Management) applications that not only store all sorts of information about their contacts, but allow that information to be shared throughout the organization. Focus on finding a solution somewhere within that broad spectrum that will meet your  organization’s present, specific needs; remember, you can always upgrade later.

 

 

Spreadsheets Versus Databases

The first step in implementing a contact management solution is to choose between two types of applications: spreadsheets and databases, both of which can be used for contact management. In the early stages of developing and maintaining a contact list, most activists utilize simple spreadsheet software. Although it is just as easy to enter data into database applications, most people are not familiar with them – or at least not with their contact management features. Furthermore, there’s just something enticing about being able to see the contents of other records in the file as one enters data into a table. Most of the more advanced application types default to a different sort of interface for entering data, although there’s usually a way to do so through a table-style interface as well.

Let’s take a quick look at how each of these application types function.

A spreadsheet is a two-dimensional table, normally featuring a set of value descriptions across the X axis, and rows of value sets corresponding to those descriptions underneath. A column in such a spreadsheet consists of the value description – the column name - at the top, followed by a vertical series of cells containing values described by the column name – such as a series of email address in a column named “Email Address”. A row in such a spreadsheet consists of a horizontal series of cells containing a set of values that all relate to one another – such as a particular person’s name and contact information – which includes their email address.

 

 

 A typical contacts spreadsheet

 

A database of the type used in the applications described here – that is, a relational database – consists of sets of tables, each one much like a spreadsheet. The database equivalent of a “column name” is a field.

 

The tables in a relational database have one or more fields in common with one another, referred to as key fields, which are used to connect a record from one table with one or more related records in a different table.

 

 

 This relational database contains the same information as the above spreadsheet. The “Organization” field is used as a key to connect related records in the two tables.

 

If you choose to build a contacts spreadsheet, it’s important to do so in a way that makes it easy to convert the information and upgrade to a more powerful application as your needs evolve. The most important factor influencing one’s success or failure in this endeavor is a basic understanding of how  spreadsheets work in relation to database-driven applications.

 

 

Building Flexible Spreadsheets

 

Spreadsheet applications understand data in terms of what value is contained within each cell on the twodimensional coordinate system created by its columns and rows – like cell D32, located at the intersection of column D and row 32. Naturally, a spreadsheet user gets to see all of the data (or as much of it as will fit on the screen) at once, and understands it visually. Information in spreadsheets is primarily retrieved visually by the user - by locating the appropriate column, row, or cell - as opposed to through any automated process. As a result, spreadsheets are usually organized in ways that make more sense to the user than they do to the computer, making it slightly tricky to manipulate or export this information.

Here’s an example. Let’s say you have a contact, Joe Smith. You have two email addresses for him. In your spreadsheet, you probably went to the “Email Address” column in the row containing Joe’s record, and entered both of them, perhaps separated by a comma, like this: “joe@smith.com, joesmith@freepalestine.org”. It makes perfect sense to you when you look at it in the spreadsheet. But what happens when you import that data into a database-driven application? The program looks at the value in the “Email Address” field in Joe’s record, and thinks that Joe’s email address is “joe@smith.com, joesmith@freepalestine.org”. If you activate the function that allows you to send an email to the address in the cell (usually by clicking on it), the program will try to use all of the information in the cell. Not only do you have a useless “Email Address” field, but the field in the database you’re using now (which didn’t exist in your spreadsheet) called “Alternate Email Address” is just sitting empty. Now you need to go through all the records in your database and cut and paste every alternate email address you have for someone into the appropriate field. You’ve got hundreds of contacts! Ugh! If you had stored those two pieces of information in separate columns in the spreadsheet – creating one an additional column - you wouldn’t have this problem now.

 

Note: you don't really need to do all this work manually if you've made that mistake. You can usually fix this, for the most part, using your spreadsheet application's "text to columns" function.

 

 

The wrong way: Joe Smith’s record in the spreadsheet

 

 

The wrong way: Joe Smith’s record after being imported into the database

 

 

The right way: Joe Smith’s record into the spreadsheet, modified to include an extra column for “Alternate Email Address”

 

 

The right way: Joe Smith’s record from the modified spreadsheet, imported into the database

 

Here’s another example: you’ve got three different contacts at the same organization. In your spreadsheet, you’ve got three rows of records with “Law Students for Human Rights” in the “Organization” column, followed by the contact information for one of those three people. Let’s say you import that into a database-driven application, which uses different tables to keep track of individuals and organizations. You perform the importing in the most efficient way possible, which places the information on individual contacts into one table, and the organization data from the same records into another table. Now you’ve got three duplicate records for the same organization, in addition to the records of your three individual contacts. All you wanted was one record for the organization, with your three contacts linked to it. If you had entered all of your contacts into the same row in the spreadsheet (a series of columns for Contact 1 and their contact information, then a series for Contact 2, etcetera), you wouldn’t have to go back and fix things now.

 

 

The wrong way: three contacts for the same organization entered into the spreadsheet as three separate records

 

 

The wrong way: the result of importing the same three contacts into the database

 

 

The right way: the first few columns of a single record created for one organization with multiple contacts. (Information for Contact 2 and Contact 3 is found in columns G through N, not shown.)

 

 

The right way: the Organizations table of the database after the contacts are imported from the modified spreadsheet

 

The more information you store about the individuals and organizations in your contacts spreadsheet, the more columns you’ll need to add in order to keep the information well-organized and easy to import into another application (not to mention much easier to sort in the original spreadsheet application). This will likely become extremely annoying as once the columns begin to add up and you’re forced to scroll fifty columns to the right in order to see the entire record. When this happens, it’s a surefire sign that it’s time to move on to a database-driven application.

 

 

Spreadsheet Applications

 

If you opt to utilize a spreadsheet in the initial stages of developing your list of contacts, your options will include the following:

 

Microsoft Excel

(Estimated Price: $50 - $200)
http://office.microsoft.com/en-us/FX010858001033.aspx
Like Word, Excel is a part of Microsoft Office Suite. As such, it’s installed on most public computers you’re like to encounter and is available for both Windows and Macintosh. For a comparison of Microsoft Office Suite and its chief open-source rival, OpenOffice.org, see:
www.techsoup.org/learningcenter/software/page4382.cfm

 

OpenOffice Calc (Freeware)

www.openoffice.org/product2/calc.html
OpenOffice.org is a free, open-source, cross-platform productivity suite that includes a set of applications similar to those offered in Microsoft Office. Calc is the suite’s spreadsheet utility, which is similar to Microsoft Excel both in feel and in functionality. When managing very large spreadsheets (those containing 20,000 rows or 100 columns) it runs much slower than Excel, but this isn’t a huge concern, as you’re unlikely to be working with that amount of data. You won’t find OpenOffice suite on most public computers, but it’s free to download if you care to use it. For a comparison of OpenOffice.org and Microsoft Office, see this link: www.techsoup.org/learningcenter/software/page4382.cfm

 

 

Personal Information Managers

One alternative to a spreadsheet application as a starting point for contact management is a personal information manager (PIM). Such applications utilize a relatively simple relational database to keep track of contacts, maintain calendars and to-do lists, and send and receive email. PIM databases vary substantially in complexity, but they are generally designed to simplify the import and export of data. Consequently, it is much easier to upgrade from a PIM to a more advanced database application than it is to upgrade from other spreadsheet applications. PIMs also tend to be compatible with handheld devices such as Blackberry, Palm, and Pocket PC products (see the section on Personal Digital Assistants), giving one the ability to transfer contact and other information back and forth between the application and the device. The distinctions between PIMs and CRM applications are discussed in more detail in the discussion of CRM software below, but they essentially boil down to multi-user support, the level of detail of stored information, and the ability to be integrated into every aspect of an organization’s interactions its customers or constituents, regardless of the medium used for the actual communication. Major signs that it’s time to upgrade from a PIM would be:

 

1. The application needs to be accessed by more users than it supports
2. You need to track information a greater degree of detail than your software allows
3. Your interactions with your contacts are becoming more and more complicated
4. You want to analyze these interactions to understand your contacts better

 

Microsoft Outlook

(Estimated Price: $0 - $200)
www.microsoft.com/outlook
Outlook is the PIM component of Microsoft Office Suite, and a scaled-down version is distributed for free as Outlook Express. It includes an email component, calendar, contact and task management features, and a journal. Prior to the release of the 2003 version, Outlook was infamous for having significant security holes which, along with its popularity, made it a choice target for malicious hackers. The current release, however, is much more secure than its predecessors, and additional security add-ons provide encryption and other useful features. With the 2003 release, Microsoft began offering an optional Outlook upgrade called Business Contact Manager, which dramatically expands Outlook’s contact management capabilities through the use of a relational database, enabling it to track far more information about each contact, and effectively transforming it into a low-end CRM application (see “CRM applications” later in this section).

 

Mozilla Thunderbird

(Freeware)
www.mozilla.com/thunderbird
Thunderbird is an open-source, cross-platform email application with limited Personal Information Management features. Though not quite as powerful as Microsoft Outlook, it’s a free download, and is bolstered by a growing library of add-ons that expand its functionality, including a number of important features not found in Outlook. Thunderbird allows you to synchronize your information with various PDA (see the section on “Personal Digital Assistants”) devices. (Palm devices are supported, but this feature has not yet been perfected. Support for Pocket PC has yet to be implemented, but workarounds make it possible to synchronize data indirectly.) Thunderbird supports an encryption add-on called Enigmail which allows users to implement powerful encryption technologies such as GPG (see the Encryption section of this module), making it a valuable tool for secure communications.

 

 

Generic Database Applications

 

Generic database applications can be used to create contact management databases tailor-made to one’s own specific needs. Due to the time investment involved, this is practical only when one’s needs are not met by an existing product. However, contact management templates and add-ons are available for a number of these applications. These are usually closer to PIMs than to CRM applications in terms of their level of functionality, but technically, a skilled programmer (or team of programmers) should be able to use such an application to develop a database that rivals even the best CRM programs available. Whether this would be worth the investment, however, is debatable.

Microsoft Access

(Estimated Price: $100-$200)
www.microsoft.com/access
MS Access is a relational database management application, part of Microsoft Office Suite. Its basic functions are relatively easy to use, but the application is powerful enough that skilled programmers can use it to develop complex databases and even standalone database-driven applications of their own. Due to its popularity, there are a great many training and support resources available for Access users.

 

 

OpenOffice Base

(Freeware)
www.openoffice.org/product/base.html
Base is an open-source, cross-platform relational database management application, and has been a component of the OpenOffice.org suite since version 2.0. According to its developers, the version of Base that was released with OpenOffice 2.0 (Base version 1.8.0) is only 76% complete, with many more features still to come in later releases. As a result, the program is currently very limited compared to Microsoft Access; the big advantage is that it’s open-source and therefore free. For a comparison of Microsoft Office Suite and OpenOffice.org, see
http://www.techsoup.org/learningcenter/software/page4382.cfm.

 

 

CRM Applications

 

“CRM” is variously interpreted as “Customer” Relationship Management and “Constituent” Relationship Management, depending on the target market of the application (commercial versus nonprofit or public sector). Essentially, a CRM application is a PIM on steroids. The distinction between the two categories traditionally hinges on two primary factors; one is that PIMs are intended for use by individuals, and CRM applications are designed for (often very large) organizations. The other is that CRM products track many more pieces of information about customers/constituents than do PIMs. However, the recent introduction of high-end PIMs has caused the old lines to become slightly blurred; these new PIMs promise (limited) multi-user capabilities and the ability to track more types of information that were once the exclusive domain of CRM applications.

Today, the primary distinctions separating PIMs from CRMs are really  scalability, integration, and the ability to analyze data. PIMs may be adding multi-user functionality, but not on anything approaching the scale of CRM applications, which often support thousands of users. The second factor is integration: CRM products are intended to be integrated into every aspect of an organization’s interactions with and understandings of its  customers/constituents, including sales, marketing, and customer service; not even the most advanced PIMs offer that level of functionality. Finally, CRM products (sometimes through the use of an add-on module) allow the data collected to be analyzed to develop a better understanding of customers or constituents; one example would be determining the most common subjects of incoming communications.

A more detailed discussion of CRM applications can be found in this article from Wikipedia: http://en.wikipedia.org/wiki/Customer_Relationship_Management