Here is a situation most organisers have lived through. A company buys eight tickets to your conference. The order has one name and one email — the person who paid. Two weeks before the event you need eight badge names, eight dietary answers and eight session choices, and you are chasing an office manager who has moved on to other things.

The fix is not a better follow-up email. It is asking the right questions, for the right ticket, for each attendee, before anyone reaches the payment page. This post explains how we approached that in Geiger Events and what to look for in any ticketing and payments tool.

Event questions vs. ticket questions

Most registration tools have one set of custom questions per event. Everyone gets asked the same things. That works until ticket types start meaning different things:

• A VIP ticket includes a T-shirt, so you need a size.
• An Exhibitor ticket needs a company and a stand number.
• A Student ticket needs an institution for eligibility.
• A Workshop add-on needs a session choice.

With one shared form, every buyer sees every question with "if applicable" in brackets. With conditional logic you can hide some of them, but only if the form knows which ticket was picked. The cleaner answer is to attach questions to the ticket type itself.

In Geiger Events, questions can be defined on a ticket type, and they are additive: a buyer sees the event's shared questions plus the ones for the ticket they chose. Supported answer types are short text, long text, number, email, a choice list and a checkbox, each optionally required.

Once per attendee, not once per order

The second decision is cardinality. If someone buys three VIP tickets, do you ask for one T-shirt size or three?

Three, obviously — but plenty of checkouts ask once, because the form is attached to the order rather than the seat. Geiger Events repeats the ticket's question set for every seat in the purchase, grouped as "Attendee 1 of 3", "Attendee 2 of 3" and so on. Required questions must be answered for every attendee before the buyer can continue, and the error tells them which question and which attendee they missed.

This is what makes downstream tools work. Badge printing needs one name per badge. The check-in app needs one record per person at the door. Certificates and CEU credits need to know who actually attended, not who paid.

Before payment, not after

The third decision is timing. There are two common approaches:

1. Ask after checkout. Payment first, then a "complete your registration" step or email. Checkout is shorter, but a meaningful share of buyers never come back to finish, and you end up with paid seats and no attendee data.
2. Ask before checkout. Questions are part of the details step, and the buyer only reaches payment once they are answered. Slightly longer checkout, but complete data for every ticket sold.

We chose the second, for both free and paid tickets. The engineering detail that makes it work for paid tickets is worth knowing if you are evaluating tools: answers are saved before the handoff to the payment provider, tagged with a reference, and linked to the registration when the buyer returns from checkout. The answers never have to ride along inside the payment session, so there is no size limit on how much you can ask, and nothing is lost if the buyer takes a while to pay.

Store answers as data, not a blob

The last decision is invisible to attendees but matters a lot to you. Many tools store custom answers as a single block of text or JSON keyed by the question label. Rename "T-shirt size" to "Shirt size" and your old answers are orphaned. Export them and you get one unreadable column.

Geiger Events stores ticket questions in their own table and each answer as its own row, referencing the question by ID, the ticket type, the event and the attendee's seat. Renaming a question does not break anything, and reporting on "how many medium shirts do we need" is a query, not a spreadsheet exercise.

Where conditional logic still fits

Per-ticket questions and conditional logic are complementary, not alternatives:

• Use ticket questions when the question depends on what was bought.
• Use conditional logic when the question depends on another answer — "tell us about the allergy" only after someone selects "Allergy".

We collected six common patterns for the second case in conditional registration form examples.

A checklist for your next event

• List your ticket types and write down what you need to know for each one.
• Move anything that only applies to one ticket off the shared form and onto that ticket.
• Mark as required only what you genuinely cannot run the event without.
• Buy a multi-seat order yourself in test mode and check every attendee is asked.
• Check the answers show up where your team will use them — the attendee CRM, badges and check-in.

Running a conference, an expo or a festival? Per-ticket questions are available on every ticket type in Geiger Events.