Ten Common Mistakes in Selecting Donor Databases (And How to Avoid Them)

You want a donor database that will provide clean data, solid reports, and happy staff, but the software itself is only half the story. How do you choose the right system, and how do you maximize its capabilities? Fundraising technology consultant Robert Weiner walks through 10 common mistakes that get in the way of selecting the right database—and using it properly. 

Picture two nonprofits—the first has a donor database full of bad data. Donors are getting the wrong receipts, or no receipts at all. The organization cannot use the database to plan fundraising strategies or track its effectiveness. The few reports it can get are useless. Staff members complain that no one trained them, and they get no technical support. For obvious reasons, they hate the system.  

The second organization loves its database. The data is clean, donors get timely, accurate mailings, the organization has a good handle on its fundraising activities, and staff get the reports they want. New personnel are trained on the database before they ever log in, and someone on staff helps them resolve any problems and questions that come up.
 
Both nonprofits are using the same software package. How can this be? 
 
Perhaps the first organization has outgrown its old system, which is causing many of the problems it is experiencing—but it’s more likely the organization had the wrong software to begin with, and then made it worse through mismanagement. It made a series of bad decisions and has been struggling with them ever since. 
 
How do you avoid a similar situation? Selecting and managing a donor database is never easy, but if you avoid the mistakes on this list, you can start out on the right foot.
 

1) Letting Techies Make the Decision

 
In the early days of computing, programmers created all the donor databases. Their role was to turn fundraising concepts into software programs, but since most fundraisers did not (and still don’t) want to be involved in the detailed decisions and testing required to design a database, programmers usually drove the project. Although the market for donor databases has changed significantly over the past three decades, techies still make many of the purchasing decisions for their organizations. However, few techies have experience with fundraising, which makes it critical to get input from the people who will actually use the database.
 
You don’t need to include every staff member, but you should get input from all levels of the organization—management, departments, end users—as well as fundraisers from all areas of development (direct mail, grants, online marketing and fundraising, major gifts, corporate relations and planned giving, if you have all of these), and any other staff who may be affected by a new system (for example, administrative and data entry, those who create and run reports, other departments that provide input or use fundraising data). The techies should advise on whether a system will fit into the organization’s technology strategy, and whether it will be supportable in the long term, but they should not make the final decision in a vacuum. 
 

2) Wishful Budgeting

 
Before you go shopping for a database, make sure you know what you can spend. And before you sign a contract, make sure you can afford to pay the bill—now, and in the future. Keep in mind that over a five-year period, software could be as little as one-fifth of your total cost. You might need new computers and printers; network upgrades; help moving your data to the new system; extra end-user training; help setting up the system and developing new reports, processes, policies and interfaces; and perhaps even new staff to manage the system. This effect is magnified as the software price rises—more complex software requires more staff training, stronger policies and better business processes. 
 
You also need to budget for the annual costs, if there are any. Unless you’ve decided to use a free or open source system, you’ll likely pay a monthly or yearly fee. Vendors generally charge an ongoing “rental” fee if you’re using a hosted package, or for a installed system, they generally charge a yearly “maintenance fee” (about 25 percent of the initial purchase price) that allows you to get support and updates.
 
The bottom line: if you can’t afford to train your staff and pay the annual maintenance fee, don’t buy the software.
 

3) Prioritizing Price above Everything Else

 
Price is important. But it’s only one of many factors to consider. Buy the product that meets your top needs, fits your resources and offers the best price. Think of this as a long-term investment in fundraising, donor stewardship and better management. Software that allows you to have more control over your fundraising programs, manage your solicitations, track your results and analyze your effectiveness will pay dividends for many years.
 
Accept a donation (whether of software or services) only if it fits your selection criteria. Feel free to accept input from board members, donors, volunteers or the boss, but in the end, make an educated, strategic decision. And remember that “free” software also has costs (see Idealware’s article, “The True Costs of Free and Low-Cost Software” and the blog post “There Ain't No Such Thing As a Free Software Package.”) 
 

4) Randomly Looking at Demos

 
Yogi Berra is supposed to have said, “You’ve got to be very careful if you don't know where you're going, because you might not get there.” And if you don’t know what you want from your donor database, you might get to the wrong “there.” Randomly viewing software demonstrations is not likely to produce a good result. 
 
