Charities

There is no single word for the people you deal with

Commercial CRM software is built on a simple idea: there are customers, and you sell to them. A charity has donors, beneficiaries, volunteers, trustees, members, funders and partners, and the relationships between those categories and the organisation are completely different in kind. A donor gives you money. A beneficiary receives something. A volunteer gives time. Treating all seven as Contacts with a tag is where most of the trouble starts.

It gets harder, because the same person is frequently several of them. The volunteer who sets up a monthly gift. The beneficiary who, three years later, becomes the most effective fundraiser you have. The trustee who is also a member and occasionally a supplier. A system that forces one label per person will be worked around, and the workaround is duplicate records with different addresses.

Consonas holds relationship types you name, and a person can carry more than one. The history is one history, the consent is one consent, and the address is in one place, which is the boring benefit that saves the most time.

Two populations that must not be in the same list

The distinction between the people you help and the people who fund you is the most important boundary in a charity's data, and it is the one that generic software has no concept of at all.

A fundraising volunteer needs the donor database. They must not have the safeguarding notes. Someone running a service needs the beneficiary records. They have no reason to see major donor cultivation. In a system with a single permission level per user, the only way to achieve that is a second system, which is how charities end up with a spreadsheet that is genuinely more sensitive than the CRM.

Record sensitivity in Consonas is a grant held separately from the role. That sentence is the whole design. Somebody's job title determines their role. Whether they see sensitive records is a second, deliberate decision, made by a person, and revocable without dismantling anything else. Search respects it, reports respect it, export respects it and the portal respects it, each checked separately.

Consent is a legal position, not a preference

Every organisation should handle consent properly. Charities have a sharper reason than most: the sector has been through public failures on exactly this, the regulator's expectations are specific, and the reputational cost of getting it wrong falls on the cause rather than on a brand.

The failure mode is almost always the same and it is structural rather than careless. Consent is recorded in the mailing tool. The database records something else. The list for the appeal is built from the database. Somebody who withdrew last year receives it, complains, and is entirely right to.

Here, consent is a fact on the person with a date, a channel and a source, and every send checks it again for that individual at the moment of sending rather than at the moment the list was built. There is one answer to whether you may contact someone, it lives with the person, and the sending obeys it.

The free plan, with the limits raised

Every allowance in Consonas is a value held against your organisation rather than a constant in our code, which means we can raise any of them for a single organisation without a release and without you paying anything. For a registered charity we say yes to that almost automatically.

Write to us from the address that owns the organisation, say what the charity does and which allowance is in your way, and we will deal with it. We would rather have small charities using this properly than have a discount percentage on a page.

What we will never charge anyone for

The audit trail. Consent records. Subject access tooling. Two factor sign in. A complete export. Those are obligations rather than features, and putting them on a paid plan means the organisations least able to afford them are the ones running without them. In this sector that is not a commercial decision, it is a safeguarding one.

What we are not, so you can plan around it

Consonas does not process donations, does not calculate or submit Gift Aid, does not run a direct debit mandate and does not reconcile a bank account. It is not a finance system and it is not becoming one. It records that a donation happened so the relationship history is complete, and reads from the systems that handle money properly instead of competing with them.

If what you need is a fundraising database with payment processing built in, that is a different product and you should buy one. We would rather say that here than at the end of a trial.

Separate donors and beneficiaries before anything else

These are two populations who must not mix, and the arrangement that keeps them apart has to exist before there is anything in the system. Sensitivity is decided separately from ownership here, which is what makes one system workable instead of two.

Write down in a sentence who may read a beneficiary record. Then configure that, then import.

Record consent properly on the donor side

Fundraising consent is the most scrutinised consent there is, and a column marked yes is not a consent record. Consent here is a fact with a date, a source and a channel.

Where you have the provenance, import it. Where you do not, knowing that now is considerably better than discovering it after a campaign.

Model volunteers as their own relationship type

A volunteer is not a donor who gives time and not a beneficiary. They need their own type, their own connections and frequently their own sensitivity treatment, because a volunteer who is also a beneficiary is common and needs handling deliberately.

Put the recurring dates in

Grant reporting deadlines, funder review dates, renewal of a regular gift, the annual return. In most charities these live in one person's calendar, and that person is the one who cannot go on leave in March.

Then leave it a month before building any segments

A month of ordinary use tells you what your actual donor categories are, which is almost never the ones a planning session produces.

The trust gives the money, and a named person forms a view of you

Hold the foundation as the organisation and the grants officer as a person connected to it with a period. That sounds fussy until the officer moves. When they do, the connection ends with a date and a new one begins somewhere else, and the fact that the person who liked your last application now reads applications at a different foundation is the single most useful piece of fundraising intelligence a small charity will get in a year.

Charities lose it constantly, because the officer was typed into a field on the trust record and overwritten by their successor. The history of who was there, and what they said on the telephone in February, is worth more than the field.

Trustees, who are usually in your database twice already

