Skip to content

Conference registration form questions: what to ask

A conference registration form should ask only what you will act on. Email, name and ticket type are required. Badge text, dietary needs, accessibility, session choice and consent earn their place because someone uses the answers. Everything else costs you completed registrations. Use conditional logic so each attendee sees only the questions that apply to the ticket they bought.

By Checkout Page · Updated September 5, 2026 · 10 min read

On this page

What should a conference registration form ask?

Ask only what you will act on. Every field should map to a decision somebody makes later: a badge to print, a meal to order, a room to size, an email to send. Email, name and ticket type are required. Everything else has to earn its place, because each extra field costs you completed registrations.

The form is the last thing between a person who wants to attend and your bank account. Organizers add fields because someone in a planning meeting asked for them, and nobody ever removes them.

Before a field goes on the form, name two things: the person who will read the answers, and the action they will take. If you cannot name both, cut the field.

Form friction can be expensive, but this site has no measured abandonment benchmark. Track starts, completions and field-level errors in your own checkout before attributing lost registrations to form length.

Which fields are required on a conference registration form?

Three: email address, attendee name, and ticket type. Email delivers the ticket and every pre-event message. Name identifies the attendee at check-in and on the badge. Ticket type sets the price, the access level and the capacity it counts against. A payment method is required for paid tiers. Nothing else is genuinely mandatory.

Split first and last name into two fields. Single "full name" fields produce badges reading "dr. james okoro-smith" in lower case and make check-in lists harder to sort.

Validate the email and show the buyer what they typed before payment. A mistyped address can prevent ticket delivery and may not be discovered until the conference is close.

Per-attendee or per-order: which details go where?

Order questions are asked once per purchase: billing details, purchase order number, how the buyer heard about you. Attendee questions repeat for every ticket: badge name, dietary needs, session choice. Mixing the two is the most common reason a group booking arrives with one name and five unnamed seats.

Check how your ticketing tool scopes custom questions before you design the form. Some ask once per order, some repeat per ticket, and some let you choose per field.

If your tool asks per order and you sell group tickets to companies, you have two workable options:

  1. Add numbered fields (Attendee 2 name, Attendee 2 email, and so on) shown by conditional logic once the quantity passes one. Fine up to about five seats, unmanageable above that.
  2. Take the order with buyer details only, then email a name-collection form to the buyer. Set the deadline two weeks before your badge print run and chase it twice.

The second option can reduce checkout work when an office manager does not yet know who will attend. It also creates a follow-up task and incomplete-record risk, so compare completion rates and administrative effort before adopting it.

What do you need on the form to print badges?

Four fields cover almost every badge: name as it should appear on the badge, organization, job title, and pronouns as an optional free-text field. Attendee type (speaker, sponsor, staff, attendee) comes from the ticket type, not from a question. Ask for badge text separately from legal name.

"Name as it should appear on your badge" is worth its own field. It lets Katherine print as Kate, keeps honorifics off the badge for people who do not want them, and stops you printing an all-caps passport name across the front.

As a rule of thumb, keep the badge name line to about 20 characters so the type stays readable from six feet away. Say so in the field's help text rather than hard-limiting the input.

Organization is the second line and the field sponsors care about most. Job title is the third line and is the one to cut first if your badge template is tight.

Make pronouns optional and free text, never a dropdown that misses options.

How should you ask about dietary requirements and accessibility?

Ask them as two separate questions, and only if you can act on the answers. Dietary needs work best as a select list with an "other, please specify" option that reveals a text field. Accessibility works best as one open question, because the useful answers are the ones you did not predict.

Your caterer needs counts by category by a date, not a wall of prose. A select list with vegetarian, vegan, gluten-free, dairy-free, halal, kosher, nut allergy and other gives you that straight from the export.

For accessibility, ask something like: "Is there anything we can do to make the conference work better for you? For example step-free access, a reserved seat near the front, captions, or a quiet room." Route those answers to one named person who replies individually. An unanswered accessibility request is worse than not asking.

