Building the form is not the hard part. Any tool will produce a registration form with a name field, an email field and a submit button in about ten minutes, and it will look fine. The hard part starts the moment the link goes out, because from then on the thing that matters is not the form. It is the list, and the list has to be correct on a specific day in front of people who are standing in front of you.
Most of the trouble with online registration comes from the same source: the form was designed as a way of collecting answers, when what was actually needed was a way of maintaining a roster. Those are different jobs, and the second one continues for weeks after the first one is done.
Decide the capacity rules before the link goes out
Capacity is the decision that is hardest to change later and the one most often left until it bites.
Work out four numbers in advance. The hard limit, meaning how many people can physically be accommodated. The point at which registration closes, which is rarely the same as the hard limit because of no shows. Whether there is a waiting list, and how somebody moves off it. And the date registration closes regardless of numbers, because there is usually a catering order or a room booking that has to be confirmed.
Then check whether the tool can enforce those rules rather than leaving them to be watched by hand. Closing a form automatically on a submission count or a date is a feature some tools include on their free tier, Tally among them, and where it does not exist the fallback is somebody remembering to close the form on a Friday evening. That fallback fails roughly once per event, and an over subscribed event is a worse problem than an under subscribed one because it has to be resolved by disappointing named individuals.
The waiting list deserves a specific decision rather than an intention. Two arrangements work. Keep registering past the limit and mark the overflow with a stage of its own, so promoting somebody is a status change and the order is preserved. Or close the form and put a short second form behind it for people who want to be told about cancellations. What does not work is a note in the confirmation email saying the event is full and somebody will be in touch, because nothing records who was told what.
Keep the form to what is needed to hold a place
Registration forms grow. Somebody asks for dietary requirements, somebody asks for a job title for the badge, somebody in marketing asks how they heard about it, and the form reaches fourteen questions for an event that needs three.
Sort the questions by when the answer is actually required.
Needed to hold a place. Name, email, which session or date, and whatever determines eligibility or price. That is usually the whole list. Every additional field on this form costs registrations, and the effect is largest on phones, which is where most registration links get opened.
Needed before the day. Dietary requirements, accessibility needs, badge details, a session choice for a multi track programme. These do not have to be on the registration form. They can be collected in a second, short form sent to confirmed registrants a fortnight before, which has two advantages: the registration form stays short, and the answers are fresh rather than three months stale.
Needed only for reporting. How did you hear about this, would you like to join the mailing list. Put these last, make them optional, and accept that the answers will be patchy.
The single field worth arguing about is the phone number. It reduces completions noticeably and it is genuinely useful on the day when somebody has not arrived. A reasonable compromise is to ask for it in the pre event form rather than at registration, where it is needed only for the people who actually turn up.
One person, three rows
Duplicates are the most common defect in registration lists and they arrive by several routes.
Somebody submits, sees no confirmation because it went to spam, and submits again. Somebody registers, then registers a colleague using their own email address. Somebody registers for two sessions and appears twice, which may be correct or may not be. Somebody's name is spelled two ways.
The mitigations are worth setting up before the link goes out, because de-duplicating afterwards means judgement calls about strangers.
Prevent repeat submissions from the same person where the tool supports it, which Tally offers on its free tier. Use the email address as the identity key, so the same person answering more than once stays one person rather than becoming several unrelated rows. Send a confirmation immediately, because a visible confirmation is what stops the second submission. And decide explicitly whether one person registering for two dates should be two records or one record with two dates, because the answer determines whether the headcount for each session is trustworthy.
A list where identity is keyed on something stable is also what makes the second contact possible. Sending the pre event form only to confirmed registrants, and the reminder only to people who have not cancelled, both depend on knowing who is who.
The confirmation email is where it fails quietly
The confirmation is the most important message in the whole process and the one least often checked, because it works on the desk where it was built.
Three things go wrong. It does not arrive, because it was sent from an address belonging to the form vendor and the receiving server distrusted it. It arrives but is not recognised, because the sender name is a service rather than the organisation the person registered with. Or it arrives without the information people actually need, which is the date, the time, the location and what to do if they cannot come.
Deliverability is worth taking seriously here specifically. Sending from your own domain is possible on some plans and not others, and it is the single change with the largest effect on whether the message lands. Without it, a proportion of registrants will have no record of registering, and that proportion turns up as either duplicate submissions or arguments at the door.
The related problem is that an unopened message and an undelivered message look identical from your side. Where opens and clicks are recorded, the list can be checked a week before the event and the people who never saw the confirmation can be contacted a second time. Where they are not recorded, the first sign of trouble is the day itself. Whether a tool sends from your own domain and whether it records opens tend to sit on specific plans, so it is worth checking the pricing against the size of the event rather than assuming.
Include in the confirmation the things people will look for later: what, when, where, what to bring, and a clear instruction for cancelling. A cancellation route in the confirmation email is not a courtesy, it is how the list stays accurate.
Cancellations, changes and the week before
A registration list is only useful if it reflects reality on the day, and reality changes continuously in the final fortnight.
Give each registration a stage rather than treating registration as a binary. Registered, confirmed, cancelled, waiting, attended covers most events. Stages do two things: they let more than one person work the list without duplicating effort, and they make the headcount answerable at any moment without a spreadsheet filter that somebody has to remember to apply.
Assign an owner where registrations need individual handling, such as courses with prerequisites or applications with eligibility checks. Two colleagues working from the same mailbox with no owner field produce the familiar pair of failures: the registrant who gets two different answers and the registrant who gets none.
Record cancellations rather than deleting them. A deleted row loses the fact that a place opened, which is exactly the information the waiting list needs, and it also loses the audit trail when somebody claims to have cancelled and nobody can tell.
Keep internal notes separate from the answers. Paid by invoice, needs a parking space, cancelled twice before. This is the information that makes the list useful to the people running the event, and it must not be visible to the registrant. Where a tool supports internal fields, these also appear as columns in the export, which is what makes the day of list printable. The features list is the place to check whether stages, owners and internal fields exist before committing to a tool, since retro fitting them means a migration.
Check what the tool counts before a popular event
Registration is spiky by nature, which makes response metering a specific risk rather than a theoretical one.
Several widely used form tools meter responses per month. Typeform's Basic plan at 39 USD a month includes 100 responses a month with one user. Jotform's free tier allows 100 submissions a month across 5 forms, and its Bronze plan at 39 USD a month allows 1,000 submissions a month across 25 forms. Cognito Forms places no cap on the number of forms on any plan but meters entries, at 100 a month on the free tier and 2,000 a month on Pro at 24 USD. Tally allows unlimited forms and submissions on its free tier subject to fair usage, with a 10 MB per file limit that its Pro plan at 24 USD a month removes.
None of those is wrong. The point is that a response meter and a registration campaign have opposite shapes. The ceiling arrives in the week the link is working best, and the failure mode is the worst available: a form that stops accepting registrations without telling the person who published it.
Seat counts deserve the same check. Several entry plans include exactly one user, which makes shared work on the list impossible regardless of the monthly figure. Two people handling registrations is not an advanced requirement.
Test the list, not the form
Before publishing, register yourself twice from a signed out browser on a phone. Then do the four things you will actually do for the next month: find your own registration in the list, change its stage, send a message from inside the tool, and find that message a week later.
That sequence exposes almost everything that matters. Whether the confirmation arrives and looks credible. Whether the list is workable by more than one person. Whether replies are attached to the registration or scattered in a mailbox. Whether the export contains the columns needed for a door list. Rebuilding the whole form during a trial tells you about the editor, which is the part that stops mattering the day the link goes out. The demo exists for exactly this kind of walk through.
What to change first
Take the last event and ask two questions: how many people had to be contacted twice because the confirmation never reached them, and how many minutes went into producing an accurate list on the morning. If either answer is uncomfortable, the fix is not a better form. It is a list where each registration carries a stage and an owner and every message sent stays attached to it, which is what Halict is built around.
Q1. How many fields should an online registration form have?
Only the ones needed to hold a place, which is usually name, email, which session, and whatever affects eligibility or price. Everything else can go in a short second form sent to confirmed registrants before the event, which keeps the registration form short and produces fresher answers for things like dietary requirements.
Q2. How do you stop the same person registering twice?
Send a confirmation immediately, because the invisible confirmation is what causes the second attempt. Beyond that, use the email address as the identity key so repeat answers attach to one person, and turn on duplicate prevention where the tool offers it, which Tally includes on its free tier.
Q3. Can a registration form close itself when the event is full?
Some tools can close a form automatically on a submission count or a date, Tally among them on its free tier. Where that is not available, closing the form is a manual task somebody has to remember, which is worth knowing before publishing rather than after an over subscribed event has to be resolved by telephone.
Q4. Will the confirmation email definitely arrive?
No, and this is the most common hidden failure in online registration. Delivery depends on the sending domain, so a message sent from an address belonging to the form vendor behaves differently from one sent from your own domain, which is a feature available on some plans and not others. Where opens are recorded, the list can be checked before the event instead of at the door.
Q5. What is the risk with a free form builder for a popular event?
Response metering. Free and entry plans commonly include 100 responses or submissions a month, and a registration campaign hits its ceiling in the week it is working best. Check what the tool counts and what your busiest week looks like, and check the included user count too, since several entry plans allow only one person to be signed in.