Can Your CRM Show a Donor Their Well? Most Can’t
Project-level donor attribution is the ability to answer, for any donor, which specific project their gift helped fund — and to prove it. It sounds like table stakes. For most donor CRMs, it isn’t, because they are built to record a gift, not to connect that gift to a physical outcome in the field. Ask a generic system “which well did this donor pay for?” and the honest answer is usually a shrug and a spreadsheet.
For water and WASH organisations, that shrug is expensive. The whole appeal of funding a well is that it is a specific, findable thing in a specific place. A tool that can tell a donor how much they gave, but not what it built, is optimised for the wrong half of the relationship.
The question your database probably can’t answer
Try running it as a query against whatever you use today: show me every donor attached to the Kiruruma well, and what to tell each of them now that it’s complete.
In a donor-first CRM, that request runs into a structural wall. The database knows donors, gifts, campaigns, and appeals. It does not usually know “projects” as real records with a location, a status, and a completion date. So the link a water charity cares about most — this donor funded a share of that well — lives nowhere the system can retrieve. It lives in a campaign name, a tag, a custom field, or a colleague’s memory, and none of those was designed to be queried at the moment a donor asks where their money went.
The gift side is immaculate. Amounts, dates, receipts, soft credits, all clean. The project side is improvised. That asymmetry is the actual problem, and it doesn’t show up in a demo; it shows up eighteen months later when a well is finished and no one can cleanly pull the list of people who paid for it.
Why this is a data-model limitation, not a settings problem

“We built 30 wells” vs. “Here’s your well”
The clearest way to feel the gap is to compare the two updates a water charity can send after a good year.
The first: “Thanks to supporters like you, we built 30 wells this year.” True, warm, and completely interchangeable. Every donor gets the same sentence, and none of them can find themselves in it.
The second: “The well you helped fund in Kiruruma is complete. Here’s where it is, here’s a photo, and here’s who it serves.” Same organisation, same year, but now the donor is looking at a specific thing they can point to.
Only one of those reliably earns a second gift, and the research explains why. In Zeffy’s 2025 Donor Behaviour & Giving Trends Report, drawn from 1,000 U.S. donors, only about 36% said they can easily find out what their gift accomplished — and donors who do understand their impact give again and give more. CCS Fundraising, reported via Neon One in 2026, found 97% of donors named the real or perceived impact of their gift as a major reason they gave. The generic “we built 30 wells” update gestures at impact. The specific “here’s your well” update delivers it, and it can only be produced by a system that knows which donor is attached to which project.
The exemplar here is Charity: water, which built its entire donor experience around exactly this capability: every project published with photos and GPS coordinates, and a customised Impact Report sent to the donor once the project they funded is complete. That isn’t a communications trick layered on top of a normal CRM. It’s the visible output of a data model that treats the project as a real, locatable record.
What project-level attribution actually requires
An organisation doesn’t need field GPS rigs to close this gap. It needs a system whose data model can hold four things at once:
A project as a first-class record, with a name, a location, a cost, and a status that changes over time. A many-to-many link between donors and projects, because real funding is dozens of donors across one well and one donor across several wells. A completion event that can be reported from the project outward to every attached donor, rather than assembled donor by donor. And retrievability, so “everyone connected to this well” is a query, not an archaeology project.
Once those exist, the donor-facing part — the proof, the receipt, the update — becomes generatable rather than heroic. That’s the mechanism behind the companion approach we describe in shared-project receipts for one well, many donors. And it sits alongside the timing problem covered in our pieces on the funding-to-completion gap and the second-gift silence: attribution answers what to say, timing answers when to say it, and a water program needs both.
Generic donor CRM vs. project-aware system
| Generic donor CRM | Project-aware system | |
| Core record | Donor + gift | Donor + gift + project |
| “Which well did this donor fund?” | Manual lookup, if answerable at all | A query |
| Donor-to-project relationship | Improvised in tags/fields | Native, many-to-many |
| Well completion | No trigger; often unreported | Reportable to all attached donors |
| Proof to donor | Generic aggregate update | Specific, project-level |
| Fails when | Volume or staff turnover rises | Scales with the project list |
FAQ
What is project-level donor attribution? It’s the ability to link each donor to the specific project their gift helped fund, and to retrieve that link on demand — so you can prove to a donor which well, borehole, or system they supported, not just how much they gave.
Why can’t a normal donor CRM do this? Because its data model is built around donors and transactions, not projects. A well has a location, a status, and multiple funders, and a donor-first database has no native record for that, so teams improvise with tags, campaigns, or spreadsheets that don’t hold up at scale.
Can’t I just use a campaign or a custom field for each project? For a handful of projects, sometimes. It breaks down because one campaign often funds several wells and one well is funded across several campaigns, and because tags and fields carry no project status or completion, they can’t drive an update when the well is finished.
Is donor-to-project tracking only worthwhile for large organisations? No. It matters most where many concurrent projects make manual cross-referencing impossible, which describes plenty of small and midsize water programs, not just large ones. The smaller the team, the less it can afford to assemble proof by hand.
How is this different from restricted-fund accounting? Restricted-fund coding answers a finance question: is this money tracked to its designated purpose? Attribution answers a donor question: where did my specific gift go? A gift can be correctly fund-coded and still leave the donor with no idea which well they helped build.
Donorfit treats the project as a real record, not a campaign name or a tag, so the link between a donor and the well they funded is something you can query and report on — including when it’s finally complete. If “which donors funded this well?” is currently a question your system can’t answer, that’s the gap it exists to close.

