How to Choose a CRM for Your Nonprofit
Which CRM is best for nonprofits is the wrong first question. It is the question the listicles answer, and most of those articles are written to earn a commission on the click — which is why the same handful of products appears in every one of them, in a different order, each described as the best. None of them has seen your organization.
The right first question is what your organization actually needs a CRM to be responsible for. That sounds like a delay, and it is the opposite: requirements are the only thing that turns a demo from a sales presentation into an evaluation, and they are the reason you will still like the decision in three years. This guide is the method — surfaces first, requirements second, vendors last.
Why small nonprofits keep buying the wrong CRM
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 on your data, with 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.
The outcome is the same in all four cases, and it is the thing organizations eventually call us about: 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 quietly build spreadsheets to work around the system they were told to use, which makes the records worse, which makes the system less trusted.
Start with requirements, not vendors
Requirements are not a feature list. A feature list is written in a vendor's vocabulary; requirements are written in yours. The way to get them is to look at where supporter data is actually created, lost, and duplicated in the organization you already run.
We do this as a survey of mission surfaces — 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.
- 01
Inventory the surfaces
List every place supporter data is created, and for each one note what it captures, where that lands, and whether anything downstream reads it. Observed reality only — what actually happens, not what the process document says should happen. The gap between those two is usually where the story is.
- 02
Follow one real person through
Pick a supporter who has done more than one thing with you: came to an event, then gave, then volunteered. Trace every record they generated across every system. The points where you cannot tell it is the same person are your integration requirements, and you will not find them on any comparison chart.
- 03
Name the system of record
For each kind of data — supporter identity, giving history, program participation, communication consent — decide which single system is authoritative. Most stacks fail here rather than at features: four things are each half-pretending to be the CRM, and none of them is wrong enough on its own to force a fix.
- 04
Write down what it must not do
This matters as much as the requirements themselves. A CRM that also tries to be your email platform, your event tool, your website, and your bookkeeping will be mediocre at several of them and expensive at one. Deciding what deliberately stays outside the CRM is what keeps the decision small enough to make well.
- 05
Derive five to eight non-negotiables
From the four steps above, not from a feature grid. A real requirement reads like: event attendance and giving history must sit on one supporter record without anyone matching them by hand. A fake one reads like: robust reporting. If a requirement could be copied onto another organization without changing a word, it is not yours.
It is worth running the same surfaces past the four CARE questions — how people connect, how their participation advances, how relationships persist between transactions, and how value flows back to sustain the work. A CRM chosen to serve only the last of those will quietly make the first three harder, and that trade tends to become visible about a year after it is locked in.
See the CARE frameworkWhat those five steps produce is an observed map of your surfaces and the data moving between them, which is the thing a CRM decision needs underneath it. It is also, precisely, what a Mission Surface Review produces — so if you run the method yourself, you have done the engagement, and if you do not have the weeks to spare, that is the one to buy rather than a selection consultant who starts at the shortlist.
When you do not need a new CRM at all
A fair share of the time the honest 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 does not close that gap. It relocates it, at considerable cost, into a product nobody on staff has learned yet.
There is a second option that did not used to be practical, and it is worth understanding before you sign anything. 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 — the same identity and the same history across the mail platform, the event tool, the CRM, and the spreadsheet — was an enterprise line item for most of the last two decades. It is not anymore. For a lot of small organizations that now costs less than a migration, requires no retraining because nobody has to learn a new interface, and can be shaped around how the organization actually works instead of around a vendor's assumptions about how nonprofits work.
This is not a claim that custom software is usually the answer. It is one option among several, it was genuinely out of reach at your size until recently, and it belongs on the table next to the migration quote rather than being ruled out before anyone prices it.
Evaluating vendors against your requirements
Once you have requirements, the vendor conversation changes character. You are no longer being shown a product. You are checking a product 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.
- Bloomerang
- Givebutter
- HubSpot
- Little Green Light
- Neon One
- Salesforce Nonprofit Cloud
- Zeffy
Those are the names you will encounter most often, listed alphabetically. We are not ranking them, for two fairly boring reasons.
The first is that we have no vendor relationships, referral agreements, or implementation practice, so we have nothing to gain by pointing at one — and nothing to protect by staying quiet about another. The second is that the ranking would be dishonest even if we wanted to make one. Which of these is right depends entirely on requirements we have not seen. Every one of them is a good answer for some organization and a poor answer for others, and any article that ranks them without asking about your programs, your data, and your capacity is answering a question that cannot be answered in the abstract.
The closest we come to product-specific advice is a caution, and it is about capacity rather than quality. We would almost never recommend Salesforce to a nonprofit that does not have a dedicated technical resource — a staff member, a contractor on retainer, or a genuinely committed volunteer whose job includes owning it.
That is not a criticism of the product. Salesforce is the most capable platform on the list, and that is precisely the issue: it is a platform you build on, not a tool you turn on. The donated licenses that make it free to adopt do not make it free to run, and without someone whose role is to configure and maintain it, it becomes the half-implemented system described in the cost questions below — powerful, free, and quietly in the way of the giving program it was supposed to support.
The cost questions people forget to ask
- How does the price change as our record count grows? Per-record pricing is the most common way an affordable year one becomes an expensive year four without anyone making a new decision.
- How many seats do we actually need, and what does one more cost? Per-seat pricing quietly discourages giving program staff access, which is exactly the access that makes the data worth having.
- What does it cost to get our existing data in, who does that work, and what happens to records that do not map cleanly?
- What happens if we leave? Ask it directly: can we export every field, including custom fields and interaction history, in a usable format, without paying extra for the privilege?
- What is the all-in total for year one including implementation, and what is the total for year three at our expected growth? Compare those two numbers across vendors, not the monthly sticker price.
- What will free actually cost in time? Donated nonprofit licenses — Salesforce's program is the best known — price at zero and bill you in implementation. A free platform your team cannot configure delays the thing you adopted it for: every month it sits half-implemented, donor data stays scattered and the income it was supposed to help diversify stays fragile. When the price is zero, time-to-value is the number to interrogate.
Red flags
The pricing requires a conversation
Custom pricing is not dishonest by itself. The problem is that you cannot compare what you cannot see, and the conversation is structured to happen after you have invested time in the relationship.
Your requirements get answered with a demo
You sent a numbered list. A serious vendor responds to it line by line, including the lines where the answer is no. A vendor who responds by scheduling another walkthrough is managing you, not evaluating fit.
Migration is described as simple, unprompted
Nobody can call your migration simple before looking at how your data is structured. When it is described as included and painless without a single question about your current records, the estimate is marketing rather than scoping.
Nobody will say what the product does not do
Every honest tool has an edge somewhere. A salesperson who cannot name a scenario their product handles badly has either not thought about your organization or has decided not to tell you.
The pressure is attached to a date
End-of-quarter discounts and price increases landing next month are about their sales cycle, not your decision. Good software is still good next quarter, and a vendor comfortable with your timeline is telling you something useful about the support relationship.
Questions we get asked
- What is the best CRM for a small nonprofit?
- There is no universal best, and that is a finding rather than an evasion. The best CRM for a small nonprofit is the one that matches requirements derived from that organization's own surfaces: how supporters actually arrive, what data those touchpoints create, which systems already hold it, and what the team genuinely has capacity to maintain. Two organizations with the same budget and the same headcount routinely need different products, because their programs create different data and their staff have different tolerances for administrative work. Anyone who names a product before asking about your organization is either selling that product or guessing.
- How much does a nonprofit CRM cost?
- The honest range is wide. Free and genuinely low-cost tiers exist and are real options for small organizations; mid-market nonprofit products commonly land somewhere in the low hundreds of dollars per month; enterprise platforms run well past that even with nonprofit pricing. But the subscription is the smaller number and it is not where organizations get hurt. The costs that actually surprise people are data migration, staff time during implementation, training, and pricing that scales with record count — the last of which turns an affordable decision into an expensive one several years later without anybody revisiting it. Free carries its own version of this: a donated license with implementation demands beyond your team's capacity does not save money — it delays the diversified giving income the system was supposed to help you build. Price the third year, not the first.
- Can we just keep using spreadsheets?
- Sometimes, honestly, yes. One organized spreadsheet maintained by a person who knows what is in it will outperform a badly implemented CRM for a surprisingly long time, and moving off it too early is a real and common mistake. It stops being adequate at recognizable points: when more than one person needs to edit it at the same time, when you cannot reliably tell whether two rows are the same human being, when giving history and program participation live in separate files nobody reconciles, when answering who gave last year but not this year takes an afternoon, or when consent and contact preferences are not recorded anywhere you could defend. Those are the failure signs. Until they show up, the spreadsheet is not your problem and replacing it will not fix the thing that is.
- Do we need a consultant to choose a CRM?
- Not always, and we would rather say that plainly than pretend otherwise. The method above is the method; an operations-minded staff member with a few focused weeks can run it. Outside help pays in a narrower set of cases than consultants usually admit: when nobody internally has time to do the surface inventory honestly, when the organization has already attempted this once and stalled, or when internal disagreement means the requirements need to come from someone with no stake in which system wins. That inventory is what a Mission Surface Review produces, and when the decision is imminent and the stack is genuinely tangled, the Technology Strategy engagement goes further and assigns every system a defined role.
The step that produces your CRM requirements
A Mission Surface Review is the inventory in section two, run for you: an observed map of where supporter data is created, lost, and duplicated across your real touchpoints, and the requirements that fall out of it. You can take that into any vendor conversation, or use it to conclude that you do not need one.