How do you run registration when the guest list is controlled?

Two kinds of event, one word

Open ticketing. Anyone who pays may attend. The organiser's job is to sell. Payment is the gate, and the tooling for this is excellent and cheap.

Controlled list. Someone decides who may attend. Registration is an application. Sales teams nominate customers, departments submit names, a committee approves, and a rejection has to be delivered without anyone losing face.

Everything below is about the second kind. It is worth naming because organisers of controlled-list events often go looking for “ticketing software,” find tools built for open ticketing, and spend the next six months in spreadsheets covering the gap.

A ticket type is an identity, not a price

This is the single most useful idea on this page.

At a controlled-list event the ticket type — VIP, guest, media, analyst, staff, crew, exhibitor — is not a price band. It is the record that determines:

Lanyard and badge colour

What the volunteer picks up without asking

Materials

Which gift, which bag, or none

Meals

Which restaurant, which sitting

Accommodation

Which hotel, whether a room is held at all

Session access

Which rooms open, which refuse

Script

What the volunteer says while handing it over

Set the ticket type at registration and every one of those follows automatically. Fail to set it, and a person at a desk has to make six decisions with a queue behind them.

Colour is the interface. A volunteer does not need to know the gift policy. They need to know that red gets the VIP set and green gets the small one. Encoding entitlements as a colour is what makes a desk staffed by casual hires run at speed — and it is a decision made in the registration form, months earlier.

The corollary is worth stating plainly: if a new attendee category appears two weeks before the event, it is not a form change. It is a lanyard order, a materials count, a room allocation, an access rule and a line in the volunteer script. Freeze categories early and treat late additions as the expensive thing they are.

Invited guests confirm; they do not fill in forms

If a sales team nominated someone, you already have their name, company, title and email. Asking them to type it again is both rude and slow, and it is where invitations die.

The pattern that works:

Two things make or break it.

Match on two fields, not one. Name alone collides. Name plus email, or name plus phone, is reliable enough in practice and forgiving enough that people get through.

Design the no-match path first, because it will be used more than you expect — the assistant registers on the executive's behalf, someone uses a personal address, the sales team typed the name wrong. A no-match should drop cleanly into a short application form flagged as invited, so approval knows this person was nominated and is not a stranger. What it must never do is dead-end with “we cannot find you.”

Two rounds, not one

Controlled-list events almost always run two waves, and they need different entrances.

Round one — invitation. The pre-loaded list, personal links, confirmation rather than form-filling, and usually no approval step because approval already happened when the name was submitted.

Round two — open application. A public link, a full form, and a real approval queue. These people are strangers to the system and the organiser genuinely has to decide.

Running both through one entrance is the mistake. Either you make invited guests fill in an application form, or you let strangers walk in on the invited path. Two entrances, two forms, two scripts, one attendee list underneath.

Keep the source on the record — which team nominated them, which round, which channel. It costs nothing at registration and it is the only thing that lets you answer “where did our audience come from” afterwards.

Approval is an organisational problem wearing a technical costume

The hard part of approval is never the queue. It is that a human being has to decline another human being, and both of them have colleagues watching.

Three roles, and they should not be the same person:

• Nominate. A sales owner or department submits a name. They know why this person matters.
• Review. Somebody checks the name against the criteria — competitor, capacity, seniority, region quota. This is administrative and can be fast.
• Decide contested cases. A small group, meeting on a schedule, resolving the ones review would not.

What makes this work in practice:

• Publish the criteria before registration opens, even if only internally. An approver without written criteria approves everyone, and you fill the room with the wrong audience.
• Set a decision deadline per application, because a pending registration is functionally a rejection — the guest cannot book travel and eventually stops trying.
• Notify at both ends. Under review, then decided. A silent pipeline generates a phone call for every applicant in it.
• Write the rejection wording once, centrally. Approvers should not each invent one.

And the rule that saves the desk on the day:

A rejected guest is referred to the organiser and told nothing else.

“Your registration was not approved — your contact at the company can tell you more” is the whole script. The volunteer does not know the reason. A volunteer who guesses at a reason turns an administrative decision into a scene.

Some categories skip registration entirely — committee members, volunteers, sponsor staff, supplier crews. Badge them in advance from a list, hand the badges over before the event, and keep them out of the approval queue. They are not applicants.

