What to ask on an event registration form, and what to cut

Every field on a registration form has a cost, and the cost is paid by the people you most want at your event: the senior ones, filling it in on a phone, between meetings.

Nobody ever regrets a form that was too short. Plenty of organisers have watched a director give up on one that was too long, then had to be chased personally by the client.

The test for every field

Before a field goes on the form, answer one question: what decision does this change?

If the answer is "we might want it later", cut it. Later is not a decision. If the answer is "the caterer needs it", keep it and put it where the caterer's deadline needs it. If the answer is a shrug, you have found a field that exists because a previous form had it.

Applied honestly, this test removes about a third of most corporate registration forms.

What almost every corporate event actually needs

That is usually the whole form. Five fields, one screen, no scrolling on a phone.

The fields worth adding, when they earn it

• Dietary requirements. Only for events with a seated meal, and only in the form that the caterer's deadline actually needs. On a stand-up cocktail event it is noise.
• Session or workshop choice. Genuinely valuable, because it drives room capacity. If your sessions have real limits, set them with a waitlist behind each one rather than letting the form accept more than the room holds.
• Accessibility needs. A short, open, optional field. Always worth asking, never worth a dropdown.
• How did you hear about this. Only if someone has committed to reading the answers. In practice, almost nobody does.

The fields to cut, and where they should go instead

• Postal address. Unless you are physically posting something, delete it. If you are, collect it after registration from the people who qualify, not from everyone up front.
• Company size, industry, budget, buying timeline. This is a sales qualification form wearing a registration form's clothes. It converts worse and it annoys people who were invited by name. Ask afterwards, or ask nobody.
• Anything you already know. If the client supplied the guest list, do not make invited guests re-type their own company. Pre-fill it or drop it.
• Confirm your email address. A second field to catch a typo in the first one. Show the address back to them on the confirmation screen instead. That catches the same mistake and costs nothing to fill in.
• Free-text "any other comments". It generates work and reliably contains nothing you will act on before the event.

The question bank, by event type

Corporate events come in about five shapes, and each one earns a different set of questions on top of the five. Everything in the "add" column changes a decision. Everything in the "later" column is a real need that does not belong at registration. The last column is what gets asked anyway.

Two patterns sit in that table. The seated meal is the only thing that reliably earns a dietary field, and it earns exactly one. Most corporate caterers in Malaysia serve halal by default, so that is an assumption to confirm with the venue, not a question for the guest; the list the guest sees is no restrictions, vegetarian, vegan, no beef, no seafood, and one free line for allergies. The other pattern: a curated room does not need more questions. It needs a decision step, which is the next section but one.

How to ask it, field by field

The question decides whether a field exists. The field type decides whether anyone finishes it on a phone.

Order the fields by how sure the guest is of the answer: name, email, mobile, company, then the choices, with the optional ones last. A form that opens with a dropdown asks the guest to make a decision before it has asked who they are.

When registration needs an approval step

For restricted guest lists, yes. Someone reviews each registration and a ticket is only issued once it is approved. This is common for client events, launches with a curated room, seats the client is paying for, and anything where the client's brand sits on the invitation. It is also the honest answer to a capacity problem: if the room holds 200 and the invitation will be forwarded, approval is how the client chooses which 200.

What the guest should see. The form says plainly that it is a request, not a registration: the button reads "Request a seat". The confirmation screen says the request has been received and by when they will hear back. The ticket and QR code arrive only on approval. A decline is a short, polite note with a route, a waitlist or the next event, never a form error.

What the reviewer needs. One named person, with a deadline. A request that sits for a week reads as a rejection, so the rule is a decision within one working day. The queue should show the fields the decision rests on, which is why "company" and "invited by" matter more here than anywhere else on the form. And the obvious cases should never reach a human: names on the invited list and email addresses on the client's own domain can be approved automatically, so the queue holds only the exceptions.

Rules to write down before the form opens. What qualifies. Who decides the borderline cases, by name. What a declined guest is told. And the cut-off after which requests stop being reviewed and the door takes over, which is a walk-in question: see how to handle walk-in guests who never registered.

What to tell the client's team. Forwarded invitations will arrive as requests. That is the point of the step, not a failure of it. Agree in advance whether the client's own colleagues are approved automatically, because they will forward it first.

Decide all of this before you build the form, not after. Retrofitting an approval step onto a form that has already issued tickets means re-issuing, re-explaining, and a day you will not get back.

One form, or one per audience?

If VIPs, media and general delegates need genuinely different questions, use separate forms rather than one form with conditional branches. Two short forms are easier to fill in, easier to check, and far easier to explain to the client than one clever one.

A worked example: the form for a seated client appreciation dinner

Three hundred guests, invited by name by the client. Seated dinner. Plus-ones allowed for the top tier of invitees only. A restricted room, so approval is on. Here is the whole form, in order, with the copy.

1. Name as it should appear on your badge. Text, required.
2. Work email. Email field, required. Helper text: "Your ticket and QR code will be sent here."
3. Mobile number. Phone field, required, +60 pre-selected. Helper text: "Only used on the day, if we need to reach you."
4. Company. Text, required.
5. Job title. Text, optional.
6. Dietary requirements. Radio buttons: No restrictions, Vegetarian, Vegan, No beef, No seafood. Then Allergies, one optional line.
7. Are you bringing a guest? Yes or No, shown only to the tier that may. On Yes, Your guest's name and their dietary choice. The guest gets their own badge and their own line on the caterer's sheet, and nothing else is asked about them.
8. The privacy notice, one sentence with a link. Then the button: Request my seat.

The confirmation screen: "Thank you, [name]. Your request has been received. [Client] confirms seats within one working day, and your ticket with its QR code will be emailed to [email] once confirmed." The same words go in the email. On approval, the ticket. On decline, a short note with the client contact's name.

Eight questions, one screen on a phone, and every answer changes something: the badge, the ticket, the seat count, the caterer's sheet, or the reviewer's decision.

For a half-day seminar with open registration, the same form loses the guest question and the request wording, and gains a session choice showing places remaining. For a staff town hall it loses company and gains department. Nothing else changes.

Make it work on a phone, because that is where it will be filled in

• One column. Always.
• Inputs at 16px or larger. Anything smaller and iOS zooms on focus, which feels broken even though it is not.
• The right keyboard for each field: email keyboard for email, number pad for phone.
• No date pickers for anything you could ask as a simple choice.
• Test it on a real phone, on mobile data, not on your laptop at the desk.

What happens after submit is part of the form

The confirmation is where most registrations quietly fail, because a form that submits successfully still leaves the guest with nothing if the email never lands.

• Show the confirmation on screen, not only by email. Their ticket and QR code should be visible immediately.
• Send the email as well, and expect a share of them to be eaten by corporate filters. That is a real, common failure with its own fixes.
• Send the ticket again closer to the day. A meaningful share of guests will have lost the first one.

The short version

Five fields, one screen, one column. Every additional field has to name a decision it changes, and the question bank above is the list of the ones that do. Ask each question in the field type a phone can finish. Decide approval before you build, not after, and write the rules down. And treat the confirmation screen as part of the form, because for a guest whose corporate mail filter ate your email, it is the only part they will ever see.