The best demo wins most database decisions. That’s how organizations end up paying for software built for someone else.
A demo is a performance. The vendor shows the features that look good on a big screen, with clean sample data, run by someone who uses the system every day. Your reality is a part-time gift processor, ten years of inconsistent records, and a board that wants one number by Friday. The system that looks best in the conference room is not always the one your staff can live with.
I don’t recommend specific products here, and I don’t list prices. Both change too often to be useful in a guide meant to last. What doesn’t change is the method. Here it is, in five steps, with a scorecard at the end.
Step 1: Write requirements before you see a demo
Before you call a single vendor, gather the people who will use the system and write down what it needs to do. Not what would be nice. What you do every week, every month, and every year.
Sort each item into one of three columns:
Must have. You can’t operate without it. Recording gifts with fund, campaign, appeal, and source. Producing acknowledgment letters with the right tax language. Tracking pledges and payments separately. Exporting all of your data, whenever you want, in a standard format.
Should have. It would save real time. Online giving forms that post gifts directly into donor records. Household records. Event registration. Moves management for your major donor prospects.
Could skip. Pleasant, not necessary. Built-in peer-to-peer fundraising, if you’ve never run a peer-to-peer campaign. Advanced wealth screening, if no one on staff will use it.
Then add a short list of your realities: how many records you have, how many people will log in, how many gifts you process in a typical year and in your busiest month, and which other systems it has to talk to (your accounting software, your email platform, and for schools, your student information system).
This list does two things. It keeps you from being dazzled, and it gives every vendor the same test.
Step 2: Ask vendors the questions they don’t volunteer
Send your requirements ahead of the demo and ask each vendor to show your must-haves using your scenarios, not theirs. Then ask these questions, and write down the answers:
About your data
- Can we export every record and every field, including gift history and notes, at any time, without paying a fee?
- If we leave, what format will our data come in, and how long do we have to get it?
- Where is our data stored, who can see it, and how do you handle a security breach?
- If you process card payments, do you meet the PCI Data Security Standard?
About the people who use it
- How long does it take a new staff member to learn to enter a gift and run an acknowledgment?
- What training is included, and what costs extra?
- When we call for support, who answers, how fast, and is that included in our price?
- Are your online giving forms accessible to people who use screen readers? Do they meet the Web Content Accessibility Guidelines?
About the contract
- What is the price at our current size, and what happens to it when we add records or users?
- How much notice do you give before a price increase, and is there a cap?
- How long is the contract, and what does it cost to leave early?
- Can we talk to three organizations of our size that have used the system for at least two years?
Call those references. Ask them what they wish they’d known before signing.
Step 3: Count the real cost
The subscription fee is the number on the proposal. It is rarely the biggest cost.
Use this worksheet to estimate the first three years, because year one is always the most expensive:
| Cost | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Subscription or license | |||
| Payment processing fees | |||
| Add-on modules | |||
| Implementation and setup | |||
| Data migration | |||
| Training | |||
| Staff time during migration (hours × loaded hourly cost) | |||
| Staff time for ongoing data entry and reports | |||
| Outside help (consultant or freelancer) | |||
| Total |
Staff time is the line organizations skip, and it is often the largest. Plan for several weeks in which the people moving your data are also doing their regular jobs, and for a stretch afterward when everything takes longer because the system is new. A cheaper system that takes your gift processor twice as long every week is not cheaper.
Step 4: Plan the migration before you sign
Migration is where database projects go wrong. Plan it before you commit.
Clean first, move second. Merge duplicates and retire dead records before you migrate, not after. Moving a mess into new software just gives you a more expensive mess.
Decide what history to bring. Bring all gift history if you can. For notes and old event records, decide what you’ll use and archive the rest in an export you keep.
Map every field. Write down where each field in your old system goes in the new one. Where there’s no match, decide on purpose.
Run a test migration. Move a sample, then check it against the old system. Pick twenty donors you know well and compare their records line by line: total giving, first gift date, last gift date, address, and household.
Run both systems briefly. Keep the old one available, read-only, for a few months so you can check numbers and settle disputes.
Pick a quiet time. Avoid your busiest giving season and the end of your fiscal year.
Step 5: Score every option the same way
After demos and reference calls, have each person on your selection team fill out this scorecard alone, then compare. Weights add up to 100. Adjust them to fit your organization, but decide the weights before the first demo, so no one tilts the math toward a favorite later.
| Criterion | Weight | Score (1–5) | Weighted score |
|---|---|---|---|
| Meets every must-have requirement | 25 | ||
| Ease of use for the people who enter data daily | 15 | ||
| Reporting your board and finance office need | 15 | ||
| Three-year total cost, including staff time | 15 | ||
| Data ownership and export | 10 | ||
| Integration with accounting, email, and other systems | 10 | ||
| Support, training, and reference checks | 10 | ||
| Total | 100 |
Multiply each score by its weight, divide by five, and add. A system that fails a must-have is out, whatever its total.
Then ask one last question of the team: which system will we still be using correctly in three years, after the person who chose it has moved on? Sometimes the score and that answer differ. When they do, have the conversation before you sign.
The short version
- Write requirements before you watch demos.
- Make vendors show your scenarios.
- Get the export and exit terms in writing.
- Count staff time as part of the price.
- Clean before you migrate, and test the migration.
- Score every option on the same sheet, with weights decided in advance.
A database is a long relationship. Choose it the way you’d want a donor to choose you: with clear eyes, good questions, and a plan for the years after the first yes.
If you’d like help writing requirements, running the selection, or planning the migration, that’s part of our CRM and Metrics work.
– Mary-Ellen
Sources
- PCI Data Security Standard (PCI Security Standards Council)
- WCAG 2 Overview (W3C Web Accessibility Initiative)
Featured photo: Photo by Fiona Murray-deGraaff on Unsplash.
