Group Registration Form

Group registration breaks the usual shape of a form. One person fills it out, but the questions are about other people, and the answers repeat. Trying to handle that with a standard registration form is what leads to five separate submissions paid on five different cards and a roster nobody can reconcile.

How the form is structured

Three parts. The organizer answers for themselves once. Then they choose a number of seats, and the attendee questions repeat once per seat, because the seat item carries a per unit sub form. Checkout is cart based, so payment happens once at the end through Stripe rather than as questions on the form.

Group pricing is handled by conditional logic rather than a fixed price list. Rules watch the seat count and set the per seat price directly, so the rate falls as the roster grows without anybody needing to know a code. A promo code can drive the same thing if you would rather control it that way.

Who it is for

Associations selling team rates to member organizations, corporate training teams enrolling a department, conferences with a table or delegation model, and any event where one purchase covers several seats.

How to adapt it

Decide two things before building: where your price bands sit, and whether every name is required at the point of purchase. Everything else follows. If you want attendees to pay for themselves, this is the wrong template. Use the standard event registration form and let each person register individually.

Setup checklist

1. Price the seat, not the group. The cart holds a single Attendee Seat item. The organizer chooses a quantity and the attendee questions repeat once per seat, because the item carries a per unit sub form. Checkout is cart based, so payment is collected by Stripe at the end rather than as questions on the form.
2. Discount with conditional logic. The template ships with two rules that watch the seat count and set the per seat price directly, one band for five to nine seats and one for ten or more. Keep the bands mutually exclusive. Two rules that can both pass on the same item at once will fight over the price, and the winner is not guaranteed.
3. Or discount with a promo code. A code can be applied by a rule instead of by the registrant typing it. Note that promo codes cannot travel inside a template, so the code itself has to be created on the form after import, and the rule that applies it will do nothing until it exists.
4. Decide whether names are mandatory. The sub form is set to required, so every seat needs a name and email before checkout. If organizers routinely buy seats before they know who is coming, turn that off and chase the names later.
5. Cap the group if the room does. Put a quantity cap on the seat item so a group cannot buy more seats than you have.
6. Decide about attendee emails. Each seat collects its own email, so every attendee can get their own confirmation while the organizer gets the summary. That surfaces typos while there is still time to fix them.
7. Plan the roster edit path. Names change between registration and the event. The edit link in the confirmation lets the organizer swap them up to a deadline you set, which beats retyping names by hand the week of the event.

Before you publish

Buy four seats and confirm the full price applies, then six, then twelve, and check the per seat price changes at each band. Pricing rules are re-checked server side at checkout, so what you see in the form should match what is charged. Finally confirm the export gives you one row per attendee rather than one row per group.