A Fundraiser’s Guide to Getting Real Answers About Integrations
Ask a fundraising leader what they want from a new donor platform and you’ll get a good list. A giving page that converts. Forms that don’t feel like forms. Peer-to-peer fundraising that supporters actually enjoy. Reporting they can trust. Ask which systems the platform needs to connect with, and the conversation usually slows down.
I’ve sat in a lot of these conversations, and I’m convinced it’s one of the most expensive blind spots in nonprofit tech decisions. Not because anyone is careless, but because integration is the one part of the purchase you can’t see in a demo.
Why integration matters more than it looks
A supporter doesn’t know or care that you have a platform and a CRM. They know they gave, and they expect the rest to follow: a receipt that arrives quickly, a thank you that uses the right name, and an appeal list that doesn’t ask them for money again a week after they gave. When two systems aren’t properly connected, those are the first things to go wrong, and the supporter is the first one who notices.
Your team feels it too, just more slowly. Most nonprofit teams are small, and the person who ends up covering the gap is usually the same person who is already stretched. It starts as a quick export on a Monday. Then it becomes a spreadsheet that only one person understands. Then it becomes “just fix it in Excel before the board report.” None of that shows up in the budget, but all of it comes out of the time your team could have spent with donors.
That’s why timing matters so much. The best moment to talk about integration is earlier than most people expect, when you’re writing your requirements and shortlisting, before you’ve fallen for a front end and before anyone has signed anything. Once a contract is in place and an implementation schedule is set, every integration question turns into a change request. The second-best moment is just before go live, when you can still test with real-world scenarios. The worst moment is after launch, when gifts begin flowing through the system and something doesn’t work as expected.
Where integration conversations go wrong
Three common assumptions can lead fundraisers astray when it comes to discussing integration:
“It integrates with our CRM” tells you very little. Two vendors can both say yes when one syncs in real time in both directions and the other drops a file overnight. Both are real integrations. They are very different experiences.
“Integration is an IT problem” is the second one. The people who feel the consequences are in fundraising and finance, so they need a voice in the conversation.
And “we’ll sort it out during implementation” is the third. By then the scope is fixed, the timeline is fixed, and the important decisions have already been made without you.
Five questions to ask (and how to spot a good answer)
In my experience, the buyers who got the best outcomes weren’t the most technical people in the room. They asked plain questions, and they kept asking until the answer was specific. Here are the five I’d want to hear from every fundraiser:
What data moves?
Most people ask whether two systems are connected. This question is better because it makes the vendor name the data: gifts, donor details, recurring plans, refunds, consent, notes. A strong answer is a clear list, with direction (“gifts go from us to your CRM, donor updates come back”).
A red flag is something vague like “everything” or “all the important stuff.”
When does it move?
This is the real-time versus batch question, without needing the jargon. A strong answer gives you a time: “within a minute,” or “every hour,” or “overnight at 2am.” It also explains what that means for you, like when a gift shows up for the person staffing your phone line.
A red flag is “it syncs regularly” with no number attached.
What creates or updates a record?
This is where duplicates come from. A strong answer explains how the platform decides whether a donor already exists (email, name and address, a constituent ID) and what it does when it isn’t sure.
A red flag is “it just creates a new record,” or silence on matching altogether.
How are campaigns, funds, and appeals mapped?
This is the one that protects your reporting. A strong answer shows you the mapping, in plain terms, and explains who maintains it when you launch a new appeal next year.
A red flag is hearing that attribution “can be handled in a report later,” because that usually means someone will be doing it by hand.
What happens when something goes wrong?
Every integration encounters issues at some point, so the more useful question is what happens next. A strong answer covers:
- Alerts: who gets notified
- Retries: what happens automatically
- Reconciliation: how you confirm that the data matches across systems
A red flag would be a response like “that doesn’t really happen,” — the one answer you can be sure isn’t true.
Who should be part of this conversation?
The person who asks the above questions matters nearly as much as the questions themselves. Integration conversations are strongest when multiple perspectives are represented, because each team hears something different.
| Who | What they should be listening for |
| Head of fundraising or donor relations | Whether the donor experience holds up: receipts, thank yous, no duplicate asks, and whether gifts show up fast enough for the team to act on them. |
| CRM or database administrator | How records are matched, how duplicates are prevented, and what the vendor needs from the CRM side (access, fields, a test environment). |
| Finance | Whether the totals reconcile, how refunds and chargebacks are handled, and whether the audit trail is sufficient. |
| Marketing or communications | Whether consent, communication preferences, and campaign attribution remain intact. |
| IT or security | Where data is stored in transit, who has access, how files are transferred, and what activity is logged. |
| Executive sponsor | Who owns the integration after launch and how continuity is maintained if key staff leave |
Setting demo expectations
Most demos describe integration instead of showing it. A slide with two logos and an arrow between them proves nothing. If you’re not technical, the best thing you can do is ask to see it in action.
What to ask to see live
Ask the vendor to make a test gift and then show you where it landed. Specifically:
- A one-off gift, followed by the matching record in the CRM, with the donor, amount, date, fund, campaign, and appeal all visible.
- A change to a donor’s details made in one system, and where (or whether) it shows up in the other.
- A recurring gift being set up and then updated, such as a changed amount or a cancelled plan.
- A returning donor, so you can see whether they are matched to the existing record or given a new one.
- A failed payment or a refund, and what each system shows afterwards.
It’s reasonable to expect a test environment with sample data, and it’s reasonable for a batch sync to take a few minutes or hours rather than seconds, as long as the vendor tells you that up front. It’s not reasonable to be told “we can’t show that” for everyday scenarios.
If a vendor can’t demonstrate a basic gift moving successfully through the process, you’ve learned something important.
How to check attribution without being technical
You don’t need to understand the technical architecture to test whether it works. Try this:
- Ask the vendor to make three test gifts, each to a different appeal, fund, and campaign.
- Write down what you expect to see in your CRM for each one before they show you.
- Compare. If what you wrote down matches what you see, attribution survived.
- Ask for the mapping in a one-page, plain-language document, and ask who updates it when you add a new appeal.
If the mapping only exists in someone’s head, treat that as a warning sign.
Key terms to know
Understanding a handful of common terms will make all of this easier to follow during a demo:
- Sync direction: one-way (data goes from A to B) or two-way (changes in either place update the other).
- Real-time vs. batch: whether gifts move as they happen or on a schedule.
- Field mapping: which field in the platform lines up with which field in your CRM.
- System of record: the system you treat as the source of truth when the two disagree.
- Matching, or deduplication: how the platform decides that a donor already exists.
- API vs. file transfer: a live connection between systems versus a CSV file sent over (often by SFTP).
- Sandbox: a safe test environment where you can try things without touching real donor data.
- Reconciliation: the check that confirms totals in both systems agree.
- Error queue: where failed records wait so they can be seen and fixed instead of disappearing.
When it works, nobody notices
One Australian charity I’ve spoken with had a reporting need that their CRM couldn’t handle natively. Someone, years ago, created a workaround: export the data, merge it in a separate desktop tool, and rebuild the report by hand every time. It worked. Nobody wrote it down, it was just “how the report gets done.”
It came to light when the team started looking at a new platform and someone asked a simple question: where does the data go when it leaves the CRM, and who can see it? The answer was a shared folder full of donor names and giving history, and a process that depended on one person who knew how it worked. Nothing had gone wrong. But no one had ever asked what moves, where it moves to, and who is responsible for it.
That’s the pattern I see most often. The risk isn’t usually a dramatic failure. It’s a workaround that gradually became infrastructure.
Everything above is really about protecting the experience you’re building for your supporters. When integration is working well, a donor gives, gets a receipt, gets thanked by name, and never hears from you with the wrong ask. They never think about your systems, and that’s exactly the point.
Making sure it stays that way takes a little ongoing attention:
- Give a small test gift yourself every so often and follow it all the way through.
- Assign one person to own the integration, and one backup owner.
- Ask for a regular reconciliation so you find mismatches before your auditors do.
- Make sure alerts go to a person who can review and act on them.
- Re-test whenever you change a form, launch a new appeal, or alter fields in your CRM.
If you’re evaluating a new platform, don’t leave integration questions until the end. Ask the five questions above during your first demo. You’ll learn as much from the specificity of the answers as you will from the feature list itself.
