A conference registration form looks like a solved problem right up to the moment somebody asks which breakout session a delegate picked, whether the caterer has the final allergy count, and why two badges have been printed for the same person under different spellings. The form itself takes an afternoon. The ten weeks that follow it are the actual job.
What separates a conference form from an ordinary event sign up is that the answers feed other deadlines. Session choice feeds room allocation. Dietary answers feed a caterer who needs numbers before the venue will confirm. Badge name feeds a print run that cannot be redone on the morning. Each of those has its own cut off, and each of them changes after somebody has already registered. A form that only collects, and hands the rest to a spreadsheet, quietly makes all three of those deadlines harder.
Collect only what has a job
The temptation is to ask everything while the delegate is already typing. Resist it, because every extra field costs completions and every field collected has to be stored, exported and eventually deleted.
A field earns its place if a named person will act on the answer. Job title earns its place if the programme committee segments sessions by seniority or if the badge shows it. It does not earn its place because it is on every other conference form. The same test kills most of the marketing questions that get added late in the process.
What almost always earns its place: name as it should appear on the badge, email, organisation, ticket type, session choices, dietary and accessibility needs, and whoever should be invoiced if that is not the delegate. What usually does not: postal address for a conference with no physical mailing, phone number when nobody has a plan to call, and any question whose answer would not change a decision.
One more test worth applying. If the answer will be needed after the event as well as before it, say for a certificate of attendance or a follow up, it belongs in the record rather than in a one off email thread. Anything that lives only in somebody's inbox is lost the moment that person goes on leave.
Session choice is the field that breaks
Breakout sessions are where a simple form turns into a system. The requirements pile up fast.
Sessions run in parallel tracks, so a delegate picks one per slot rather than any number. Rooms have capacities, so a session can fill, and a form that keeps accepting choices for a full room creates a problem that surfaces on the day. Delegates change their minds, sometimes in week nine. And the organising committee wants a per session count that is current, not the count as of the last export.
Three approaches are common. The first is one question per time slot with the sessions as options, which handles the one per slot rule cleanly and is the right default. The second is a single multi select, which is easier to build and produces clashes that somebody has to untangle by hand. The third is capping by closing options as they fill, which requires either a tool that supports per option limits or a person watching the counts.
Decide early whether session choice is binding or indicative. If it is indicative, publish that clearly and the pressure comes off the capacity question. If it is binding, the form has to enforce it and somebody has to own the waitlist. Conferences get into trouble by leaving this unstated, then discovering that delegates treated a soft preference as a reservation.
Dietary needs and accessibility, asked once and usefully
Two questions that look similar and are not.
Dietary requirements split into three kinds: allergies, which are a safety matter and need to reach the kitchen precisely, religious or ethical requirements, which need a reliable count, and preferences, which need a rough count. A single free text box collects all three mixed together and hands the caterer a paragraph per delegate. A fixed checklist misses the real allergy that is not on the list. The arrangement that works is a short set of common options plus a free text box for anything else, with the free text clearly labelled for allergies and severity.
Accessibility needs belong in a separate question, because a delegate who needs step free access and a seat near the front should not have to write it into a food box. Ask it openly rather than as a checkbox list, and route the answers to whoever handles the venue rather than to the caterer.
Both of these are health related answers about identifiable people. Under most privacy regimes that raises the sensitivity of the record, which has practical consequences: restrict who can see the answers, do not paste them into a shared spreadsheet that the whole committee can open, and delete them once the event is over. A tool where each response has an owner and access is limited by role makes this considerably easier than a shared sheet does. The access levels and internal fields in a form tool with response management exist for exactly this kind of split, where the caterer needs a count and nobody else needs the detail.
The badge name problem
Badges fail in predictable ways. Somebody registers as Robert and goes by Bob. Somebody registers their organisation as its trading name and the badge shows the legal entity. Somebody registers a colleague and types their own name by accident. Two people register the same delegate, once through the group booking and once directly, and two badges come off the printer.
A few field decisions prevent most of this. Ask explicitly for the name as it should appear on the badge, separately from the name on the invoice if invoicing is involved. Keep organisation as its own field rather than letting it arrive inside the name field. If pronouns go on the badge, make the field optional and free text rather than a fixed list.
Group bookings make the same problem worse
An administrator registering eight colleagues at once is the single most common source of badge errors. The submission carries one email address, the administrator's, and eight names typed from memory. Either give group bookings their own form that asks for one row per delegate with that delegate's own email, or accept that the badge names will need checking against the organisation before printing. The second option is a task somebody has to be assigned, not a hope.
Duplicates are the harder one, and they are not solved by a field. They are solved by keying registrations on the email address so that a second submission from the same person is visible as a second submission rather than as a second delegate. Without that, the duplicate is found by whoever sorts the badge spreadsheet, usually on the day before the print deadline.
Paid, free, or invoiced: where the money decides the tool
The tool question is really a payment question. Three arrangements cover most conferences.
| Approach | Suits | What it costs | Where it runs out |
|---|---|---|---|
| Ticketing platform | Public paid conferences that also want discovery | Eventbrite charges no ticketing platform fee on free events; paid tickets carry a 3.7% plus $1.79 service fee per ticket and a 2.9% payment processing fee per order | Custom questions, invoicing, and the correspondence that follows registration |
| Form tool with response management | Free, invoiced, or internally billed conferences | A flat plan, usually priced by the number of organisers rather than by attendees | Taking card payment at the point of registration |
| Spreadsheet plus email | Small internal events under fifty people | Nothing, and then a lot of somebody's time | Immediately, once two people edit at once |
The middle row is where most academic, association and corporate conferences actually sit, because the money moves by invoice or by internal transfer rather than by card. In that case a ticketing platform is paying for a checkout that never runs, and its fee model is built around per ticket volume rather than around the handful of people doing the organising. Worth checking the pricing model of any candidate against the shape of the event: a tool billed per response gets more expensive as the conference succeeds, while one billed per organiser does not.
The ten weeks after the form opens
This is the part that no form builder comparison covers, and it is where the hours go.
Registrations arrive and each one needs a state. New, confirmed, invoiced, paid, cancelled, waitlisted. Somebody emails to change a session choice. Somebody's colleague is coming instead, which is a substitution rather than a cancellation and a new badge either way. An invoice needs to go out and somebody needs to know whether it came back. A reminder goes out at two weeks and again at two days, and it should not go to the people who cancelled.
Handled in a shared mailbox, every one of those is a message that two people might answer or nobody might. Handled in a spreadsheet alongside the form, the spreadsheet and the form disagree within a fortnight and the spreadsheet wins because it is the one people look at.
The arrangement that holds up is one record per registration that carries its own state, its own owner and its own history of what was sent. Then the session count is a filter rather than an export, the caterer number is a filter, and the question of whether anyone replied to the delegate who asked about parking has an answer on the screen. Conferences are one of the standard shapes this problem takes, alongside course intakes and membership applications, and they are worth looking at as a workflow rather than as a form.
On the day, work from the same list
Check in should read the same record the registration created. A separate attendee list exported the night before is out of date by the morning, and it cannot record who actually arrived without creating a third version of the truth.
What check in needs is small: find a delegate by name or email quickly, mark them arrived, and handle the walk ups by adding them to the same list. What it must not do is fork. An attendance mark that lands in a different file from the registration record means the post event follow up goes to everyone who registered rather than to everyone who came, and the certificates go out wrong.
What to change first
Take the session choice question and decide, in writing, whether it is binding, then build the form to match that decision rather than leaving it ambiguous. Then check that the tool holding the registrations can also hold a status, an owner and the correspondence, because the spreadsheet that gets opened to cover that gap is the thing that goes wrong. A tool that keeps the reply on the same screen as the registration removes the gap rather than tracking it.
Q1. What fields should a conference registration form actually have?
Name as it should appear on the badge, email, organisation, ticket or delegate type, session choices, dietary requirements, accessibility needs, and invoicing details if the delegate is not the payer. Each additional field should have a named person who will act on the answer, otherwise it costs completions for nothing.
Q2. How should session choice be collected when sessions run in parallel?
One question per time slot, with the sessions in that slot as the options, so a delegate can only pick one per slot. A single multi select across all sessions is easier to build and produces clashes that somebody untangles by hand later. Decide and publish whether the choice is binding or indicative before the form opens.
Q3. Is a free text box enough for dietary requirements?
Not on its own. A short list of common requirements plus a free text box for anything else gives the caterer countable numbers while still catching the allergy that is not on the list. Allergies and severity should be asked explicitly, because that answer is a safety matter rather than a preference.
Q4. Does a conference need a ticketing platform or will a form tool do?
It depends on how the money moves. If delegates pay by card at the point of registration, a ticketing platform earns its fee. If the conference is free, invoiced, or billed internally, the checkout never runs and a form tool that handles the correspondence and the statuses afterwards is usually the better fit.
Q5. How do duplicate registrations get prevented?
By keying registrations on the email address so that a second submission from the same person shows up attached to the existing record rather than as a new delegate. Field validation alone does not catch the common cases, which are a group booking and a direct registration for the same person, or a colleague registering somebody twice.