A CRM is a database that keeps everything you know about a supporter in one place – what they gave, when you last spoke, which events they came to, what they have asked not to receive. For a small charity, the question is rarely which system to buy. It is whether the problem you have is one a database can solve.
A charity can buy one, move its spreadsheets across, and find a year later that the reporting is no better and two people have quietly gone back to their own lists.
If your systems are part of a wider look at how the charity runs, you can book a free clarity call.
What are you actually trying to fix?
Three different problems get described as needing a CRM, and only one of them is a software problem.
The first is a tool problem. Information exists, people record it consistently, and you still cannot get it out in a useful shape. Somebody has to open four files to answer a question a funder asked. That is what a database fixes.
The second is a data problem. The information is there but nobody agreed how to record it, so the same donor appears three times under different spellings and half the entries have no date against them. New software will import that mess and hand it back to you faster.
The third is a time problem. Everyone knows what should be recorded and nobody has the hours. A CRM makes this worse before it makes it better, because setting one up and keeping it current costs more time in the first year, not less.
Work out which you have before looking at a single product. Buying a system to solve the second or third problem is how charities end up blaming the system.
When a spreadsheet is still the right answer
Spreadsheets hold up better than the sector likes to admit.
With a few hundred supporters, one person doing the recording and nothing automated going out, a well-kept spreadsheet answers most questions faster than a database somebody has to learn. It costs nothing, it exports anywhere, and it will still open in ten years.
It stops holding up at recognisable points. When more than two or three people need to update the same information at once. When you cannot tell who changed what, or when. When someone’s contact preferences sit in one file and their giving history in another, so honouring an opt-out depends on remembering to check both. When you start sending anything automated. And when the person who built it leaves.
That opt-out point is where an inconvenience turns into a risk, and it is usually the honest reason to move.
What a small charity needs a database to do
Strip away the feature lists and four things matter.
One record per person, so the same supporter is not three entries. A history you can see at a glance. Contact preferences held in the same place as everything else, so acting on them is not a separate job. And a report you did not have to assemble by hand.
Everything past that is worth paying for only if you will use it. Volunteer rostering, event ticketing, marketing automation, dashboards, supporter scoring – real features, all of them, and all useless to a charity that has not filled in the basics.
One question is worth answering before any of it. What would you do differently if you had the information? A CRM tells you nothing on its own. It returns what somebody typed into it. If you cannot name a decision that would change – who to phone, what to stop posting, which appeal to run again – the system will be an expensive filing cabinet.
There is also a boundary to settle early. Your finance system and your supporter database will both want to hold donation records, and if both do, they will eventually disagree. Decide which one is the authority for what before you buy, not eighteen months in when the totals do not match.
The systems question usually arrives attached to something else: a funder asking for numbers nobody can produce, or a fundraiser leaving and taking what they knew with them. If the database is the symptom rather than the problem, a free 30-minute clarity call is a reasonable place to start.
What migration costs that nobody quotes for
The licence fee is the smallest number in this decision.
Migration is the one people miss. Extracting your records, cleaning them, mapping them to new fields and checking they arrived intact is real work, and it is usually either charged separately or absorbed by your own staff in evenings. A system quoted at a few hundred pounds a year can come with a one-off migration several times that.
Then configuration, because someone has to decide what you record and how it connects. Then training, for everyone who will touch it, and again when they leave. Then the first year, when the system runs alongside the old way because nobody trusts it yet.
Budget for the year, not the subscription.
Questions to ask before you sign
Ask these before you commit. The answers are much harder to get once you have signed.
- How does the system handle someone asking to be removed – does it delete the record or flag it?
- Can we record consent separately for each channel, and see it on the supporter’s record?
- Can we export everything ourselves, without asking you, and in what format?
- What happens to our data if we stop paying?
- Where is it hosted, and who else has access to it?
- Can you put me in touch with two charities of about our size who use this?
- What does this cost in year three, not year one?
The last three matter more than they look. A supplier whose charity customers are all much larger than you will have built for their problems. And a price that is attractive in year one is a different proposition once your record count has grown.
The hosting question connects to something worth stating plainly. Putting supporter information into a single system concentrates it, which raises your data protection responsibilities rather than reducing them. You remain accountable for what a supplier does with data you hand over, so ask where it sits and what happens in a breach. The ICO publishes guidance for charities on this, and it is better read before signing than after.
This article is general information for UK charities and not advice on any specific situation. On data protection and supplier contracts, check the ICO’s guidance and take advice where a contract carries real commitments.
If the supporter database is one of several systems that need sorting, our digital and tech support covers systems selection alongside the rest of the infrastructure.
