Donor Engine · 01
Inside a supporter record
Amounts and dates are the easy part. What usually goes missing is why someone gave, what you promised them, and what they will not fund.
Who this person is to your organisation, in the language your team already uses.
Every rupee, with the context that explains it, not just the amount and the date.
The half of the relationship that most donor databases never record.
What you are allowed to send, on which channel, recorded at the point of consent.
The part that usually lives in one person's memory or one person's inbox.
Worked example
This is the shape of a record that has been kept properly: a supporter who gave, volunteered, nearly left, and came back further in than before.
Arrives through a general appeal, designated to the education fund. Attribution recorded against the field visit that prompted it, not just the appeal that carried it.
Same record, second relationship type. Skills and availability captured once, so shift matching can start immediately.
Monthly giving replaces the one-off gift. Engagement score rises on frequency and on volunteer hours logged in the same period.
Flagged as a payment failure, not a lapse. The follow-up is an administrative fix, and the score is held rather than dropped.
Score falls across three consecutive reads. The record shows the last field visit was never followed by the outcome note that was promised.
The suggested action is honoured. Reply logged on the record, volunteer shift claimed the following month, standing instruction resumed at a higher amount.
The point of the example
Nothing in that sequence needed clever technology. It needed a record that noticed a failed mandate was not a lapse, and remembered a promise made after a field visit eleven months earlier. That is mostly a data-structure problem, which is why we start here rather than with the scoring.
Practical detail
Which is the real test of a supporter database, and the one most of them fail.