Trustee is a relationship type and a term of office, which means a connection with a start and an end instead of a label. The same person is very often also a donor, often a member, and occasionally a supplier or connected to one. That last case is not gossip, it is the related party question your examiner asks every year, and it is far easier to answer from connections that were recorded as they happened than from memory in September.

Terms of office ending are dates, and a board that discovers in a meeting that two terms expired in the spring is a board that will spend that meeting on governance rather than on the charity.

The agency that refers people to you is two records, not one

On the service side, most beneficiaries arrive from somewhere: a council team, a surgery, a housing association, a school, a court, another charity. There is an organisation, and inside it there is a named worker who actually picks up the telephone, and those are different relationships with different lifespans.

The care needed here is specific to this trade. The partnership with the referring agency belongs on the organisation and is ordinary information. The fact that a particular person was referred by that agency belongs on the beneficiary record, and it is sensitive, because in many services the referrer's identity discloses the reason. Sensitivity is a grant held separately from the role for exactly this kind of split, and reporting respects it for each person rather than presenting one total to everybody, so the person who manages the partnership is not quietly told who came through it.

The corporate partner, where one badge covers three relationships

A company that makes you its charity of the year is a funder. Someone inside it championed you and is a relationship of their own. And a number of its employees will fundraise, whose details you may hold under different circumstances and often under different consent. One logo, three relationship types, and most charities record the logo.

The consequence is predictable. The champion changes job, the partnership is not renewed, and no one saw it coming because the relationship was filed under the company. Held properly, the champion leaving is a visible event and their new employer is an opportunity rather than a loss.

The examiner or auditor, who should never be surprised

At the year end someone asks about restricted funds, when income should be recognised, and whether any trustee is connected to a supplier. The money side of those answers comes from your finance system, which is where it belongs and where it is staying.

What comes from here is the relationship side: which funder gave what and on what terms, which obligations attach, who is connected to whom, and a record of changes that nobody can edit afterwards. Producing that in an afternoon rather than a fortnight is most of what makes an examination cheap.

Carers, parents and advocates, who are not the beneficiary

The person you help is frequently not the person who telephones you. Who may speak on somebody's behalf, and what may be said to them, is a fact about a relationship rather than a courtesy, and in some services getting it wrong is the most serious mistake available to a member of staff.

That is two people connected to each other with a role, and what has been agreed recorded against the record it concerns. In most charities it lives in one worker's head and is discovered, badly, on a day that worker is not in.

The grant maker, which is this whole page in a mirror

A foundation gives money away. Applications arrive rather than go out, they are assessed against published criteria, a panel decides, payments run on a schedule and reports come back in. Relationships and a pipeline with your own stages cover the front of that and nothing of the assessment, the scoring or the payment schedule.

If giving money away is the business rather than a thing you also do, buy a product built for it. This is one of the two we would rather not send away, and saying so at the start of a trial is better manners than saying it at the end.

The charity whose real problem is casework

An advice service, a hospice, a refuge, a service delivered under a statutory contract. What those need is structured assessment, outcome measurement, risk rating and returns with defined fields, and records of that character belong in a system built for them rather than in a relationship system with custom fields bolted to it.

Consonas will hold that a person exists, who they are connected to, which records are sensitive and who may read them. It will not hold an assessment framework, and a charity whose main difficulty is casework should buy for the casework and decide about the fundraising side afterwards. That is the second one we would rather not send away.

The charity whose actual pain is collecting money

No card processing, no mandates, no reconciliation, no Gift Aid claim and no submission to HMRC. If what hurts is regular gifts failing, or a donate button that loses people, or a claim that takes a fortnight to assemble, then the useful purchase is a giving platform or a better finance package, and a relationship system will not touch the pain at all.

Come back to this when the difficulty is that no one knows who these people are, which is a different complaint and the one this is for.

The federation whose branches each want their own data

Each customer organisation gets a database of its own. For a national body whose branches largely run themselves that is a real question rather than a detail: separate organisations mean separate data, separate sign in and separate everything, which is exactly right when the branches are independent charities and exactly wrong when head office wants one supporter list.

The reason to decide before you create anything is that the arrangement is made at creation. If you are in that shape, describe it to us first and let us tell you honestly whether it fits, because it is not a question that gets easier once there is data in several places.

The charity with forty donors and a spreadsheet that has not failed

The test is not how many donors you have, it is whether anything was forgotten this year that cost you. If no deadline slipped, no one was contacted who had asked not to be, no beneficiary record was seen by somebody who should not have seen it, and the person who keeps the spreadsheet can go away for a fortnight without anything stopping, the spreadsheet is winning and should be left alone.

The three things that change that answer are a second member of staff who needs the data, a funder who starts asking questions about records, and the moment the consent position stops being knowable from memory. Any one of those is a reason. Being told a charity ought to have a CRM is not.

Where the mechanisms behind all this are described

Consent at the moment of sending is set out on marketing and automation, the sensitivity grant on permissions and the audit trail, and the quarterly numbers a board asks for on reporting. A charity with a subscription base as well as donors should read membership organisations beside this page, and one running courses or accredited training will find the cohort calendar on education and training.