Both categories are sensitive. Restrict who can export them, and delete the file after the event rather than leaving it in a shared drive.

How do you let attendees choose sessions or tracks with limited capacity?

If overbooking a room is a real problem, the session must be inventory, not a question. Sell the workshop as its own ticket type or paid add-on with a capacity, so it sells out and disappears. Use a plain select question only when you want a headcount estimate and can move rooms.

A registration question records a preference. It does not stop 180 people picking a room that seats 60, which is how free workshops attached to a paid pass go wrong.

The two mechanisms, and when each fits:

ApproachWhat it doesUse it when
Select question ("Which track?")Records a choice, no limit enforcedTracks run in rooms you can swap, and you want a planning number
Ticket type or add-on with capacitySells out, stops at the limit, shows remaining seatsHands-on workshops, dinners, tours, anything with a hard cap

Add-ons also let you charge. A $75 pre-conference workshop attached to a $499 pass is the cleanest way to raise revenue per attendee, as covered in workshop add-ons and multi-day passes.

From our publisher · Checkout Page

Put your ticket plan into practice

Unlimited ticket types with their own capacity, custom registration fields with conditional logic, and no per-ticket fee.

Try Checkout Page →

Possible checkboxes include acknowledgement of the terms and refund policy, a photo and video notice, a separate unticked marketing opt-in, and a separate choice if you share attendee details with sponsors. The requirements and lawful basis differ by jurisdiction and purpose. Keep distinct choices separate, explain what each covers and have the wording reviewed for the places where you sell tickets.

Sample wording to adapt, not legal advice:

[ ] I accept the ticket terms and the refund policy. (required)
[ ] I understand that photography and filming take place at this event
    and may be used in future marketing. Tell us at the registration
    desk if you prefer not to appear. (required acknowledgement)
[ ] Email me about future events from Example Conference. (optional,
    unticked by default)
[ ] Share my name, organization and email with event sponsors.
    (optional, unticked by default)

Link the refund policy before payment and keep a record of the version the buyer accepted. Clear pre-purchase notice supports informed agreement, but visibility or a checkbox does not by itself make an unlawful or unfair term enforceable.

The sponsor checkbox is the one organizers get wrong. Pre-ticking it, or hiding sharing inside the general terms, is what generates complaints when the first sponsor email lands.

Where do discount codes, invitation codes and invoice details go?

Discount codes belong in the ticketing platform's coupon field at the payment step, never in a custom text question, because only the coupon field changes the price. Invitation-only tiers are better handled with a hidden ticket type behind a private link. Invoice details should be conditional on an "I need an invoice" checkbox.

A custom "promo code" text field is a trap. It records the code, charges full price, and leaves you issuing partial refunds by hand.

For invitation-only tiers such as alumni or past speakers, two patterns work. If your tool supports unlisted ticket types, share one by direct link so the price stays off the public page. Otherwise use a coupon code with a usage limit, which fits when the tier is a discount rather than a separate product.

For buyers who request an invoice, a conditional block can collect legal company name, billing address, tax or VAT number, purchase-order reference and an accounts-payable email. Checkout Page can use Stripe Tax to calculate tax for configured registrations and transaction data, but the organizer remains responsible for deciding where it must register and configuring the tax treatment. Scale can record payments taken manually outside card checkout; that is not the same as an integrated invoicing or bank-transfer workflow.

When should you use conditional logic and multi-step forms?

Use conditional logic whenever a question applies to some attendees and not others, so nobody scrolls past fields that are irrelevant to them. Use multi-step forms once a single screen would show more than about eight fields. Both reduce the perceived length of the form without removing anything you need.

Conditional logic examples that pay for themselves:

  • Show "Which workshop are you attending?" only if the buyer selected a workshop pass.
  • Show a free-text allergy box only if the dietary answer is "other".
  • Show company, billing address and tax ID only if "I need an invoice" is ticked.
  • Show passport name and nationality only if the attendee ticks "I need a visa invitation letter".

