Group Registration: How One Person Registers a Whole Team Without Knowing Everyone's Details

An executive assistant at a member company registers five people for your annual meeting. She knows the company is sending five. She does not know which five. She knows two of them have dietary restrictions, but not which two. And she is not attending herself. She was handed a card and told to handle it.

Most registration platforms have one answer for this: fill out every field for every person right now, or abandon the cart and come back when you know more. Group registration in Sunfish Events takes a different approach. One transaction can hold several tickets, and each ticket can be completed in whatever way that buyer actually has information for. That includes not yet.

What group registration actually has to solve

The ticket quantity part is easy. Almost every platform can sell five tickets in one checkout. The hard part is the four sets of custom questions attached to those tickets.

Registration forms for corporate events, association meetings, and trade shows are not just name and email. They ask about session choices, meal preferences, badge titles, accessibility needs, and company affiliation. Those answers belong to the attendee, not the person paying. When a platform forces the buyer to answer all of them at checkout, one of three things happens.

The buyer guesses, and you get five badges that say "TBD" and a dietary column full of blanks. The buyer abandons, emails your team instead, and now you are doing data entry for a registration that should have been self-serve. Or the buyer registers five copies of themselves planning to fix the names later, which becomes a support ticket the week of the event.

None of those are the buyer being difficult. They are the natural result of a form demanding information the person filling it out does not have. The fix is not a better form. It is letting the buyer choose, per person, when and by whom each answer gets supplied.

The three ways a spot gets completed

When group registration is on, the buyer sets their ticket quantity and then decides how each of those spots gets filled. There are three options, and a single order can use all three at once.

Fill it out now. The buyer answers that attendee's questions during checkout. On submit, that person is fully registered and receives their own confirmation email. This is the right path when the buyer already knows the details, which is common for the two or three people they work with directly.

Send it to them. The buyer supplies an email address, and optionally a name. The invite email goes out as soon as the order is complete. The invitee clicks the link, sees everything purchased for them already selected, answers the questions the planner set for that ticket, and submits. No login. No payment, because the ticket is already paid for. They get their confirmation email once they finish.

Leave it open. The buyer does not have to name anyone at checkout. The spot is held on the order, and the buyer assigns it later from the attendee portal, at which point the invite email goes out.

A few mechanics are worth knowing before you turn this on.

Once an invitee completes their own registration, that record belongs to them and the buyer can no longer change anything on it. That is deliberate. The person who paid should not be able to quietly edit someone else's accessibility request or session selection.

Attendees can edit their own answers later, but only if you have the attendee portal turned on and that permission enabled. If you want registrations locked after submission, leave it off.

The buyer who is not attending

Group registration includes a checkbox at the start: the buyer indicates they are purchasing on someone else's behalf. It is a small control that fixes a real reporting problem.

If they check it, they are not attending, and no ticket is allocated to them. If they leave it unchecked, one of the tickets in the order is theirs. Either way the buyer exists in your system, in a buyers area separate from your attendee list, so you can reach them about the order. A non-attending buyer does not appear in your attendee metrics.

That separation matters more than it sounds. Assistants, office managers, and association staff book a large share of B2B event registrations, and when a platform cannot tell a payer apart from an attendee, your headcount is wrong from day one. You end up reconciling a list by hand before catering, badge printing, and room setup. For more on what corporate teams should expect from registration software generally, see our conference registration software buyer's guide.

Assigning add-ons to the right person

Selling five tickets and three workshop add-ons is easy. Knowing which three of the five people get the workshops is where most tools fall down.

In Sunfish, add-ons are assigned to specific spots. The buyer does this at checkout or later in the attendee portal, and you can move an add-on to a different attendee from the admin side afterward. A spot with no name attached yet can still carry add-ons, so a buyer who wants three workshop seats but does not know who is filling them can buy three and sort out names later.

Invitees can also buy their own add-ons when they complete their registration. That is a separate order on their own card, so the original buyer is not charged for it. If an add-on has already been purchased for them, they will not be offered it again, so nobody ends up paying twice for the same dinner seat.

Groups versus ticket-level rules

How add-ons attach depends on how you have structured the event.

A group in Sunfish sits one tier above tickets. Tickets, questions, and add-ons all get assigned to a group. When you build an event with groups, an order can only contain one group, and the add-ons in that group are eligible for any ticket in the order. That is the cleaner setup when you have distinct audiences, such as members versus non-members or exhibitors versus attendees, and each audience should see its own tickets, questions, and extras.