Your first step should be to convene a selection team to help you make the decision. Make sure team members understand their role—is it their decision, or are they advising management? Will the decisions be made based on majority-rule or consensus?
 
The team should start by understanding the current system. What works? What doesn’t? What codes and reports do you actually use? Next, develop a list of needs. These can be general, like “ad-hoc report writer,” or specific, like the ability to track a 15-character appeal code or analyze membership upgrades, downgrades and renewals. Don’t forget to consider future needs, especially if major organizational changes are anticipated. Then ask the team to identify the mandatory items on the list—“mandatory” means that if the system cannot provide that one single feature, you will have to reject the database, no matter what else it can do. Everything that is not mandatory goes on the “wish list,” which should be ranked roughly in priority order (for example, A, B, C, or 1 to 5). Consider what worked at your last job only if the needs, budgets, and staffing are similar.
 
Next, identify a pool of possible vendors. You can find some in our Consumers Guide to Low Cost Donor Management Systems and in our article, “A Few Good Donor Management Systems.” You’ll also find links to several other vendor listings at http://www.rlweiner.com/resources.html#donors.
 
In addition, you can ask for suggestions from your professional network or on email forums for nonprofit professionals. Be sure to get references from comparable organizations (for example, type of nonprofit, number of staff, budget size, fundraising volume, number of locations, etc.). There is no point in finding out which database the Red Cross headquarters uses if your organization’s annual budget is $250,000.
 
You might wish—or even be required—to use a Request for Proposals (RFP). If you do, be sure the questions you ask can be answered unambiguously and will help you narrow the vendor pool. Think ahead to how you will use and rate the responses. Keep in mind that not all vendors will respond to an RFP, particularly a lengthy one. 
 
When you are ready to look at software demos, make sure the vendors address your mandatory and top priority requirements. You can help ensure this by providing a list of your requirements, or a script the vendors must follow. Make sure each follows the same process: If you use a script for the demos, they must all follow the same one. If one vendor gets four hours for a demo, the rest should as well. Give each vendor the same information about your needs. If you answer a substantive question for one vendor, give the same information to the others. Follow up on the information that vendors provide by checking references carefully and spending time testing a demo version of the software. 
 

5) Falling in Love with Cool Features

 
As you look at software demos, the vendor is likely to focus in on the areas where the system is strong and try to gloss over the areas in which it’s weak. They may well have a number of nifty features they show specifically because they look very appealing. But think critically about your own needs. How important is it really that you’re able to, say, plot all your donors visually on a map? Create sophisticated charts within the system? Send tweets or mobile texts from within the interface? 
 
If it wasn’t on your requirements list prior to the demo, think very carefully before letting yourself be swayed by a shiny new feature.
 

6) Falling in Love with the Salesperson

 
You are not buying the salesperson—in fact, in most cases you will never hear from the salesperson again once you’ve signed the contract, so don’t worry about hurting feelings. Try to look past who has the best personality, does the best demo or has the nicest outfit and judge the software on its own merits. 
 
However, the strength and support the vendor organization can provide is a critical factor. The right vendor will keep up with changing technologies, provide good training and support and supply usable documentation. Remember, if the vendor disappears you will have to do this all over again. Reference checks will help you assess the vendor’s track record. If the company’s stock is publicly traded, you can find detailed financial information—you can also get some financial information from Dun and Bradstreet. If the company seems risky, you might want to visit their office and see how they run their operation.
 

7) Buying More Than You Need

 
Don’t buy a Ferrari if you only need (or can afford or maintain) a Honda Civic. It’s great to be able to track every detail about every prospect and donor, but will your staff have time to use those features? Plan for the future, but make sure you can use it now. With some systems, you may be able to start small and buy additional modules as needed (although you will have to be prepared to pay for additional training and annual support along with the new modules). One often-overlooked option is improving what you have—it isn’t reasonable to compare a five-year-old version of your current software to the most recent versions of other software.
 