A sensible step order to test is ticket selection, attendee details, extras and add-ons, then payment. Do not assume an abandoned form leaves a usable lead: retention and follow-up depend on what the platform records, whether an email was supplied and what contact permission applies. It also keeps multiple ticket tiers on their own screen.

Field-by-field: what to ask and why

The table below lists every field worth considering on a conference registration form, what you actually do with the answer, and whether it should be required. Anything not on this list needs a stronger justification than "it would be interesting to know", and probably belongs in a post-event survey instead.

FieldWhy you need itRequired?
Email addressTicket delivery, receipts, every pre-event emailRequired
First and last nameTicket ownership, check-in search, badge fallbackRequired
Ticket typePrice, access level, capacityRequired
Name as it should appear on the badgeBadge print, avoids all-caps legal namesRequired if you print badges
OrganizationBadge line two, sponsor value, audience mixOptional
Job titleBadge line three, session planningOptional
PronounsBadge line, inclusionOptional, free text
Dietary requirementsCatering counts by a deadlineOnly if you serve food
Accessibility requirementsVenue, seating, captioning arrangementsOptional, open text
Session or workshop choiceRoom sizing, or hard capacity if sold as inventoryConditional on ticket type
How did you hear about usMarketing attribution for next yearOptional, last, single select
Invoice detailsFinance departments and purchase ordersConditional on invoice checkbox
Terms and refund policyRecords acknowledgement of the version shown; enforceability still depends on law and draftingReview locally
Marketing opt-inRecords a choice where consent is the selected legal basisOptional and unticked; review locally
Photo and video noticeRecords notice or consent according to the event's reviewed media policyReview locally
Discount or invitation codeChanges the price at checkoutOptional, platform coupon field
Visa invitation letterTriggers a manual document workflowConditional, international events

Copy the ready-made version from the conference registration form template, then delete the rows you cannot act on. Once the form is live, read the check-in guide to make sure the answers you collected reach the right people on event day.

Frequently asked questions

How many questions should a conference registration form have?
Require only fields that have a named operational or legal purpose. Three required fields plus four to six optional or conditional ones is a planning example, not a completion benchmark. If the form is longer, test a multi-step version on mobile and compare completion and validation errors.
Should I collect attendee names at checkout or after the purchase?
Collect them at checkout when the buyer is likely to know the names. For group bookings placed by an office manager or an assistant, take the order first and send a name-collection link afterwards, with a deadline about two weeks before the badge print run.
Is it legal to ask for dietary requirements and accessibility needs?
The legal basis and required notices depend on your jurisdiction. Ask only when the event can act on the answer, explain why it is collected, restrict access, and set a documented retention period. Dietary and accessibility answers may reveal sensitive information, so have counsel or a privacy lead review the form.
Where should the discount code field go on a registration form?
Use the ticketing platform's built-in coupon field, at the payment step, not a custom text question. A custom question records the code but does not change the price, so you end up issuing manual refunds. On Checkout Page, coupon codes are available on every plan.
Do registration questions slow down check-in?
No, if the answers are on the attendee record rather than on the ticket. Check-in staff scan a QR code and see the attendee's name and answers on screen. Long forms slow down registration, not check-in, which is why every field has to justify itself.
What is the difference between an order question and an attendee question?
An order question is asked once per purchase (billing details, purchase order number, how they heard about you). An attendee question is asked for every ticket in the order (badge name, dietary needs, session choice). Getting the split wrong is the most common cause of missing data on group bookings.

Published by

Checkout Page

Checkout Page builds checkout and event ticketing software. This site covers conference registration through product documentation, fee calculations and practical planning examples.

Published by Checkout Page, one of the platforms covered. Comparisons use public pricing and documentation. Our editorial approach.