What this automation does
From the moment someone registers until the day after the event, every step happens from one attendee record, and organizers handle exceptions instead of spreadsheets.
- Register. An attendee fills in a Typeform or Jotform form with ticket type, session choices and free-text requests. Paid tickets go through a Stripe Checkout page.
- Reserve the seat. On payment success (or form submit for free events), the workflow claims a seat with an atomic capacity check. If the event or session is full, the person goes on the waitlist and any payment is not captured or is refunded.
- Confirm. A confirmation email goes out with a calendar invite in the attendee’s time zone, a unique check-in code, and a link to manage or cancel the booking.
- Sort requests. A model reads dietary, accessibility and other free-text fields and maps them to categories the venue and organizers use. Anything unusual is flagged to a person.
- Sync. The registrant is created or updated in HubSpot with the event, ticket type and source, so marketing and sales see it.
- Remind and promote. Reminders go out on a schedule by email and, with consent, by SMS. Cancellations release seats and automatically offer them to the next person on the waitlist with a time limit to accept.
- Check in and wrap up. Staff scan codes at the door. After the event, attendees and no-shows are tagged in the CRM, ready for the same kind of segmented follow-up used for webinars.
When it is worth building
Build when events are a repeating part of the business, such as monthly trainings, member workshops or a recurring conference, and the team spends days per event reconciling form exports, payments and waitlists. It is also worth it when an off-the-shelf platform forces you into workarounds, like approving registrants by hand, member-only pricing, or splitting one payment across several attendees.
If you run two or three events a year with simple ticketing, buy an event platform and connect it to your CRM with its built-in integration. A custom workflow adds maintenance and it should only replace a platform when the custom rules are worth that cost.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Registration form | Typeform or Jotform | Conditional questions for sessions and requests without a custom front end |
| Payments | Stripe Checkout and webhooks | Handles cards, receipts and refunds; webhooks drive the workflow |
| Attendee database | Airtable for small events, Postgres for larger or concurrent ones | Single source of truth for seats, waitlist and check-in status |
| Orchestration | n8n | Built-in Typeform, Jotform, Stripe, Airtable, HubSpot, Gmail and Twilio nodes |
| Request sorting | Claude Haiku 5.5 with a fixed category list | Free text to structured categories at low cost |
| Messaging | Gmail or your email platform, Twilio for SMS | Confirmations, reminders and waitlist offers |
| Check-in | A small web page reading the attendee database | Works on any phone, no app install for staff |
How to build it
- Model the data first. Events, sessions, ticket types, registrations, attendees (one registration can cover several people), waitlist entries and check-ins. Decide which fields are required for the venue.
- Pick the capacity authority. For low concurrency, Airtable with a locking step works. For popular events that sell out quickly, use Postgres with a transaction, or a ticketing platform that enforces capacity itself.
- Wire the form and payment. Pass a registration ID from the form into Stripe Checkout metadata so the payment webhook can find the right record.
- Build confirmations. Generate a calendar file with an explicit time zone and the venue address, a unique check-in code, and a manage-booking link.
- Add request sorting. Give the model your category list (for example vegetarian, vegan, gluten free, nut allergy, wheelchair access, interpreter) and require it to flag severe allergies and anything outside the list for a person.
- Build the waitlist logic. Cancellation releases a seat, the next person gets an offer with an expiry, and an unclaimed offer moves to the next person.
- Build check-in and the post-event sync. A phone-friendly page for staff, and a job after the event that marks attended and no-show in the CRM.
What breaks in production
- Race conditions at launch. A popular event opens and two registrations claim the last seat. Without an atomic check you oversell, and the fix is an awkward phone call.
- Abandoned checkouts. People start payment and never finish, holding a seat. Release held seats after a short timeout.
- Group registrations. One buyer registers four colleagues with one email. Capture each attendee’s name and email separately or check-in and follow-up break.
- Calendar invite time zones. Invites without an explicit zone show the wrong time for out-of-town attendees. Always include the zone.
- Missed allergy notes. Free-text fields like “no nuts please, severe” must never be dropped by a category mapping. Flag anything that mentions severity for a human, and send the venue a final list.
Timeline and cost
A build with one form, Stripe, an attendee database with capacity and waitlist, confirmations, reminders, CRM sync and a check-in page usually takes two to three weeks. Lumeor builds this in the range of $5,000 to $12,000, depending on ticket complexity, multi-session tracks, the capacity approach and how much SMS is involved. Running costs are payment processing fees, SMS fees and hosting, all billed by those providers; model usage is minor. If registrations mainly need to land in a database, start with form submissions to a database and grow from there. For help scoping, start here.
How to measure success
- Staff hours per event spent on registration admin
- Oversold or double-booked seats, target zero
- Share of waitlist offers accepted before expiry
- Registration-to-attendance rate, and how it changes with reminders
- Free-text requests that reached the venue correctly