7 CMS Features Nonprofits Need for Fundraising
A fundraising website lives or dies on a handful of unglamorous jobs. Not design awards. Whether a campaign coordinator can get an appeal page live on a Friday afternoon. Whether the donation form actually works on a battered five-year-old Android. Whether anyone in the building can say, with a straight face, which appeal brought the money in.
Here's the list I'd start with: seven capabilities, the question worth asking about each, and, where Webcoda has built it, the project to go and look at.
Key Takeaways
- Letting non-technical staff build campaign pages alone is the capability that pays off fastest.
- Donation and payment integrations should feed your CRM, not create a second supporter list.
- Accessibility and mobile performance decide who can actually finish a donation.
- No campaign attribution means no way to tell what's working.
- Most of this is implementation, not platform features. Ask to see it demonstrated.
1. Campaign Pages Your Team Can Build Alone
Appeals are time-sensitive. If launching one needs a developer, you'll launch fewer, and later, after the moment has passed. What good looks like: a campaign page type built from the components your appeals actually use (hero, story, progress indicator, donation call to action), that a coordinator can assemble without touching code.
Ask to watch someone do it, and time them. Then ask for a build where that was the goal. Webcoda's migration of UTS College moved roughly 1,400 pages to HubSpot CMS with the design preserved, rebuilding templates and modules so non-developers could edit afterwards. Different sector, same constraint.
2. Donation and Payment Integration That Actually Works
Your CMS shouldn't be your donation engine. What matters is that giving feels like part of your site rather than a handoff to an unbranded third-party page, and that transaction data lands where it should.
One decision to make early: which system holds the real supporter record. Almost always that's your CRM or donor database, with the website writing to it rather than keeping a competing list. Two lists side by side get reconciled by hand, and it's never tidy.
For what that looks like built, the St Vincent de Paul members and volunteers hub keeps member details in a custom CRM, with an integrated user database handling login authentication, so the site reads one record instead of creating a second. Tresillian runs ecommerce and events on Umbraco. Webcoda's systems integration work covers payment gateways including eWAY, WorldPay, SecurePay and PayPal.
Ask this: what happens to a donation if the link between the site and the CRM drops mid-transaction?
3. Accessibility Baked Into the Templates
Accessibility is a fundraising feature, whether anyone frames it that way or not. A donation form that can't be finished with a keyboard, or that fails on colour contrast, locks out donors.
It belongs in the templates, not in authors remembering every time. Webcoda builds to the WCAG guidelines through design and development rather than scanning at the end, which is a working method, not a certification. Can you complete a donation on your site using only a keyboard? If not, start there.
4. Mobile Performance That Actually Holds Up
Most people land on an appeal page from a phone, often on a patchy connection, and every extra second of load costs you donations you'll never know you lost. Performance comes down to implementation: image handling, script weight, how the donation form is embedded. Test on a real mid-range phone over mobile data, not a simulator on office wifi.
5. Campaign Attribution and Reporting
If nobody can answer "which appeal raised this money", nobody can improve anything. That answer needs the website, the donation platform and the CRM to agree on how a campaign is identified, and that agreement has to be designed in at build time. Reconstructing it later from spreadsheets is miserable.
Metropolitan Memorial Parks, built by Webcoda on HubSpot Content Hub, combines analytics, CRM integration and marketing automation covering event registrations, and publishes a "30% Decrease in administrative tasks" as a result. That figure is theirs, from that project, and we won't pretend it's a benchmark for anyone else.
Ask: where do you go to see donations by campaign, and does that number match what finance is seeing?
6. Structured Content You Can Actually Reuse
Fundraising runs on stories, and the same story gets used more than once: appeal page, newsletter, annual report, social post. Stored as structured content, with a defined image, quote, outcome and consent status, they surface wherever you need them. Stored as formatted text in a page, every reuse means retyping.
The consent field matters more than people expect. Knowing which stories you're allowed to keep using, and until when, is a real governance job once the people in them are service users rather than staff.
7. Permissions and Approval That Fit How You Work
Fundraising content often needs a second pair of eyes before it goes live, particularly where it touches service users or funders. You want a coordinator who can draft and submit and an approver who can review, neither needing a developer. Keep the workflow as light as the culture will genuinely follow: a process heavier than people will use gets bypassed within a month.
Getting These Built
Most of the seven are implementation decisions rather than spec-sheet features, so they live or die on the content modelling and integration work done during your build. Get it wrong and it isn't a design problem, it's missed donations nobody circles back to explain. Webcoda has been building websites from Sydney since 2005 and is a Certified B Corporation, a signal with an audit behind it. Our not-for-profit services page has more.
Frequently Asked Questions
Either can work well. What matters is that the experience feels continuous and branded, that the form is accessible and quick on mobile, and that transaction data reaches your CRM reliably every time. A well-embedded third-party form usually beats a custom-built one, mostly for compliance and security reasons.
Yes. The St Vincent de Paul members and volunteers hub holds member details in a custom CRM with an integrated user database for login authentication, shows news and events based on each member's profile, and provides downloadable resources, guides and templates. It's the closest published example to a supporter portal.
Most not-for-profits do, because donor management involves a lot more than web form submissions. What matters is deciding which system is the source of truth and making the other follow it, rather than running two half-complete supporter lists side by side.
That's a job for your donation or payment platform, not the CMS. The website's role is presenting the option clearly and passing the right campaign information through. Make sure supporters can manage or cancel a regular gift themselves, without emailing you to do it.
For most organisations, letting staff build campaign pages unaided. It changes how many appeals you can run and how fast you can respond when something happens, and that compounds over a year in a way a design refresh rarely does.
Three quick checks: how long it takes to get a new appeal page live, how your donation form's completion rate on mobile compares with desktop, and whether you can report income by campaign without reconciling spreadsheets afterwards. A clear failure on any one of those usually pays for itself to fix.
Talk to Webcoda
Webcoda is a Sydney-based, B Corp certified digital agency that has been building websites and enterprise web applications since 2005, for organisations including Sony, BridgeClimb, the Australian Federal Government and NSW Health. We are an Umbraco Gold Partner, a Gold partner for Xperience by Kentico and a HubSpot Solutions Partner, so platform advice comes without a single-vendor agenda.
Get in touch to talk through your project, or browse our full range of services and platforms.