Registration and payment are different states

At association and academic conferences especially, a meaningful share of people register and do not pay. They intend to. They forget, or they are waiting on a departmental budget, or they registered from their phone and meant to finish later.

Treat these as distinct states from the start, and plan for all three arriving at the desk:

Run a payment lane, separate from check-in. Same reasoning as the enquiry lane: one payment takes several minutes, and a check-in lane cannot absorb that.

Practical shape: a laptop with the attendee list open, so an unpaid registrant is found by name in seconds rather than re-registering; a payment method that works on the guest's own phone; and a volunteer whose whole job is this. Then they rejoin the check-in queue — or better, the payment lane issues the badge too.

On-site registration is a queue you can move upstream. A visible registration code at the entrance, with a person beside it, lets people complete the form while standing in line instead of at the desk.

Discount codes are an attribution tool

At an open-ticketing event, a discount code is a discount. At a controlled-list event, it is mostly a measurement device.

Issue a distinct code per team, region or partner, each with a usage cap. Afterwards you know exactly which team filled which part of the room:

Three things this gives you that a single code cannot.

• Accountability. “Your team was given three hundred seats and brought in a hundred and ninety-eight” is a specific conversation. It is also the number that gets the same team to work harder next year.
• Capacity control. The cap is real. A region that would otherwise fill the room cannot.
• Early warning. A code that is barely used four weeks out is a problem you can still fix. The same information a week out is a post-mortem.

Note the gap between registered and approved in the numbers above. It is normal, it varies by team, and tracking it tells you which teams nominate carefully and which submit lists.

Registration does not end when registration closes

Three things keep happening after the deadline, and each of them shows up as work at the desk.

Substitutions. A director sends a deputy. This is the most common late change at corporate events and it touches everything — badge, materials, room, session access. Decide in advance who may authorise a substitution and route every one of them through that person. What must not happen is a substitution agreed at the check-in desk, because the desk cannot see the room allocation or the session permissions.

Late nominations. Someone important is added four days out. Have a path for it that does not involve editing a spreadsheet: a short internal form, one approver, and an automatic ticket.

On-site registration. However tightly controlled the list, some people will arrive without one. The question is not whether to allow it but who approves it in the room and how fast. Name that person before the event and put them near the enquiry lane.

What you decide online is what happens at the desk

The connection is direct, and it is worth walking once in the other direction.

A guest reaches the desk. The volunteer scans, and the screen says: green lanyard, small gift, no room, sessions 1 and 3, dinner at the second sitting. The volunteer hands over four items and says one sentence. Eighteen seconds.

Every one of those facts was set months earlier in a registration record. If the ticket type was right, the desk is fast. If it was not — if the category was invented late, or the entitlements were never mapped to a colour, or the substitution never made it into the system — the desk becomes the place where all of it gets resolved, one guest at a time, in front of a queue.

The check-in desk is where registration decisions are finally tested. Design them backwards from that moment.

What actually goes wrong

What the data is worth afterwards

Three questions a controlled-list event should be able to answer, and cannot without deciding to capture the answer up front:

• Who filled the room? Registrations by nominating team, and the approval rate for each. This is next year's seat allocation.
• Where did we lose people? Nominated but never registered, registered but never approved, approved but never paid, paid but never arrived. Four drop-off points, and they have four different fixes.
• Did the right people come? Attendance by category against the target mix. A conference that hit its headcount with the wrong seniority mix has failed in a way the headcount conceals.

Attendee data is personal data. Decide before you start how long you keep it, who can export it, and what a sponsor receives — aggregate counts, or names.

Where software actually helps

Four places, and they are worth naming precisely, because they are what to test a system against before you buy one — ours included:

• Pre-loaded lists with confirmation flows. Matching a guest to a record they did not have to type is the single largest completion-rate improvement available in controlled-list registration.
• Approval as a role, not a person. Nomination, review and decision as distinct permissions, with an audit trail of who decided what.
• Ticket type as a carrier. One record holding badge colour, materials, meals, accommodation and session access, so setting the type sets everything downstream.
• Codes with caps and attribution. Per-team codes that both limit and measure.

Everything else here is organisational design — who nominates, who decides, and what you say to the person you turned down. No tool decides that for you.