Create event registration — professional signup

An event registration without capacity check is a time bomb. As soon as the first viral tweet hits the registration form, three hundred sign-ups for one hundred slots arrive in an hour — and the organizer faces an ugly task. A hard upper limit per slot plus server-side check on submit is mandatory.

Technically that means: on registration submit a database transaction checks "is slot X still free?" and in the same breath "book slot X for this person". Atomically — otherwise race conditions occur where two people book the last seat simultaneously. With multiple workshops inside one event this applies per workshop separately. Conditional logic can show or hide the workshop slot depending on availability so that full slots are not selectable at all.

Capacities should plan a small reserve. For an event with 100 slots, 105 sign-ups are usually safe because typically 5-15 percent no-show rates are expected. For paid events the no-show rate drops to 1-3 percent — calculate tighter here. This reserve should be configurable as a parameter in the calculation engine, not hardcoded.

A waitlist is more than a collection pot — it is an automated workflow. When a confirmed participant cancels, the first on the waitlist must receive an offer within minutes, with a clear deadline to accept (e.g. 12-24 hours). Otherwise waitlist frustration accumulates: ten days waiting, then a mail "you are in" one day before the event — too late, the calendar is full.

The implementation: when capacity is reached the registration form switches to "waitlist". Registrants explicitly accept on entry that they only join in case of cancellations. On a cancellation a webhook automatically triggers a mail to position 1 with a confirmation link and 24-hour deadline. If the waiter does not confirm in time, the offer goes to position 2.

Communicate the waitlist position transparently. "You are currently position 7 of 12 on the waitlist" provides expectation clarity. A weekly status mail to all waiters keeps the list warm. Anyone with no realistic chance (position 50 at an event with 100 slots) should know early — honesty costs you less than an angry tweet chain two days before the event.

An event confirmation without ICS attachment wastes conversion. ICS (iCalendar) is the universal calendar format understood by Apple Calendar, Google Calendar, Outlook and all mobile calendars. One click on the attachment adds the event directly to the calendar — date, time, location, description. Without this single click the event ends up in the mail archive and gets forgotten.

The ICS structure is a text format with clear mandatory fields: UID (unique per event), DTSTART/DTEND (with timezone), SUMMARY (title), LOCATION (address or online URL), DESCRIPTION (details, ideally with a link to the event briefing). Important is the method METHOD:REQUEST — otherwise some mail clients treat the file as a note instead of an invitation.

For online events the LOCATION URL should be a direct link to the meeting tool (Zoom, Google Meet), not a landing page. The participant clicks on the calendar entry on event day and is in. Updates to the event (time change, new location) are communicated via a fresh ICS with METHOD:REQUEST and a higher SEQUENCE number — the calendar overwrites the old entry automatically. This saves you the "please note the change" mail.

A single reminder mail on event day is often not enough — especially not for online events where mental commitment is lower. No-show rates of 30 to 50 percent are normal for free online events, with a good reminder strategy these can be pushed down to 10 to 20 percent.

The typical pattern: 7 days prior a reminder mail with agenda and preparation hints. 1 day prior a second reminder with access link and last-minute info. 1 hour prior a short "in 60 minutes we start". For in-person events additionally 2-3 days prior a note about travel, parking and dress code. Every mail includes the ICS attachment because a single calendar conflict notice can save the appointment.

The reminder sequence can be automated via scheduled webhooks or cron jobs triggering at fixed intervals before the event date. Conditional logic additionally enables personalized reminders: workshop participants get the workshop link, networking-only participants get the lounge area. Anyone not responding to reminders (no mail open, no click) can receive a "can you still come?" confirmation question two days prior — honest answers allow waitlist promotion.

Cancellation must not be a hurdle for the participant. Anyone forced to write a mail to info@... to cancel does not cancel — and then does not show up (no-show). A self-service cancel via personalized link in the confirmation mail is mandatory, ideally with two clicks: open link, confirm cancellation.

For paid events you should have a cancellation deadline (e.g. 7 days before event = 100 percent refund, after that 50 percent, from 24 hours before event no refund). You can show this logic transparently to the participant on the cancellation confirmation — "you receive X euros back, in 5-10 business days". Stripe refunds work via API so the refund can be triggered automatically.

Rebookings (to a different date or workshop) are the more elegant alternative to cancellations when the event offers multiple options. Instead of cancelling the participant gets the option to switch to a free slot in another workshop or a later date. This lifts the customer experience significantly and reduces the cancellation rate. With every rebooking a new ICS with METHOD:REQUEST is sent — the calendar updates automatically.