The donor relationships your database cannot store

A fundraising manager builds the list for the end-of-year appeal and two names sit four rows apart. Margaret Chen and Robert Chen, same suburb, different email addresses, both giving steadily since 2019. They are married. Nobody looks that up, because the person who has run the program for six years knows it, and has known it since the two of them stood at the back of a room after a member event and asked what the organisation actually needed. The appeal goes out to both, addressed separately, asking each for $500. Neither the letter nor the database has any idea it has asked one household twice.

Who a donor is connected to is a fundraising fact of the same order as what they gave and when. Most donor databases have nowhere to put it, so it lives in one person's head and leaves when they do.

The notes field, and the day that fundraiser leaves

Plenty of teams do write it down. The notes field on the donor record carries "married to Robert", "introduced by the Pattersons", "chairs the board at the arts centre", and in most Australian programs that is the whole system. It does real work, too: a fundraiser reading the record before a call gets the context they need, which is more than a lot of programs manage.

What a note will not do is appear on the other record. Robert's page says nothing about Margaret unless somebody typed it there as well, and somebody rarely did. A note also cannot be filtered or counted, so no one can ask how many donors in the major-gift portfolio are connected to a current board member, or which lapsed donors came in through someone who is still giving.

More than 22,000 registered charities were entirely volunteer-run in the 2023 reporting period, around 43% of all Australian charities, on the ACNC's own figures. In an organisation of that shape there is no fundraising team to spread the donor knowledge across. It sits with the volunteer who has run the appeal since 2017, and when they step back the giving history stays in the database while the map around it goes with them. Six months later their replacement runs the same appeal, to the same list, and asks the Chens for two separate gifts.

The duplicates queue is where most relationships come from

The usual fix is framed as a data-entry problem: buy a system with a relationships table, then persuade busy people to fill it in. That approach has a poor record, because relationship data is the first thing to fall off a form that already has eleven other fields on it.

A more useful question is when a fundraiser already knows the answer and is already looking at both records at once, and that moment is the duplicates queue.

Duplicate detection flags pairs of records that look like the same person: same surname, same address, similar email. A decent share of what it flags turns out to be a married couple at one address, a parent and an adult child, or a business owner and the company that gives alongside them. The fundraiser opens the pair, reads both, decides they are two different people and clicks Not Duplicate. In most systems that click throws the finding away.

Together offers to record the relationship at that point instead. The second donor is already filled in, so the only thing left is choosing the two roles, and every card in the Not Duplicates tab carries the same button, which makes a backlog somebody cleared last year workable too. Establishing that two people are connected is the expensive part, and by the time that button appears it has already been done. It is a different proposition to a relationships tab that waits for someone to think of it.

Ten types, and the one relationship a pair can hold

Together starts every organisation with ten relationship types: Parent, Child, Sibling, Spouse, Partner, Friend, Colleague, Employer, Employee and Relative. They are deliberately non-gendered, so an organisation that wants Mother and Son creates those itself by typing the label into the role field. Together then asks for the reverse label, because it needs to know what the relationship is called from the other side. An Employer has an Employee. A Neighbour has a Neighbour.

One relationship is one record, read from both ends. Record that Margaret is Robert's Spouse and Robert's own page shows Margaret as his, without anyone entering it twice. The Relationships tab carries a count, so a fundraiser can see whether a donor has any without opening it, and both records pick up an entry on their activity timeline.

Some of this is deliberately narrow. A pair of donors holds one relationship, so two people who are both siblings and business partners get the tie that matters for fundraising and the rest goes in the description field. A type cannot be renamed once it exists, which makes the reverse label worth a second's thought at the point of creation. Relationships are part of the Grow plan, and the Free plan shows an upgrade prompt where the list would be.

Together leaves this to a person. It will not read a shared surname or address and decide that two donors are a couple. Somebody has to say so. Guessing wrong about whether two people are married is a worse failure than an empty tab, and it is the kind of guess that surfaces in a letter.

What changes about the next ask

RFM scoring and the donor scores built on it read a donor as a column of their own transactions. That is genuinely useful, and it has a blind spot with a definite shape: it cannot see anything that happened between two people. A donor who gives $200 a year and introduced the organisation to someone who gives $20,000 scores as a $200 donor.

Most of the difference shows up in smaller, more frequent moments than that example suggests. The end-of-year appeal asks the Chens once, at a figure that makes sense against what the household gives together. A major-gift approach goes through the board member who made the introduction rather than cold from the office. Recorded connections also give a segment that changes what a fundraiser does something to work with beyond giving history: everyone connected to a current board member, or every donor who arrived through an introduction and has never been thanked for it.

None of this earns much in a program running an untargeted mass appeal to 40,000 names. It pays in the portfolio, where somebody is planning individual approaches, and it pays most in the small organisation where one person holds all the context and no succession plan covers what is in their head. That is the same accounting as the rest of the cost of running fundraising on tools that have not moved in fifteen years.

The cheapest place to start is a queue that already exists. Most organisations have a pile of flagged duplicates somebody cleared months ago and never went back to, and every pair in it that turned out to be two real people is a connection the organisation established once and then discarded. Working back through that list is an afternoon's work, and it is the only part of this that does not depend on anybody remembering to write something down.