Updated 2nd July 2026

Choosing the right CRM for your charity: Integration, experience and measurement

Most CRM comparisons focus on features and databases. For charities, that's only half the story. The way your CRM connects to your website is what supporters actually experience - the donation form, the event booking, the newsletter signup, the volunteer enquiry. Get that integration right and the whole journey feels seamless, on-brand, accessible to everyone, and properly measurable. Get it wrong and you'll spend years patching cosmetic issues, fighting reporting gaps and explaining accessibility failures.

This guide walks through the questions that decide whether your CRM will work with your website or against it - integration approach, forms, donations, events, newsletters, analytics, accessibility and future flexibility. Use it as a brief for your team before you take a single sales demo.

How the CRM connects to your website

Not all CRM integrations work the same way. The approach the CRM uses shapes everything else - branding, accessibility, performance, tracking and the cost of changes down the line. The common patterns you'll see are:

• Hosted pages - users leave your site and complete the action on the vendor's domain. Easiest to set up, but you lose branding control and create cross-domain tracking and accessibility inconsistencies.
• Embedded iframes - the form sits inside your page in a frame served by the vendor. Better than redirecting, but still owned by the vendor, often hard to style, and the source of most reporting blind spots.
• JavaScript widgets or scripts - a vendor script injects the form into your page. More native-feeling than an iframe, with better styling, but still controlled by the vendor's code.
• API-driven integrations - your developer builds the form on your own site and posts data directly into the CRM. Maximum control over design, accessibility and tracking, but the most technical effort.
• Native CMS plugins - for example a WordPress plugin from the CRM vendor. Easier than full API work, usually styleable, and updates are managed by the vendor.
• Third-party integration platforms - tools like Zapier, Make or middleware that connect any web form to the CRM, useful when the vendor's native options don't fit.

Whichever route you take, the questions to work through with the vendor are the same. Where does the supporter's data actually get submitted, and does the user stay on the website or get sent elsewhere? How much control do you have over design and accessibility, and how much technical effort will the set-up and its ongoing maintenance really require? What happens when you redesign the site in two or three years, and are there extra licence costs for API access or premium integration options?

Forms and data capture

Forms are the workhorse of a charity website - contact enquiries, volunteer expressions of interest, campaign signups, service applications, event bookings. How the CRM handles them deserves real scrutiny. You want to know whether forms can be styled to match the rest of the site, whether you can add and rename custom fields without going back to the vendor, whether data is stored directly in the CRM or passes through middleware first, and whether the layout you can actually build has hard limits.

Accessibility deserves equal weight. Forms need to be keyboard accessible end to end, with labels and error messages that work properly with screen readers. Users must be able to zoom to 200% without breaking the layout. The form provider should be aiming for WCAG 2.2 AA, the standard most UK organisations now work to. Just as importantly, if you find an accessibility issue you should be able to fix it yourself rather than wait for the vendor's roadmap.

Watch out for generic-looking embedded forms that visibly don't match your brand, forms that aren't fully mobile responsive, poor screen-reader support or vague error messages, and slow-loading third-party scripts that hurt page performance and Core Web Vitals.

Donations

The donation journey is where integration matters most. A friction-free, on-brand, accessible donation experience is one of the single biggest drivers of charity income, and the CRM's integration approach decides what that experience can look like.

Start with the fundamentals. Does the donor stay on your website all the way through, or do they get sent to a vendor-hosted page? Is the form delivered via widget, script, iframe or custom API integration? Can the same form be reused across campaigns and landing pages, or are you stuck with one generic page? And how much control do you have over branding, copy and the visual journey from opening pixel to thank-you?

Accessibility is non-negotiable here. Every supporter, including those on screen readers or with motor impairments, needs to be able to complete a donation without barriers. The payment process should be fully keyboard navigable, validation errors should be announced clearly and tied to the right field, and if users are sent to a third-party donation page you need to be confident the accessibility experience doesn't fall off a cliff.

The wider trade-offs matter too. Every redirect and slow load costs you donors. A branded, on-site donation flow looks more legitimate than a generic vendor page. Recurring giving needs to work inside the same journey rather than forcing donors through a separate direct-debit process. And when you eventually change platforms - because at some point you will - you need to know exactly what happens to your active recurring donations.

Events and ticketing

Events need much richer data than a contact form, and they're where weak CRM integration usually shows up first. The questions to press vendors on are whether attendees can register and pay online in the same flow, whether different ticket types and waitlists are supported, whether you can capture event-specific information beyond name and email, whether attendance feeds back into the supporter record automatically, and whether follow-up communications (the thank-you, the photos, the Gift Aid prompt) can be automated.

The richer the data you can capture at the point of booking, the better. Useful examples include:

• Accessibility requirements
• Dietary requirements
• Session or workshop selections
• Personal fundraising targets and team affiliations
• Emergency contact information

Access requirements in particular should be easy to communicate at the point of booking, the booking journey should be accessible end to end (including any payment step), and confirmation emails and mobile or PDF tickets should be usable with a screen reader.