8) Confusing Highly Functional Software with Highly Trained Staff

 
Complex software requires your staff to have more computer knowhow, not less. New software will not solve undertrained staff, poor communication, broken business processes and poor management. Usually, the problems will only get worse. 
 
It’s also important to look at your staffing and procedures as part of the project. Beware of management and “people” problems masquerading as technology problems. For instance, if you are having problems getting accurate reports, are the problems being caused by the database software, sloppy data entry, lack of communication between fundraisers and techies, poor training or bad programming logic in the reports? If it takes two weeks to produce a receipt, does the problem lie with the database or with your business practices?
 

9) Hoping the Database Will Install Itself

 
Although it accounts for eight of the 10 topics in this article, buying software is usually the easiest part of the project. The hard part comes next: the conversion project. Conversions usually have many components: mapping the data in the old database to the new one; cleaning up your current data (manually or through programs); configuring the new interface to match your needs; figuring out what to do with data that does not fit easily into the new database; creating new reports; testing the converted data;  defining system security (who can log in and what can they view, add, change or delete); defining codes; building interfaces to other systems; defining and documenting your procedures; creating a data-entry style guide; and writing training materials.
 
Someone is going to need to oversee that work. This project manager will need to understand your fundraising programs and learn how the software works. She probably has a full time job that may be derailed by this project, and her manager will need to understand this before the project starts. The project manager is also likely to need help from your fundraisers and administrative staff, each of whom have their own jobs to do. Some organizations get through conversions by reassigning staff or hiring temporary staff to support the staff working on the project, but you may also need help from the vendor or a consultant. 
 
If you have a hard deadline (like the end of the fiscal year), you need to make sure everyone knows this. You also need to consider the implications of missing it and have contingency plans in place. 
 
Finally, you should try to build some flexibility into your budget, in case unexpected costs arise. They say that time is money, but the reverse is also true—more money can pay for temporary staff, overtime and more help from the vendor or consultants.
 

10) Leaving the Database to Fend for Itself

 
At long last, your new system is live, your data is clean, all processes and data entry standards are documented, you have a training manual, and all staff members are fully trained! (Well, you can dream.) Like a shiny new car, your shiny new database will get dented and filled with trash if you let it. How do you keep things running smoothly?
 
First, someone should “own” the database and be responsible for quality control. Sometimes called the “data manager” (as opposed to a technical “database administrator”), this person must make sure your data entry procedures are documented and followed, and run periodic audit reports to identify problems. Someone will also need to make sure that staff are trained on new features and procedures, and that new staff are trained before they start entering data. 
 
New systems often change the way work gets done. You will need to make sure that job duties and descriptions still match reality. You might also need to spend time thinking through how data and paperwork move through your organization. 
 
Finally, you will need to budget for ongoing hardware and software upgrades, annual software maintenance fees and ongoing training from the vendor—potentially including attendance at annual users group conferences.
 

Wrapping Up 

 
There are a number of donor management systems on the market. Choosing the right one is critical, but so is remembering that the tool itself is only half the story—the other half lies in understanding what you need, and then following through.
 
Sophisticated fundraising combines a realistic development plan with appropriate staffing and the financial and technical resources you need to achieve that plan. Similarly, selecting a donor database combines clear goals and a realistic budget, a solid selection process, proper attention during the conversion. It also requires good staff training and ongoing support. That approach will allow you to choose the software that will support your organization’s long-term goals.
 
 
Thanks to TechSoup for the financial support of this article. Robert Weiner is an independent consultant specializing in helping fundraisers make informed, strategic decisions about information technology. He has consulted for a wide variety of organizations ranging from volunteer and grassroots organizations to universities and international nonprofits. He is the co-host of TechSoup’s Technology for Fundraising forum and a frequent speaker on donor management systems and best practices in Development Operations. His web site is www.rlweiner.com, and you can contact him at robert at rlweiner.com.

 

 

 

License: 
Copyright © Techsoup, published under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License.