The relationship problem
Bloomsbury Football Foundation runs youth programmes across London, and like every charity it lives or dies by its donors and sponsors. Keeping those relationships warm is a full-time job that nobody has the time to do full-time. Birthdays get missed. Donation anniversaries pass without acknowledgement. When a donor goes quiet for six months, nobody notices until the annual report. The foundation needed a system that would do the noticing for them — and that framing, not a feature list, is where I started.
A stewardship notebook, not a deal pipeline
The tool is designed around one idea: no relationship should go cold by accident. Each donor gets a record with their history, preferences, personal milestones, and every interaction logged. The system watches for signals — upcoming birthdays, donation anniversaries, periods of inactivity — and recommends a specific action: a handwritten letter, a phone call, an event invitation, a piece of branded merchandise. The recommendations are personalised. A donor who gave at a gala gets a different follow-up cadence than one who set up a monthly standing order. AI drafts the outreach copy, but a human always reviews and sends.
Three views, prototyped before any code
The interface has three views I built and tested as prototypes first. The Roster is a triage list: every donor sorted by urgency, with colour signals for who needs attention now. The Dossier is a deep profile for a single donor, showing enrichment data, past touches, and campaign recommendations side by side. The Action Board flips the model around — instead of browsing donors, you browse campaigns (birthday letters this week, re-engagement calls this month) and batch your outreach. The data layer sits on Supabase with a pipeline that handles audit, extraction, validation, and tiering of donor records.
Why not Salesforce
Every off-the-shelf CRM I evaluated was built for sales teams closing deals, and the mental model is wrong for charity stewardship. Donors are not leads in a funnel. They are people who chose to support something, and the job is to keep that relationship genuine. A sales CRM optimises for conversion. This system optimises for warmth. That distinction runs through every design decision — the language in the interface, the way recommendations are framed, what gets measured.
Where it stands
This is written up from the project as it stands in its design phase: three interactive prototypes built and tested, a visual system locked to Bloomsbury's brand, and a defined data model. Application code follows the Network Mapper, because discovery has to come before management — you cannot steward candidates you have not yet found. Adapted from the project write-up.