If you work in charity comms and marketing, you’ll know the feeling. Every part of your job lives in a different piece of software, and none of them talk to each other.
Your website is on WordPress. Your newsletter goes out through Mailchimp. Donations come in through Donorfy. You might also have a CRM on Salesforce. Events run through Eventbrite and the shop is on Shopify. Volunteer rotas live in a spreadsheet, and the referral form is a Google Form someone set up in 2019.
Each tool does its own job well enough. But the trouble is what happens between them…
The same person, four times over
Take Sarah. She signed up to your newsletter after a Facebook post. A few months later she bought a ticket for your quiz night, then a tote bag from the shop at Christmas. In January she set up a £10 monthly gift, and she ticked the Gift Aid box.
To Sarah, that’s one relationship: she’s someone who cares about your work and has shown it four different ways.
To your systems, she’s four strangers:
- a subscriber in Mailchimp
- an attendee in Eventbrite
- a customer in Shopify
- a regular donor in Donorfy
Each record has is slightly different – an mistyped phone number or a missing surname. None of them knows the others exist.
Where it goes wrong
This fragmentation isn’t just untidy – it leads to real mistakes that supporters notice.
Donors get asked when they should be thanked. Sarah has just set up a monthly gift, and next week your newsletter tool sends her the emergency appeal asking her to give for the first time. To her it reads as though you weren’t paying attention.
People fall through the gaps. Last year’s quiz night attendees are your warmest audience for this year’s fundraiser, but they sit in Eventbrite and your invitations go out from Mailchimp. Unless someone remembers to export, clean and import the list, they never hear about it.
You can’t see who your most committed supporters are. Someone who gives, volunteers, comes to events and buys from the shop is probably one of your most committed supporters, and possibly a future legacy pledger. Spread across four systems, they look like four casual contacts.
Consent gets lost in transit. Under PECR, marketing consent is given per channel: someone can say yes to email and no to phone. When data moves between systems by CSV, these details are the first to go. A tick box in one tool becomes a blanket “subscribed” in another, or a withdrawal recorded in one place never reaches the others. Since February 2026, charities can also use a soft opt-in for supporters who showed an interest in their work, but only with a record of when and where those details were collected and an opt-out offered every time. That record is hard to keep when the details have passed through three exports!
Gift Aid paperwork gets scattered. Gift Aid declarations need to be kept and matched to the right donations. If a declaration was made on an event booking but the gift came through a separate donations platform, linking the two is down to whoever has time, and HMRC won’t accept “it’s in the other system” as an answer.
Data protection requests become a scavenger hunt. When someone makes a subject access request, you have a month to give them everything you hold about them. With four systems, that means four logins, four searches and four exports, plus the spreadsheets nobody remembers making. The same goes for a request to be forgotten: miss one system and you haven’t actually deleted them.
The work of joining it all up falls to a person, usually the only comms person or a fundraiser who has become the “data person” on top of their real job
The person in the middle
Meanwhile, the work of joining it all up falls to a person, usually the only comms person or a fundraiser who has become the “data person” on top of their real job.
They’re the one exporting CSVs, deduplicating by hand, and maybe even keeping a Zapier chain going that always seems to break randomly. They carry the full picture of the organisation’s supporters in their head because no system holds it. When they go on holiday, or leave, much of that knowledge goes with them.
This isn’t a skills problem. Small charities are stretched, staff wear many hats, and proper integrations need time, money and technical know-how that most teams don’t have. Even when an integration exists, it’s often one-way, it syncs only some fields, or it costs another monthly subscription on top of the tools it connects.
It’s not you, it’s the structure
The cause isn’t how charities run their tech. It’s how the tech was built.
Most of these tools were built for businesses and then adapted for charities. Each was designed to sit at the centre of its own world. Your email platform assumes it owns your contacts, and so do your CRM, your donations platform and your ticketing system. Each sees the supporter only through its own lens: an email address, a payment, a ticket, an order.
None of them were designed to share one person.
That’s why a better connector or a cleverer spreadsheet doesn’t fix it. You can tie the tools together, but you’re still running four versions of the truth and hoping they agree.
Starting from the supporter
There’s another way to think about it. Start with the person, not the software.
In this model, there’s one record for Sarah. When she signs up to the newsletter, buys a ticket, orders from the shop or sets up a monthly gift, each action adds to that record instead of creating a new one.
Here’s what that changes in practice:
- You thank before you ask. The appeal knows Sarah already gives monthly, so she gets a thank-you and an update on her impact instead.
- Every event builds on the last. Last year’s attendees are already in the audience for this year’s invitation, with no export needed.
- Consent is recorded once and respected everywhere. Each channel’s yes or no, and the basis, date and source behind it, live with the person, so every message follows the same rules.
- Gift Aid declarations sit with the gifts they cover. They’re ready when it’s time to claim, and ready if HMRC asks.
- A subject access request takes minutes, not days. Everything you hold about someone is already in one place.
- Your best supporters stand out. The person who gives, volunteers and comes to every event finally looks like what they are.
- The knowledge stays when people leave. The full picture lives in the system, not in one person’s head.
None of these are new ideas. Every fundraiser knows they should work this way. The difference is whether your tools make it the default or leave you to piece it together by hand.
Where this leaves us
Charities shouldn’t need a data engineer to treat supporters like people. A small team running a local appeal deserves the same joined-up view as a national charity with an IT department, and probably needs it more.
We think the answer isn’t another tool to bolt on, or another integration to maintain. It’s building charity software the other way round: the supporter in the middle, and everything else feeding in.
If you liked this post, you might want to keep tabs on what we’re building. It’s called Unific, and you can keep up to date on our Digital Insider newsletter.