Newsletter signups and marketing consent

Newsletter signups are usually the highest-volume conversion point on a charity website, so the integration needs to be tight and the consent handling needs to be clean. The same integration patterns apply as everywhere else, but the specific questions are whether consent data is captured and stored correctly against the supporter record, whether supporters can update their preferences in a self-service preference centre, and whether data syncs automatically between the CRM, your email tool and your website - or whether someone in the office has to run an export every Friday.

Beyond the mechanics, keep GDPR front of mind. That means clear opt-ins, a documented lawful basis, and granular preferences that are actually honoured downstream (the ICO's guidance is worth a bookmark). A well-designed preference centre keeps your list clean and your unsubscribe rate lower. Signup data should feed straight into segmentation and marketing automation, whether that's a welcome series, a re-engagement journey or a gentle nudge towards a first donation. And the same accessibility standards apply to signup forms as to every other form, particularly for error states on your highest-volume routes.

Analytics and tracking

A good CRM integration should support measurement, not make it harder. Tracking is where iframe and hosted-page approaches catch charities out, often months after launch when someone tries to report on what actually drove income.

The things to probe are whether Google Tag Manager can be deployed easily across all the pages and forms the CRM touches, whether dataLayer events are available for form submissions, donations, event registrations and signups, and whether GA4 can track these as key events with the right value attached (donation amount in pounds, not just a count). Cross-domain tracking becomes essential the moment supporters move to a CRM-hosted page, and it isn't always cleanly supported. Iframes are worse still, often blocking accurate tracking of form interactions and completions altogether. It's also worth asking whether your marketing team can make tracking changes themselves, or whether every tweak needs the CRM vendor.

Without robust tracking, charities struggle to understand which campaigns generate donations, which channels acquire supporters, how events actually performed, and what their marketing ROI looks like. That makes it harder to fundraise, harder to report to trustees and funders, and harder to justify spend on the things that work.

Future-proofing your CRM choice

A CRM is rarely a short-term decision. Before signing, think about the changes you'll want to make in the next three to five years, and ask each vendor how they'll cope with them.

How easy is it to redesign the website later without rebuilding every form and donation page? Can integrations evolve as your fundraising and digital strategy change? How locked in are you to a single vendor's ecosystem for payments, email, donations and tracking? What are the ongoing costs of customisation, additional users, premium integrations and developer support? If you find an accessibility issue, how quickly can the vendor (or you) fix it? And how easily could your supporter data move out of this system if you ever needed to migrate to something else?

Questions to ask in a demo

Don't accept a generic walkthrough. Bring real scenarios, and ask the vendor to demonstrate them live:

• Show us how a supporter completes a Gift Aided regular donation from this campaign landing page.
• A user is on a screen reader. Walk us through your donation form.
• We've just rebranded. How long does it take to update the look of every form and donation page?
• Show us the GA4 dataLayer events that fire when someone donates, registers for an event and signs up to our newsletter.
• An attendee tells us at booking they need step-free access and a BSL interpreter. Where does that information live and who sees it?

Those questions reveal more in five minutes than an hour of slide-led demos.

Need help choosing or implementing a CRM that fits your website, your supporters and your measurement strategy? Get in touch with the team at Atelier Impact.

FAQs - Choosing a charity CRM

What's the biggest mistake charities make when choosing a CRM?

Buying on feature count rather than asking how the system will sit alongside the website. Plenty of fully-featured CRMs deliver a clunky donation page, force you onto a different domain and make tracking miserable. The integration layer matters more than the feature list for the supporter's experience and your reporting.

Why does it matter whether a form is an iframe or an API integration?

Iframes are owned by the vendor - your design control, accessibility tweaks and tracking are all limited to what the iframe allows. API integrations let your developer build the form natively on your site, with full control over branding, accessibility and analytics. Iframes are quicker to set up but cost you flexibility and often create reporting blind spots.

What level of accessibility should we expect from a CRM's forms and donation pages?

At a minimum, the vendor's pages and embedded components should aim for WCAG 2.2 AA. Ask for a current accessibility statement, recent audit results and a clear answer on whether you can fix issues yourself or have to wait for them. If they can't produce any of that, treat it as a red flag.

Can we track CRM forms and donations in GA4?

Usually yes, but how easily depends on the integration. Pages on your own domain with proper dataLayer events are simple. Hosted vendor pages need cross-domain tracking set up, and even then you can lose visibility on parts of the journey.

What happens to our existing donation pages if we redesign the website?

With API or plugin-based integrations, you redesign the page and the form re-skins with it. With iframes or hosted pages, you're often locked to the vendor's design, and a redesign can mean recreating donation flows from scratch. Ask vendors directly how their pages will hold up through a future redesign.

Are we locked in once we choose?

To an extent, yes - the more your forms, donations, automation and consent records sit inside a vendor's ecosystem, the harder it is to move. Mitigate by choosing vendors with clear data export options, native CMS plugins or API-first architectures, and avoid making any one vendor the keeper of irreplaceable supporter relationships.