The form goes up on a Tuesday. By Friday there are sixty replies in a spreadsheet, four emails from people asking whether they got a place, two cancellations sent to a personal address rather than the shared one, and one message from a colleague asking who is handling the dietary requirements. Nothing has broken. The registrations arrived exactly as intended. The problem is that arriving was only the first of several things that had to happen, and only the first one was set up in advance.
That gap is what most teams mean when they say online registration is not working. The collection part is solved and has been for years. What is usually missing is everything that happens between a submission landing and a person walking through the door on the day.
What online registration actually has to cover
It helps to separate the job into four parts, because tools tend to be strong at one or two of them and silent about the rest.
Collecting is taking the answers. A form, a link, a submit button. Every tool on the market does this competently.
Confirming is telling the registrant that the place is real. This is the auto reply that goes out within seconds, carrying back what they entered so they can check it, plus the date, the location and whatever they need to bring. Most form tools can send this. Fewer can send it with the answers embedded.
Tracking is knowing, at any moment, what state each registration is in. Confirmed, waitlisted, cancelled, paid, not paid, attended, no show. This is where spreadsheets are pressed into service and where they start to strain, because a spreadsheet has no opinion about what a valid state is and no memory of who changed what.
Communicating is the reminder a week out, the reminder the day before, the room change notice, the follow up afterwards. This is a mailing job attached to a list that keeps changing.
A registration process that only does the first two is not finished. It has simply moved the second half of the work into an inbox, where it stays invisible until something is missed.
Why the split matters when choosing a tool
Comparing form builders on the strength of their form editor is comparing them on the part that is already a commodity. The question that separates them is what exists on the screen after a response arrives. Some show a row in a table and stop. Some give each response an owner and a status and a history of what was sent to that person. The difference in daily effort between those two is far larger than the difference between two drag and drop editors.
The registration form is the smallest part of the job
A registration form for a single session event needs a name, an email address, and whatever genuinely changes what happens on the day. That is often three or four fields. Teams routinely ship fifteen.
The extra fields arrive with good intentions. Someone in marketing wants job title. Someone in operations wants to know how the attendee heard about the event. Someone wants a phone number in case of last minute changes, although nobody has ever called one. Each field is cheap to add and none of them is free to answer.
The test worth applying to every field is direct: if this answer were blank, would anything about the event be done differently? Dietary requirements pass, because catering changes. Accessibility needs pass, because the room changes. Company name usually fails for an internal event and passes for a trade event where badges are printed. Job title almost always fails, because nobody reads it before the day and it can be asked afterwards in a survey where the cost of a question is much lower.
Keeping the form short is not a cosmetic preference. On a phone, every field is a tap, a keyboard, and a chance to close the tab. For a free event, the drop off between a four field form and a fourteen field form is the difference between a full room and a half empty one.
Where the attendee list starts to drift
Spreadsheets are excellent at holding rows and poor at holding state. The drift that follows is predictable enough to name.
Two people edit the same row. One marks a registrant as confirmed, another marks the same person as waitlisted, and the last write wins silently. There is no record that a disagreement happened.
Cancellations arrive out of band. Somebody replies to the confirmation email rather than using a cancellation link, so the row still says confirmed. The seat is counted as taken and the waitlist does not move.
The same person registers twice. Once with a work address, once with a personal one, because they were not sure the first one went through. The list now shows two attendees. Catering is ordered for two.
Nobody knows what has been sent. A reminder goes out from one person's mail client. A second reminder goes out from a colleague who did not know about the first. The registrant gets two identical emails and concludes the organisers are not talking to each other.
Each of these is a communication problem rather than a data problem, which is why adding more columns to the sheet does not fix it. The fix is to have one place where the state of a registration lives, where changing it leaves a trace, and where every message sent to that person is recorded against them. That is the specific thing a form tool with response management provides and a spreadsheet does not.
The column that gets added too late
Most teams eventually add a status column. It is almost always added after the first event where something went wrong, and it is almost always free text, which means it contains confirmed, Confirmed, CONFIRMED, conf, and yes by the third event. Statuses only help when the set of allowed values is fixed and every row has one.
What the tools cost, and what the price is counting
Prices for form tools look similar and count entirely different things. Reading a price without reading the meter behind it is how teams end up upgrading a week before an event.
| Tool | Free tier | What the paid tier meters |
|---|---|---|
| Google Forms | Free with a Google account | Not metered on responses; sold as part of Workspace |
| Jotform | Starter: 5 forms, 100 submissions per month, 500 stored total | Submissions per month and total stored submissions |
| Typeform | Free tier exists, response capped | Responses per month, plus number of users |
| Per seat form tools | Varies | Number of people on the team, responses unlimited |
The figures above for Jotform come from the plan limits published on the Jotform pricing page, where the Starter plan lists 5 forms, 100 monthly submissions, 500 total stored submissions and 100MB of upload space. Typeform's published plans start at Basic, listed at 39 USD per month with 100 responses per month and 1 user on the Typeform pricing page.
For an event, the meter that matters is the one that a spike will hit. A conference with 400 registrations in a two week window blows through a 100 per month allowance on day one, regardless of how quiet the rest of the year is. A tool priced on team size rather than volume behaves the opposite way: the bill does not move when registrations spike, and it moves when a fourth person joins the team. Neither axis is better in the abstract. They are better for different shapes of event, and the shape is knowable in advance.
The cost that never appears on a pricing page
The larger number is usually time. An event with 300 registrants where confirmations, reminders and cancellations are handled by hand out of a shared inbox consumes a person for several days. The same event where each registration carries its own status and the reminder goes out to a filtered list consumes an afternoon. That difference does not show up in any tool comparison, because it is not a feature. It is what the features add up to.
Cancellations, waitlists and the cases that break the plan
The happy path is easy. Everything that goes wrong on the day traces back to a case that was not designed for.
Cancellations need a route that is not a reply to an email. If the only way to cancel is to write to the organiser, cancellations will be slow, ambiguous and sometimes missed entirely. A cancellation that updates the record directly is what makes the seat count trustworthy.
Waitlists only work if the promotion from waitlist to confirmed is a single visible action that also sends the person a message. If promoting somebody means editing a spreadsheet and then remembering to write to them, the second half will be forgotten at least once.
Name changes and substitutions are common in corporate events, where a booked ticket gets handed to a colleague. Deciding in advance whether this is allowed, and how it is recorded, avoids a check in desk argument.
Duplicate registrations should be collapsed on the email address rather than the name, because people spell their own names inconsistently and their email address rarely varies. A system that keys a contact to the address keeps one person as one person across several forms.
What the list has to look like before check in day
Working backwards from the door is the fastest way to find out whether the process is finished.
At the check in desk, somebody needs to open a list, search a name, and mark that person as arrived. That list needs to be current as of that morning, not as of the last export. It needs to show only confirmed attendees, not cancellations, not the waitlist, and not the test submission somebody made in week one. It needs to be readable on a phone, because check in desks rarely have a second monitor.
If producing that list requires an export, a filter, a manual removal of cancellations and a print, the process has one step too many and that step will be done the night before, which means every cancellation received on the morning of the event is invisible.
The corresponding test for the week before is different: can a reminder be sent to everyone who is confirmed and has not cancelled, without building the list by hand, and will there be a record afterwards showing who received it? If both answers are yes, the process holds. If either is no, the failure will be discovered during the event rather than before it.
What to change first
Take the last event that was run and find the single moment where somebody had to look something up in two places to answer one question. That is the seam, and closing it is worth more than any change to the form itself. If the answer is that registrations live in a sheet while the conversation lives in an inbox, put both on the same record and see what the next event feels like. Halict keeps the response and the reply on one screen, which is the shape that seam wants.
Q1. What is the minimum a registration form needs to ask?
A name, an email address, and anything that changes what happens on the day, such as dietary or accessibility requirements. Everything else can be asked after the event in a follow up survey, where an unanswered question costs nothing.
Q2. Can event registrations be handled with a free tool?
For a small event, yes. The constraint to check is not whether the tool is free but what the free tier meters. A plan that allows 100 submissions per month is comfortable for a workshop and inadequate for a conference that takes 400 sign ups in a fortnight.
Q3. How should cancellations be handled so the seat count stays accurate?
Give registrants a way to cancel that updates the record directly rather than sending an email to an organiser. Cancellations that arrive as replies have to be transcribed by hand, and transcription is where the count drifts.
Q4. Do attendees need to create an account to register?
They do not, with most form tools, and requiring one measurably reduces completion. The exception is file upload on some platforms, where the respondent may need to be signed in to the provider's account before a file can be attached.
Q5. How far in advance should reminders go out?
One a week before and one the day before covers most events. What matters more than the timing is that the reminder goes to a list filtered on current status, so that people who cancelled do not receive it and people promoted from the waitlist do.