How to Choose a CRM for Your Nonprofit

Nearly every difficult CRM situation we are called into was decided in one of four ways, and none of them started by writing down what the organization needed.

It was chosen from a demo. Demos are excellent, because they are built to be. A good sales engineer shows you the three things the product does best, on clean sample data, in an order designed to produce the feeling that this solves everything. You leave impressed having learned almost nothing about how it behaves with your data and your staff in the last week of a campaign.

It was inherited. Someone two directors ago signed the contract, nobody has asked since whether it still fits, and approving the renewal has always been easier than reopening the question.

It came from the board. A board member uses something at work, likes it, and says so. The offer is generous and the guidance is usually poor, because a fifty-person sales team and a four-person nonprofit share almost none of the same requirements.

Or it came from an article that said best.

All four end in the same place, and it is usually why organizations call us. The same supporter exists in three systems with three different histories, and nobody can say which one is right. Reporting turns into an export-and-reconcile exercise. Staff build spreadsheets to work around the system they were told to use, which makes the records worse, which makes the system less trusted.

A feature list is written in a vendor's vocabulary, and requirements are written in yours. You get them by looking at where supporter data is created, lost, and duplicated in the organization you already run.

We do this as a survey of mission surfaces, meaning every place a person can encounter the organization and leave a trace. The website, donation and signup forms, event registrations, the email platform, program intake and records, social channels, and the spreadsheet somebody maintains privately because the real system is too slow to use. For each surface, three questions: what does this create, where does it land, and does anyone ever read it again.

A fair share of the time the finding is that the CRM is adequate and the problem is elsewhere. Four systems are each holding part of the supporter record, none of them agrees with the others, and the pain everybody attributes to the CRM is really the gap between them. Replacing the CRM relocates that gap, at considerable cost, into a product nobody on staff has learned yet.

There is a second option that did not use to be practical. The cost of building small, purpose-built software has fallen a long way. A connector whose entire job is to keep your existing systems in agreement about who a supporter is, so the mail platform, the event tool, the CRM, and the spreadsheet all carry the same identity and the same history, was an enterprise line item for most of the last two decades. It is not anymore. For a lot of small organizations it now costs less than a migration, and nobody has to learn a new interface. It can also be shaped around how the organization works instead of around a vendor's assumptions about how nonprofits work.

None of this makes custom software the usual answer. It belongs on the table next to the migration quote, though, rather than being ruled out before anyone prices it.

Once you have requirements, the vendor conversation changes character. Instead of being shown a product, you are checking one against a list you wrote before you walked in.

Send the requirements ahead of the call and ask each vendor to respond to them directly, in order. Score against your list rather than their demo script, and treat the drift as information. When the demo keeps steering toward features you did not ask about, that is usually where the product is strongest and your requirements are not. Ask to see your own scenario performed on your own messy data, not the sample database where every record is complete.

Those are the names you will encounter most often, listed alphabetically. We are not ranking them, for two fairly boring reasons.

The first is the disclosure at the top of this page. We sell none of them, so we have nothing to gain by pointing at one and nothing to protect by staying quiet about another. The second is that a ranking would be dishonest even if we wanted to make one. Which of these is right depends entirely on requirements we have not seen, and every one of them is a good answer for some organization and a poor answer for others. Any article that ranks them without asking about your programs and your capacity is answering a question that cannot be answered in the abstract.