Asking your own questions at checkout

Almost every event needs something the standard booking form does not ask. A conference needs job titles for badges, a dinner needs dietary requirements, a workshop needs to know what people already know, and a race needs an emergency contact. Collecting it at the point of sale is dramatically more effective than chasing it afterwards.

Add questions to the event

You can add your own questions to checkout, in several formats:

• Short text — a name, a company, a job title.
• Longer text — accessibility requirements, or anything where a sentence is the honest answer.
• Email — validated as an address, so you do not collect typos.
• A dropdown — one choice from a list you define. T-shirt size, session track, meal option.
• Checkboxes — several answers allowed from a list.

Each question can be required or optional, and can carry placeholder text showing the format you expect. Placeholder text is underrated: "e.g. AB12 3CD" prevents more bad data than any amount of validation, because it tells people what you want before they guess.

Required means required

A required question is enforced when the order is submitted, not merely marked with an asterisk in the interface. The order does not complete without an answer.

That distinction matters when you are collecting something you genuinely cannot run the event without — an emergency contact for a physical activity, a dietary requirement for a plated dinner where the caterer needs numbers a week ahead, an age confirmation for a licensed venue.

Where the answers go

Answers are stored against the booking and appear with the order, so they are visible where you are already looking rather than in a separate system you have to remember to check.

They also come out in your attendee export, which is usually how they actually reach the person who needs them — a CSV to the caterer, a spreadsheet to the badge printer, a filtered list to whoever is running the accessible entrance. That export is the reason to collect answers here rather than in a separate form: the answers arrive already attached to the right attendee, with no reconciliation step where you match a survey response to a booking by email address and find that 15% do not match.

Asking well

The quality of what you get back depends almost entirely on how you ask.

• Every question costs you conversions. A checkout form is a series of chances to reconsider. This is the real budget you are spending, and it is why "while we have them, let's also ask..." is expensive.
• Use a dropdown when the answers are known. "Small / Medium / Large" gives you countable data; a free-text size field gives you "M", "medium", "Medium?" and "whatever fits".
• Make it optional unless you will act on it. Required fields for information you will never look at generate resentment and false answers.
• Ask per attendee, not per order, when it is per attendee. One dietary requirement on a booking for six is a problem for the caterer and probably for somebody at the table.

A word on what you ask for

Every question is personal data you now hold, and under GDPR that is a commitment rather than a free text field. You need a reason to collect it, you need to keep it only as long as that reason lasts, and you need to be able to produce or delete it if the person asks.

Dietary requirements and accessibility needs deserve particular care: they are health-adjacent data, they are unusually sensitive, and they belong with the caterer and the access team rather than in a general attendee list circulated to volunteers.

The practical filter is simple. Ask for what you will actually use, this year, for this event. "Nice to know" columns are the ones that turn into a data-retention problem two years later, when nobody remembers why the field exists and nobody wants to be the one who deletes it.