If you are not using groups, add-ons are assigned to specific tickets and those rules are enforced when the buyer assigns them. A VIP-only reception cannot land on a general admission spot.

You set maximum quantity at both the ticket and add-on level. There is no separate cap on total order size, so your per-ticket limits are what actually constrain a group order. Set them deliberately. If you do not want one company taking a quarter of the room, that limit is where you say so.

What you see as the planner

On the admin side, each order shows how many tickets were bought and how many spots are still unclaimed. You can see who has claimed a spot and what they answered, and you can assign spots yourself. Once a spot is claimed, you can edit that registration. Two behaviors are worth planning around.

Unclaimed spots hold inventory immediately. If a buyer purchases ten tickets and names nobody, that is ten seats off your capacity and off ticket type availability from the moment they pay. The seats are sold, so this is correct, but your capacity number and your named-attendee count will diverge while registration is open. Read them as two different numbers.

Incomplete registrations are flagged as incomplete. An invitee who never answers the required questions does not get a confirmation email and has not claimed the spot. When you are chasing final headcount, unclaimed spots are your work queue.

Group registration also works on free events. The mechanics are identical, there is simply no payment step, so a free regional meeting gets the same benefit as a paid conference.

Turning it on

Group registration is an event-level setting, off by default, and you turn it on per event. A conference where group buying makes sense and a small executive briefing where it does not can live in the same account without you working around a global setting.

Before you switch it on, walk through a few decisions.

Worth knowing on setup: buyers assign spots one at a time rather than uploading a list. For the five and ten person orders that make up most group registrations, that is a few clicks in the flow they are already in. If you expect delegations of fifty or more, it is worth picturing that before you point them at it.

Where this changes the work

A nonprofit selling gala tables runs into this constantly. A sponsor buys a table of ten in September and has no idea who is sitting at it until the week of the event. Selling the table now and collecting ten sets of meal choices later, directly from the ten people, removes the spreadsheet that usually lives between those moments. Our guide to event registration software for nonprofits and fundraisers covers the rest of that workflow.

Trade show exhibitors have a version of the same problem. A booth gets four staff badges and the exhibiting company does not finalize which four until staffing is set. Selling the badges to the company while collecting names from the individuals means your badge data comes from the people whose names are on the badges.

Association annual meetings are the clearest case. Member organizations send delegations, one person handles the transaction, and the delegates know their own session choices and dietary needs. The buyer handles money, the delegates handle details, and the registration flow should not fight that.

Corporate teams booking an internal offsite usually want the fastest path instead: one coordinator, a known list, everything filled in at checkout. That path is still there. The point is not that every buyer needs flexibility. It is that the buyer decides.

FAQ

Can one buyer use all three completion methods in the same order?

Yes. A buyer can complete two attendees at checkout, send an invite to a third, and leave a fourth spot open, all in one transaction. That is the normal case, not an edge case.

Do invited attendees have to pay or create an account?

No to both. The ticket was paid for in the original transaction, and the invite link opens the registration directly with no login required. The only time an invitee pays anything is if they choose to add an extra add-on for themselves, which is a separate order on their own card.

What happens if one person in a group order cancels?

Canceling and refunding a single attendee inside a multi-ticket order is supported. You do not have to unwind the whole transaction to remove one person.

Key takeaways and next step

Group registration is not really a quantity selector. It is an answer to a timing problem: the person with the credit card and the person with the answers are often not the same person, and rarely ready at the same moment.

The parts that matter:

• One transaction, several tickets, and a per-spot choice between completing now, inviting by email, or leaving it open

• A buying-on-behalf-of checkbox so non-attending purchasers do not distort your headcount

• Add-ons assigned to specific spots, movable by the buyer, the planner, or held on a spot with no name yet

• Group or ticket-level structure to control what a single order can contain

• Unclaimed spots hold capacity from the moment of purchase, and follow-up on them is yours to run

It is an event-level setting, off by default, and you turn it on for the events where group buying is a real pattern. If you are still comparing platforms, our roundup of the best event registration software for small business events covers the wider field.

To see group registration running on your own event structure, book a demo and we will walk through it with your ticket types and questions, or start setting up an event yourself. Setup is same-day, pricing is simple and transaction-based, and there is no multi-year contract to sign before you find out whether it fits.