Registration systems and data structure
Designing an event registration form
Registration opens next month, and everyone on the committee has a different idea of what the form should ask.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
A good registration form asks for each field only because a named person needs it for a named purpose, puts the fields in the order a person can answer them, and separates the event registration from any marketing permission. Start from what the event must do with the data, not from what a template offers.
Settle the field list before you configure any system, since changing fields after people have registered is harder than changing them before.
Start from the purpose of each field
For every proposed field, write who will use it, for what, and when it can be deleted. If nobody can answer, leave it out. The field minimiser gives you a worksheet for this, with privacy-review questions to take to your data protection contact.
Fields collected only to improve lead scoring or because another event asked for them are the first to challenge.
A field-by-field starting table
| Field | Needed for | Required? | Note |
|---|---|---|---|
| Full name | Badge, record, check-in | Yes | Ask how the name should appear on the badge. |
| Organisation and role | Badge, categories, programme planning | Depends | Only if the event is organised by organisation or role. |
| Confirmation and joining instructions | Yes | Confirm who owns the mailbox for group registrations. | |
| Registration category | Eligibility, pricing, access | Yes | Rules belong in the category rules. |
| Dietary needs | Catering | Optional | Say who sees it and when it is deleted. |
| Access needs | Venue and desk planning | Optional | Ask what help is needed, not for a diagnosis. |
| Session choices | Room and handout planning | Only for multi-session events | Link to capacity rules. |
| Marketing permission | Future communications | Optional, separate | Never pre-ticked or bundled with registration. |
Order and wording
- Group related questions and keep the first screen short.
- Use plain labels and give an example where the format matters, such as how a name should appear.
- Mark required fields honestly, and explain why for anything a person might hesitate to give.
- Put sensitive or optional questions last and say they are optional.
- Write the form in the languages your audience reads, and have each reviewed using the language checklist.
Questions for the registration vendor
How a system validates fields, handles duplicates, exports data or sends confirmations varies by product. Do not assume behaviour. Ask the vendor to answer in writing and, where possible, show it in a test form.
Add them to your vendor brief: which field types and conditional questions are supported, what validation is available, where data is stored and who can export it, how consent is recorded separately, and how fields are deleted after the event.
Test before it opens
- Fill the form as five fictional delegates, including a group booking and a person with an access need.
- Check the confirmation email, the export columns and the badge data match what you intended.
- Ask two people outside the project to complete it and note where they hesitate.
- Freeze the field list at a set date and record who may approve later changes.
Worked example · Fictional example
A first form for a one-day conference
Fictional organisation and figures, for illustration only.
A fictional building-professionals association drafts 14 fields for its annual conference. Using the worksheet, it removes company turnover and length of service because no one could name a use, and moves marketing permission to a separate optional question.
It keeps dietary and access fields as optional, names the catering lead and the registration lead as their only users, and records that both are deleted after the event unless the data protection contact advises otherwise.
Use this yourself
Registration form design worksheet
Copy this table for each proposed field and fill it before configuring anything.
- Registration and marketing permission are separate questions.
- Field list approved by [name] on [date], then frozen.
- Test with five fictional delegates completed and checked.
- Vendor's written answers on validation, export, consent and deletion attached.
| Field | Purpose | User of the data | Required or optional | Shown to | Delete by | Open question |
|---|---|---|---|---|---|---|
| [field] | [why needed] | [role] | [R/O] | [roles] | [date or trigger] | [for vendor or data protection contact] |
Handle it in-house, or bring in help?
Your team can usually handle this when
- Your event is simple and your team has run registration before.
- One category and no sessions to manage.
- You already have a data protection contact who reviews forms.
Outside planning help earns its fee when
- Several categories, sessions, group bookings or eligibility checks must work together.
- Committee members disagree about which fields are needed.
- You are choosing between registration systems and need a clear specification first.
Want the form specified before the system is built?
A conference project lead can run the field decisions with your committee, write the specification and test cases using fictional delegates, and put the vendor questions in writing before configuration starts. Privacy decisions stay with your data protection contact. Send your current field list and categories.
Questions organisers ask
How many fields is too many?
There is no fixed number. Test each field against a named user and purpose, and remove the ones that fail.
Should dietary and access questions be required?
Usually optional, with a clear statement of who sees the answer and why. Ask your data protection contact what notice is needed.
Can we collect marketing permission on the same form?
Often yes, as a separate optional question that is not pre-ticked. Confirm wording and records with your data protection contact.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.