Nonprofit event registration is usually compared on the wrong axis. The lists rank products by features, when the constraints that actually decide the answer for a small organisation are the fee model, the number of people who will touch the list, and what happens when the person who set it all up moves on.
A charity gala, a volunteer day, an annual meeting, a free community workshop and a paid training course are five different jobs, and a single product rarely suits all five. What they share is the environment: a small team, a tight budget, board members who want a number by Thursday, and a fundraising calendar where the same shape of event returns every year and has to be rebuilt from whatever survived.
What makes nonprofit registration different
Three constraints separate this from commercial event registration, and each one rules out a common answer.
The fee comes out of the mission budget. A per attendee fee on a commercial conference is a cost of sale. On a free community event with three hundred attendees and no ticket revenue, the same fee has no income to sit against. That changes which pricing models are viable, not just which are cheaper.
The attendee list is also a relationship list. For a business, registrations are leads. For a nonprofit, the same rows may contain donors, volunteers, beneficiaries, board members and local officials, sometimes the same person in two roles. Deleting a row after the event, or leaving the data inside a platform that is cancelled next year, destroys something that took years to build.
The people running it change. Volunteers rotate, staff are part time, and the person who built last year's form may not be there this year. Any setup that depends on knowing where things are, rather than on being visible in the list, will be rebuilt from scratch annually.
The event calendar repeats
Most nonprofit events come back: the annual meeting, the spring fundraiser, the summer volunteer days, the autumn appeal. That makes reuse more valuable here than almost anywhere else. Being able to copy last year's form with its questions, its confirmation email and its stages intact, while keeping last year's registrations available to look at, is worth more than any single feature, because it turns a two week rebuild into an afternoon.
The fee question, and who ends up paying it
Pricing in this category takes several shapes, and the shape decides whether a successful event costs the organisation money.
| Fee model | Works when | Turns painful when |
|---|---|---|
| A percentage of each ticket or donation | Ticket prices are high and revenue covers it | The event is free, or the fee quietly reduces every gift |
| A fee the attendee is asked to cover at checkout | Donors are used to the pattern and the ask is optional | The extra step reduces completion, which is hard to measure and easy to ignore |
| Per registration or per attendee | Attendance is small | A free community event succeeds and the bill scales with the good news |
| Per event | A couple of large events each year | A calendar of many small events, each carrying a fixed cost |
| A flat subscription by team size | Several events a year and a stable, small team | Nothing much, provided the team size band is honest about occasional helpers |
| Free tier, limited by entries or forms | The cap sits well above real numbers | The cap is reached mid campaign, which happens at the worst moment |
Two things are worth checking before committing. First, whether the free or discounted nonprofit plan is the same product or a reduced one, since a reduced version often removes exactly the part that saves the work, such as multiple users. Second, whether the model charges for volume or for team size. A nonprofit's volume is lumpy by definition, and a bill that depends on how many staff use the tool rather than how many people register is predictable in a way that per registration pricing is not.
Payment processing fees sit underneath all of this and are separate from the software fee. Compare the two lines separately, because a product that advertises no platform fee may still route payments through a processor whose rate is unremarkable.
Registration and donation in the same form
Free events are where the most money is left on the table, because nobody is asked for anything.
Adding an optional donation to a registration form works, and it works best when it is specific. A general "would you like to donate" performs worse than a line that names what the amount does, stated in the organisation's own terms, with a small number of suggested amounts and a free entry option. Keep it optional, keep it to one screen, and never make it a condition of attending a free event.
There is a second, quieter opportunity that costs nothing at all. A registration form is the one moment when someone has actively raised their hand, and it is a reasonable place to ask, as an optional question, whether they would like to hear about volunteering, receive the newsletter, or be contacted about the next event. Consent captured at that moment, with the wording and timestamp kept on the record, is more useful and more defensible than a mailing list assembled later from an attendee export.
What to do with the answers
An optional donation question and a volunteering question both create an obligation. Somebody has to thank the donor, and somebody has to contact the person who offered to help. If no process exists behind the question, leave it off the form, because an unanswered offer of help is worse than never having asked.
Volunteers, guests and the lists that are not attendees
A nonprofit event produces several lists, and treating them as one list with a field is almost always better than building separate forms for each.
Attendees, volunteers with shifts, sponsors and their guests, board members, and speakers all need to be in the room and all need different information sent to them. If each group has its own form, the door list has to be assembled by hand from four exports on the morning of the event.
The workable pattern is one registration with a role field, then conditional questions per role: shift preferences and an emergency contact for volunteers, guest names for a sponsor table, dietary requirements for anyone at a seated meal. One list, filtered by role, produces the door list, the volunteer rota and the catering count from the same rows.
Volunteers need one thing attendees do not, which is a state that changes over time: expressed interest, confirmed for a shift, briefed, attended, thanked. That is a status on a record, and it is the main reason volunteer coordination outgrows a spreadsheet faster than attendee registration does. Signups and the follow up that comes after them are the same process for both groups, with a different sequence of states.
Where the attendee data should end up
Decide before registration opens where these records live a year from now. Many small organisations hold donor and volunteer information in a database that is separate from whatever took the registrations, and the join between the two is done by hand every time.
The pragmatic answer for a small team is to pick one place as the reference and move data towards it on a schedule rather than continuously. A monthly export from the registration list into the donor record, matched on the email address, is unglamorous and it works. What fails is intending to do it continuously and doing it never, which is how an organisation ends up with four partial lists and no way to tell which is current.
One detail makes the matching bearable. If the registration list keys people on their email address, so that the same person answering three forms over two years stays one person rather than three rows, the export arrives already deduplicated. Doing that reconciliation afterwards, by eye, across several years of attendee spreadsheets, is the task nobody volunteers for twice.
Receipts, records and what the finance person needs
Two record keeping duties attach to nonprofit event registration, and both are easier to satisfy at registration than to reconstruct afterwards.
The first is the acknowledgement a donor is entitled to. The rules on what has to be issued, when, and what it must state, including how to handle the value of anything the attendee received in return, are set by the tax authority in the organisation's jurisdiction and change from time to time. The current guidance should be confirmed with whoever prepares the annual return before registration opens, rather than inferred from what a software product's template happens to produce. What is within your control is the record: for each registration, what was paid, what was a ticket, what was a gift, when it was received, and the wording the person was shown at the time.
The second is the internal trail. The finance volunteer or the auditor will ask which registrations were comped, who authorised a waived fee, which payments arrived by bank transfer outside the system, and why the attendance count differs from the ticket count. None of those are questions the registrant answers. They are fields the team fills in afterwards, and they need to sit on the registration record rather than in a separate sheet that only one person maintains. Fields your own team completes after the form was submitted, exported as columns alongside the answers is the mechanism that keeps the reconciliation to one file.
The handover problem
The most expensive recurring cost in nonprofit event registration is not the software fee. It is the rebuild that happens when the person who ran it last year is gone, and nothing survived except a spreadsheet with no explanation.
Three habits prevent most of that, and none of them require a particular product.
Put the process in the list, not in a person. Stages with plain names, an owner on each registration, and notes on the record mean the next person can read what happened rather than ask. A spreadsheet colour coded by a convention that lived in one volunteer's head is the opposite of this.
Make sure more than one person has access. Single user accounts are a common false economy in small organisations. When the account belongs to a departed volunteer and the password is unknown, the data is gone regardless of what the product promised.
Keep the export. At the end of every event, take a full export including the internal fields and store it where the organisation, not an individual, keeps its records. This is the cheapest insurance available against a cancelled subscription, and it is the one step most reliably skipped.
What to change first
Work out which fee model matches the shape of your calendar, because a per registration fee on a free community event is the one mistake that gets more expensive as the mission succeeds. Then put a role field and a status on one registration list instead of running separate forms for attendees, volunteers and guests, which is what makes the door list and the rota come out of the same rows. If last year's event lives in a spreadsheet nobody can fully explain, see what one list with owners and stages looks like in Halict before this year's registration opens.
Q1. Is there genuinely free event registration software for nonprofits?
There are free tiers and nonprofit discounts, and the question to ask is what the free version is limited by. A cap on registrations or on forms will be hit during a campaign. A limit on how many people can use the tool is easier to live with, though it is worth checking whether the free plan still allows the second person who will cover for you.
Q2. Should the attendee be asked to cover the processing fee?
It is a common pattern and donors are used to seeing it, but it adds a decision to the checkout and some people abandon at that point. The loss is invisible, which is why the practice looks free. If the option is offered, keep it optional and pre selected at most, and compare completion rates across two comparable events before assuming it costs nothing.
Q3. Can one form handle attendees and volunteers for the same event?
Yes, and it is usually better than two forms. Use a role field at the top and reveal only the relevant questions, such as shift preferences and an emergency contact for volunteers. One list means the door list, the rota and the catering count come from the same rows rather than from three exports that have to be merged on the morning.
Q4. What records should a nonprofit keep from each event registration?
For every registration, keep what was paid and what part of it was a gift, the date, the wording the person agreed to, any consent they gave for future contact, and the internal notes such as a comped ticket or a payment received outside the system. The rules for donor acknowledgements themselves are set by the tax authority in your jurisdiction and should be confirmed with whoever prepares the annual return.
Q5. Is a fundraising platform or a general form tool the better choice?
A fundraising platform earns its fee when ticket sales, auctions, peer to peer fundraising or donor records are central to the event. For free community events, volunteer days, annual meetings and training sessions, most of that goes unused and the work is in the chasing, the confirming and the follow up. In that case a form tool with real response management and a bill that does not grow with attendance is usually the better fit.