Event Registration and Check-In

An event has one unforgiving characteristic: it happens at a fixed moment, and everything either worked by then or did not. That makes the usual tolerances disappear. A registration page that loses people at payment, a confirmation email that does not arrive, a reminder that never goes out, a door queue that takes eleven minutes to clear - none of these can be fixed next week, because next week the event is over and the only thing left is the feedback.

Most events are run across four or five disconnected tools and one very tired spreadsheet. Registrations arrive on a form, payments sit in a payment processor, the attendee list lives in a download that was accurate on Tuesday, dietary requirements are in a reply-all email thread, session choices are in a second form half the attendees never saw, and the check-in list is printed on the morning and marked with a pen. Each handoff loses something. The person who paid but whose name was spelled wrong at the door. The vegetarian count that was right at the time of the catering order and wrong by the day. The forty people who registered and never came, whose empty seats were promised to a waitlist nobody contacted.

Three leaks matter most. First, unpaid and abandoned registrations: people who got as far as the form and were never brought back, which on a paid event is the single largest recoverable loss. Second, no-shows, which on a free event routinely run high and which are only partly inevitable - a reminder ladder and an active reconfirmation step move that number, and a waitlist turns released places into attendance. Third, the door, where a slow check-in costs you the first session's atmosphere, the sponsor's impression of the crowd, and any chance of knowing in real time who actually came. A system that holds registration, payment, ticketing, reminders and check-in in one place closes all three and leaves you with something better than a tidy event: an accurate record of who attended what, which is the asset the next event is built from.

Pipeline and stages

One pipeline, Event Registrations, with event_id as a field so a single board carries every event you run and the same attendee's history follows them across all of them.

• Interested - started the registration or asked a question. No place held.
• Registered - Unpaid - form complete, payment outstanding. Carries a hold expiry on paid events.
• Registered - Paid - payment cleared, or a free event registration completed.
• Ticket Issued - unique code generated and delivered. This is the stage that makes the door work.
• Details Complete - session choices, dietary and accessibility needs captured.
• Reconfirmed - actively re-affirmed inside the final week. The number you give to catering and to your sponsors.
• Checked In - scanned or found at the door.
• Attended - set at close of event, with session attendance where you track it.
• No-Show - ticket issued, never scanned.
• Canceled and Transferred - split, because a transfer keeps the place filled and a cancellation releases it.
• Waitlist - event or ticket type full. Ordered, with a position.

Calendars and capacity

• Event capacity per event and per ticket type, enforced centrally so no channel can oversell. Hard cap plus a configurable overbooking allowance if your venue and your nerve permit one.
• Session capacity for breakouts, workshops and tracks, each with its own limit, so a 40-seat workshop cannot take 120 choices.
• Ticket windows - early, standard and final release windows opening and closing on dates, with the window name written to the record.
• Speaker and sponsor slots - a separate calendar for rehearsals, sound checks, sponsor set-up and briefing calls.
• Door shifts - a staff calendar for check-in desk coverage, with named people per shift, because an unstaffed desk at 08:40 is the whole build wasted.

Custom fields

• event_id, event_name, event_datetime, event_venue
• ticket_type - General, Concession, Member, Group, VIP, Speaker, Sponsor, Staff, Press, Complimentary
• ticket_window - Early, Standard, Final, On Door
• ticket_quantity and group_lead_contact for multi-place bookings
• registration_code - the unique check-in code behind the QR
• payment_status - Not Required, Pending, Paid, Refunded, Partially Refunded, Failed
• payment_hold_expiry - when an unpaid place is released
• badge_name - what the attendee wants on the badge, which is not always their legal name
• attendee_company and attendee_role - the two fields sponsors actually care about
• session_choices - multi-select against your session list
• dietary_notes, allergy_flag, accessibility_needs
• consent_marketing and consent_photography - separate switches, separately captured
• reconfirmed_at
• checkin_time, checkin_method (Scan, Name Search, On Door), checkin_by
• sessions_attended - where you scan at session doors
• transfer_from and transfer_to
• waitlist_position
• no_show_count - lifetime, across events, on the contact record
• source_channel and referral_code - who sent them, measured per channel and per speaker or sponsor
• survey_score and survey_comment

Tags

• reg-unpaid, reg-paid, ticket-issued, reg-reconfirmed
• checked-in, event-no-show, attended
• ticket-vip, ticket-speaker, ticket-sponsor, ticket-staff, ticket-press
• group-lead, group-member
• allergy-present, accessibility-need
• photo-opt-out - must be visible to your photographer and on the badge design
• waitlist-active, waitlist-offered
• session- tags, one per session, for door scanning and for post-event content delivery
• repeat-attendee, first-time-attendee
• sms-opt-out - global suppression, checked before every SMS step

Forms

• Registration Form - on the event funnel. Name, badge_name, email, mobile, company, role, ticket type, quantity. Six to eight fields and nothing else. Session choices and dietary needs come later; asking for them up front is how you lose a third of your registrations.
• Group Registration - a lead books several places and supplies the other attendees' names and emails, each of which becomes its own record with its own ticket and its own reminders. Group members who never receive their own ticket are your highest-risk no-shows.
• Session Selection - released after payment, showing live remaining capacity per session so an attendee cannot pick a full workshop.
• Dietary and Accessibility - short, separate, and sent to everyone, with a clear note on who sees the answers.
• Transfer Request - name change on an existing ticket, which keeps the seat filled and is almost always better than a refund.
• On-Door Registration - a two-field walk-up form a door volunteer can complete on a phone in 20 seconds.
• Post-Event Survey - four questions, one score, one open line, sent same day.
• Speaker and Sponsor Logistics - a separate form capturing arrival time, equipment needs, slide deadline and stand requirements.

BO's role and guardrails

• BO answers the event FAQ from an approved event brief: date, times, venue and travel, parking, what is included, dress code, accessibility, whether tickets are transferable, where the agenda lives.
• BO resends lost tickets on request, after verifying the email or mobile on the record, and nowhere else.
• BO handles name changes through the Transfer Request flow and reissues the ticket with a new registration_code, voiding the old one.
• BO takes session-change requests and applies them where capacity allows, and offers alternatives where it does not.
• BO never issues a refund, never waives a fee, never quotes a price not on the published page, and never creates a complimentary ticket. All four route to the event owner.
• BO never confirms that any food is safe for an allergy. A declared allergy sets allergy_flag, applies allergy-present, and creates a task for the event manager to resolve with the caterer and reply in writing.
• BO does not override capacity, does not issue a ticket for a sold-out type, and offers the waitlist instead.
• BO messages attendees between 08:00 and 20:00 in the attendee's own time zone, with the single exception of day-of operational messages inside your stated event window.

Numbers and channels

• One dedicated event number for SMS, registered, named in the first message of every thread, and monitored live on the day by a named person - on event morning, inbound texts are your most important channel.
• An event funnel under your own domain: landing page, registration form, payment step, and a confirmation page that repeats the detail rather than just saying thank you.
• Confirmation email carrying the QR ticket, a calendar attachment, the venue address and a one-tap transfer link.
• Check-in surface - a mobile web page for door staff that scans the QR, marks arrival, shows badge_name, ticket_type and any allergy-present or accessibility-need flag, and falls back to name search when a code will not scan. Build a printed list as the offline fallback; venue wifi fails more often than anyone plans for.
• Internal: an event channel in Slack or your team chat receiving live check-in counts, every allergy flag, every failed payment, and the waitlist state.

One attendee at a paid one-day conference, from the first click to the follow-up.

1. She sees the event on LinkedIn and lands on the event funnel. referral_code in the URL records the speaker who shared it. She completes the Registration Form - seven fields - selecting a Standard ticket, and continues to payment.
2. Her card is declined. The record is created in Registered - Unpaid with payment_status Failed, reg-unpaid applied, and payment_hold_expiry set 48 hours out. Without this step she would simply be lost, which is what happens at most events.
3. Twenty minutes later the recovery message arrives: Your place at [event] is held until [date and time] - the payment did not go through, which is usually the card rather than you. Finish it here and your ticket sends straight away: [link]. She pays that evening on a different card.
4. payment_status becomes Paid, stage moves to Registered - Paid, then straight to Ticket Issued. A registration_code is generated, and the confirmation email arrives within a minute with the QR ticket, a calendar attachment, the venue address with travel notes, and the transfer link. An SMS follows with the ticket link only, because people lose emails and not texts.
5. Immediately after, the Session Selection form is released, showing live remaining seats. She picks two of the three breakouts; the third is already full and shows as such rather than failing after submission. session_choices is written and two session- tags are applied.
6. The Dietary and Accessibility form follows. She declares a severe shellfish allergy. allergy_flag is set, allergy-present applied, the event channel is notified with her exact wording, and a task is created for the event manager to resolve with the caterer and reply in writing - which they do, two days later, naming the dishes. The reply is logged on her record.
7. Stage moves to Details Complete. Then the system goes quiet for three weeks, which is the correct behavior.
8. Seven days before: the agenda email. Her two chosen sessions, the room numbers, the start time, who else is speaking, and the travel detail. One link to change a session if she wants to.
9. Three days before: the reconfirmation. Two buttons - coming, or cannot make it. She taps coming. reconfirmed_at is stamped, stage moves to Reconfirmed, and she joins the number given to catering the next morning.
10. Two days before, the final headcount runs: reconfirmed total, dietary breakdown, allergy list, session-by-session numbers. It goes to the caterer, the venue and the session leads as one document. This is the moment the build earns its keep, because the numbers are real.
11. The day before, 17:00: the what-to-expect message. Doors open 08:30, first session 09:15, the QR ticket link again, the nearest parking lot, and the event number to text if anything goes wrong.
12. Event morning, 07:45: door staff open the check-in page on their phones. The printed fallback list is on the desk. The event channel starts receiving a live check-in count every 15 minutes.
13. 08:41 she arrives. The volunteer scans her QR in about two seconds. The screen shows her badge_name, Standard ticket, and a red allergy flag; the volunteer points her to the catering lead as the briefing says to. checkin_time, checkin_method Scan and checkin_by are written. Stage moves to Checked In, checked-in applied.
14. 09:05: the event owner sees 212 checked in against 268 reconfirmed in the event channel, which is actionable - the back rows get closed and the room feels full rather than half-empty.
15. 09:20: the no-show sweep runs against anyone not checked in. Each gets one message: Doors are open and your seat is still here - first session has just started, come straight in and skip the desk: [ticket link]. Eleven people arrive late because of it.
16. Breakout doors are scanned too, so sessions_attended is populated. At 17:30 the event closes and every checked-in record moves to Attended; anyone never scanned moves to No-Show with no_show_count incremented.
17. 19:00 the same day: the Post-Event Survey. Four questions. She scores 9 and names one session as the best. Two days later she receives the slides and recordings for exactly the sessions she attended, not all of them.
18. Ten days later, with consent_marketing on, she gets the next-event announcement with an attendee-priority window before public release. Her record now carries attended status, two sessions, a company, a role, a survey score and a referral source - which is how the next event is planned rather than guessed.

Eight workflows. Every message step checks sms-opt-out and falls back to email, because a ticket is information the attendee needs in order to get through the door.

1. Registration Intake, Payment and Ticket Issue

Trigger: a Registration Form submission on the event funnel, a Group Registration submission, or a registration taken by BO.

Conditions and branches:

• Check capacity for the requested ticket_type. If full, do not create a registration: route to workflow 3 and offer the waitlist.
• Check the ticket window against today's date and write ticket_window. A request for a closed window is offered the current one, never the closed one.
• Match email and mobile against existing contacts. On a match, apply repeat-attendee, carry dietary_notes, accessibility_needs and badge_name forward, and skip asking again. Otherwise apply first-time-attendee.
• If ticket_quantity is above 1, create one child record per named attendee with its own registration_code, link them to group_lead_contact, and apply group-lead and group-member. Every attendee gets their own ticket and their own reminders. A group of eight managed as one record will produce eight people at the door with one QR code between them.

Actions in order:

• Free event: set payment_status Not Required and move straight to Registered - Paid.
• Paid event: create in Registered - Unpaid, apply reg-unpaid, set payment_hold_expiry to 48 hours out (or 4 hours if the event is inside 7 days), and send to the Stripe payment step.
• On payment success webhook: set payment_status Paid, swap reg-unpaid for reg-paid, move to Registered - Paid.
• Generate a unique registration_code, move to Ticket Issued, apply ticket-issued.
• Within 1 minute: confirmation email with the QR ticket, calendar attachment, venue address and travel note, running order, transfer link, and your refund terms quoted verbatim.
• Within 1 minute: SMS with the ticket link alone. [Event] - you are in. Ticket and QR here: [link]. [Date], doors [time], [venue]. Save this message; it is all you need at the door.
• Immediately after: release the Session Selection form, then the Dietary and Accessibility form.
• If ticket_type is Speaker, Sponsor or Press, suppress the standard sequence and send the Speaker and Sponsor Logistics form instead, with its own deadlines.
• Write source_channel and referral_code from the URL, and post one line to the event channel.

Exit: ticket issued, waitlisted, or hold expired.

2. Unpaid and Abandoned Registration Recovery

Trigger: record sits in Registered - Unpaid, or a Stripe payment failure webhook arrives, or the registration form is submitted but the payment step is never reached.

Conditions: runs only while payment_status is Pending or Failed, and stops the instant payment clears.

Actions in order:

• 20 minutes after: first recovery email and SMS. Your place at [event] is held until [expiry date and time]. The payment did not complete - usually the card rather than you. Finish here and your ticket sends straight away: [link].
• Wait 12 hours: second message, adding the one genuine reason to act now - the ticket window closing, or the remaining places if the number is real. Never invent scarcity.
• Wait 12 hours (24 hours in): third message, offering help rather than pressure. Still holding your place. If the payment page is the problem, reply to this and a person will sort it manually.
• At 4 hours before payment_hold_expiry: final notice naming the exact release time.
• At payment_hold_expiry: release the place to capacity, move to Canceled, and fire workflow 3 to offer the place to the waitlist. Send one clean message: We have released your held place at [event]. If you still want to come, here is live availability: [link].
• If the event sells out while a record is unpaid: shorten the remaining hold to 4 hours and say so plainly in the message.
• On three recovery attempts with no payment, create a task for the event owner only if ticket_type is Group or VIP. Everyone else exits silently.

Exit: payment clears, place released, or the attendee cancels.

3. Capacity, Waitlist and Release

Trigger A: a registration attempt against a full event or ticket_type.

• Create the record in Waitlist, apply waitlist-active, assign waitlist_position in submission order, and tell the attendee their position honestly. [Event] is full. You are number [n] on the waitlist - places do come back, usually in the last two weeks. I will message you the moment one does, and you will have 12 hours to take it.

Trigger B: a place is released by a cancellation, an expired unpaid hold, or a capacity increase.

• Query waitlist-active for the matching event and ticket_type, ordered by waitlist_position.
• Offer to the first person only, with a 12-hour expiry, apply waitlist-offered. A single-person offer is fairer than a scramble and produces fewer complaints than a first-come link on a waitlist people joined weeks ago.
• Wait 12 hours. Not taken: remove waitlist-offered, move to the next position, and repeat. Inside 72 hours of the event, shorten the expiry to 3 hours and offer to the next three simultaneously, since time now matters more than order.
• On acceptance: run workflow 1 from the payment step, preserving the original waitlist join date on the record so you can measure the channel.
• Inside 24 hours of the event with places still unsold: notify the event owner with the count and a one-click option to open on-door sales.

Trigger C: scheduled, daily. Recalculate remaining capacity per ticket_type and per session, update the funnel's displayed availability, and close a ticket type automatically when it fills. Alert the event owner at 80 and 95 per cent of capacity.

Exit: event starts, or the waitlist empties.

4. Details Capture and Session Selection

Trigger: stage reaches Ticket Issued.

Actions in order:

• Immediately: send Session Selection with live remaining capacity shown per session. On submission, write session_choices, apply one session- tag per choice, and decrement session capacity.
• If a chosen session fills between the form loading and submission: accept the rest, flag the clash, and offer the two nearest alternatives rather than silently dropping the choice.
• Wait 3 days. No session selection: one reminder. Wait 4 days: second reminder. After that, assign nothing - an unassigned attendee is a problem for the room count, so instead flag them on the final headcount as unallocated and let a human decide.
• 24 hours after ticket issue: send Dietary and Accessibility, stating plainly who sees the answers.
• On allergy declared: set allergy_flag, apply allergy-present, post the attendee's exact words to the event channel, and create a task for the event manager due in 24 hours to confirm with the caterer and reply in writing. Escalate at 24 hours and again at 48. Log the written reply on the record.
• On accessibility need declared: notify the event manager and the venue contact, create a task to confirm the specific arrangement, and reply to the attendee naming the person who will meet them.
• On consent_photography declined: apply photo-opt-out, flag it on the badge record, and include the list in the photographer's brief.
• When session, dietary and accessibility answers are all in, move to Details Complete.

Exit: details complete, or the event begins.

5. Pre-Event Reminder Ladder and Reconfirmation

Trigger: scheduled, counting backwards from event_datetime, on every record in Ticket Issued or later.

Actions in order:

• 14 days before: the agenda announcement - speakers confirmed, running order, and anything newly added. No ask attached.
• 7 days before: the personalized agenda. The attendee's own sessions, room numbers, start time, and one link to change a session. Attach the ticket again.
• 3 days before: the reconfirmation, two buttons only. [Event] on [day]. Still coming? Tap YES. Cannot make it? Tap here - someone on the waitlist would love your place and there is no awkwardness in it.
• On YES: stamp reconfirmed_at, apply reg-reconfirmed, move to Reconfirmed, stop reminding.
• On cannot make it: offer the Transfer Request flow first and the cancellation second. A transfer keeps your headcount, and most people would rather send a colleague than lose the ticket.
• 2 days before, as a scheduled run: compile and send the final headcount to the caterer, the venue and each session lead - reconfirmed total, unreconfirmed total, dietary breakdown by type, the allergy list with names, accessibility arrangements, and per-session numbers. One document, one send, from real data.
• 2 days before, per record: anyone not reconfirmed gets one SMS. Anyone still unreconfirmed with ticket_type VIP, Speaker, Sponsor or Group gets a task for a human to call.
• 1 day before, 17:00: the logistics message. Doors, first session, address, travel and parking, the ticket link, and the event number to text. Keep it short enough to read on a platform.
• Event morning, 2 hours before doors: the final message - ticket link, doors time, and the one thing that most often goes wrong at your venue, named explicitly.

Exit: event begins, canceled, or transferred.

6. Door Check-In and Live Count

Trigger: a scan or a name-search check-in on the door page, from the moment doors open.

Actions in order:

• Validate registration_code. Valid and unused: stamp checkin_time, checkin_method and checkin_by, move to Checked In, apply checked-in, and return the door screen - badge_name in large type, ticket_type, session choices, and any allergy-present, accessibility-need or photo-opt-out flag.
• Code already used: do not reject the person. Show the original checkin_time and who scanned it, and prompt the volunteer to call the door lead. Duplicate scans are almost always a shared group ticket or a double tap, not fraud.
• Code not found: fall back to name search across the event. Found and unpaid: flag to the door lead for a decision, never refuse automatically. Not found at all: route to workflow 7 for on-door registration.
• Session doors: scan again at each session entrance, write to sessions_attended, and alert the session lead when a room reaches capacity.
• Every 15 minutes: post the live count to the event channel - checked in, against reconfirmed, against tickets issued, plus the last 15 minutes' arrival rate so the door lead can see whether the queue is building or clearing.
• 30 minutes after doors, and again 60 minutes after the first session starts: run the late-arrival nudge against every reg-reconfirmed record with no check-in. Doors are open and your seat is still here - come straight in, the desk can wait: [ticket link]. This single message recovers more attendance than any pre-event reminder.
• At event close: move every checked-in record to Attended. Move every ticket-issued record with no check-in to No-Show, apply event-no-show, and increment no_show_count on the contact.

Exit: event closes. Keep the offline fallback list live until it does.

7. On-Door Registration, Transfers and Refunds

Trigger A - walk-up: On-Door Registration form submitted by a door volunteer.

• Check remaining capacity. Full: record as an inquiry, add to the waitlist for the next event, and tell them honestly.
• Capacity available: create the record with ticket_window On Door, take payment at the desk through Stripe where the event is paid, generate registration_code, check them in immediately in one step, and send the ticket to their phone so they have it for session doors.
• Capture email, mobile, badge_name, company and consents. A walk-up attendee with no email captured is an attendee you cannot invite next time, which is the whole point of the record.

Trigger B - transfer: Transfer Request submitted.

• Check the transfer cut-off date in your policy. Past it: route to the event owner rather than refusing automatically.
• Within it: void the old registration_code, create the new attendee record with transfer_from populated, generate a new code, and issue the new ticket within 5 minutes. Move the original record to Transferred.
• Send the new attendee the full sequence from the current point in the ladder - session selection if seats remain, dietary form, and whichever reminders are still ahead of them.
• Notify both parties in one line each so neither is left wondering.

Trigger C - cancellation or refund request:

• BO acknowledges and collects the reason, then stops. No refund is ever issued by automation. Create a task for the event owner with the request, the date, the policy position and the payment reference.
• Before the task is actioned, offer the transfer alternative once: Before we refund - would sending a colleague work? A name change takes two minutes and keeps your place: [link].
• On the owner approving, process the refund in Stripe, set payment_status Refunded, move to Canceled, release the place, and fire workflow 3.

Exit: resolved by a human in every refund case.

8. Post-Event Survey, Content Delivery and Next-Event Pipeline

Trigger: event marked closed.

Actions in order:

• Same day, 2 hours after close: send the Post-Event Survey to every attended record. Four questions: one score, best session, one thing to change, and would you come again. Same-day response rates run far above next-week ones.
• Score 9 or 10: thank them and send one review or testimonial request, with a single link. Tag them for the next event's early-access list.
• Score 6 or below: no review request. Post to the event channel and create a task for the event owner to make personal contact within 48 hours. Log the outcome.
• Wait 2 days: deliver slides and recordings by session- tag, so each attendee receives the content for the sessions they actually attended plus a link to everything else. Specificity is what gets this email opened.
• No-show branch, next morning: one message, written without reproach. Sorry we missed you yesterday. Here are the slides and the recordings anyway - you paid for them, or you meant to come, and either way they are yours: [link]. Capture any reason given. A no-show treated well registers again; a no-show ignored does not.
• Wait 10 days: if consent_marketing is on, send the next-event announcement to attended records with a priority window before public release, and set a reminder for when that window closes.
• Speaker and sponsor branch: within 3 working days, send each sponsor the agreed lead list containing only the fields attendees consented to share, plus attendance numbers and session-level counts. Create a task for a debrief call inside two weeks, while the event is still fresh enough to renew on.
• Wait 5 working days: compile the event report for the owner - registrations by channel and referral code, payment completion and recovery, show-up rate by ticket type and by reconfirmation state, check-in throughput and scan success, session attendance against choices, waitlist conversion, transfer and refund counts, dietary accuracy, survey scores and themes, and repeat-attendance rate. Keep it against event_id so the next event can be planned from it rather than from memory.

Exit: report delivered and the attendee list segmented for the next event. The record persists - that list is the asset.

The headcount becomes true. Before this build, the number you give the caterer is a registration count with a guess subtracted; afterwards it is a reconfirmed count with a known dietary breakdown, and the difference shows up directly in waste and in the number of people standing at the back. The door changes too: two seconds per attendee instead of a name hunt down a printed list, and a live count the event owner can act on while the room is still filling.

The less obvious change is that the event stops being an isolated effort. Every attendee record carries ticket type, sessions attended, dietary needs, survey score and referral source, and it persists. The second event starts with a list of people who came to the first one, segmented by what they actually sat in, with an attendee-priority window you can offer them. Over three or four events this becomes the cheapest acquisition channel you have, and it only exists if the data was captured cleanly at the door.

What to measure

• Registration conversion - funnel visits to completed registrations, and the step people abandon on.
• Payment completion rate and unpaid recovery rate - how many failed or abandoned payments the recovery sequence brings back. On a paid event this is usually the highest-return number in the build.
• Show-up rate - checked in as a share of tickets issued, split by ticket type, by paid versus free, and by reconfirmed versus not. The reconfirmed split is the one that tells you whether the ladder works.
• Reconfirmation rate and how it moves your catering accuracy.
• Check-in throughput - median seconds per attendee, and the longest queue length. Watch the first 30 minutes separately from the rest.
• Scan success rate versus name-search fallback. A high fallback rate means your ticket delivery is failing somewhere.
• Session attendance versus session choices - the gap tells you which sessions were oversold by their own description.
• Waitlist conversion - offers made, places taken, and median time to fill a released place.
• Transfer rate - transfers are good news, since a transferred ticket is an attended seat.
• Dietary accuracy - declared special meals against meals actually served.
• Source and referral performance - registrations and attendance per channel, per speaker and per sponsor code, which is what lets you pay for distribution next time.
• Survey score and response rate, plus the free-text themes.
• Repeat attendance across events, and registrations coming from your own attendee list rather than from paid promotion.

Prerequisites

• Final capacity numbers per event, per ticket type and per session, agreed with the venue and written down. Everything in the build enforces these, and a session cap entered optimistically will produce a workshop with people standing in the corridor.
• A published event brief: date, doors, running order, venue and travel, parking, accessibility, what is included, dress code, transfer and refund terms. BO answers only from this document, so vague answers in it become vague answers to attendees.
• Your refund and transfer policy decided and published before the first ticket is sold, including the cut-off dates. Deciding it after the first cancellation request is how events acquire a reputation.
• Catering deadlines and the exact date the final headcount is due, because the reconfirmation ladder is timed backwards from that date and not from the event.
• Named owners: an event manager for allergies and escalations, a door lead per shift, and someone monitoring the event number on the day. A door shift with no named person is the most common single failure.
• Badge design and printing decided - pre-printed by name, printed on demand at the desk, or blank with a marker. Each implies a different door flow and a different queue length.
• A tested offline fallback: printed list, charged battery packs, and a door process that works if the venue wifi dies. Test it before the day, not during.

Integrations

• Stripe for ticket payments, refunds and partial refunds, with webhooks feeding payment_status so no human has to reconcile two lists.
• Google Calendar or Outlook for calendar attachments on confirmations and for door shifts and speaker slots.
• Your video platform if any part of the event is streamed or recorded, so post-event content can be delivered to the specific session- tags.
• Slack or your team chat for the live event channel, which on the day is more useful than any dashboard.
• QuickBooks or Xero for revenue reconciliation per event, with event_id carried through.
• A badge printing tool or a label printer at the desk if you print on demand.
• Zapier or Make for anything your venue or your sponsor's own systems need that has no native connection - sponsor lead lists in particular.

Numbers and messaging compliance

• Provision a dedicated event number and complete A2P 10DLC registration well before the first campaign. Register the brand and a campaign that honestly describes the use case: transactional event and ticketing messages to registered attendees, with promotional messages registered separately. Registration takes days, and an event date does not move for it.
• Keep transactional and marketing consent separate and separately captured. Registration consent covers the ticket, the reminders, the reconfirmation and day-of logistics. It does not cover next year's announcement, which needs consent_marketing.
• Identify the event or organizer by name in the first message of every thread, carry opt-out language on promotional sequences, honor STOP, UNSUBSCRIBE, CANCEL and QUIT instantly, and make suppression global. An attendee who opts out of SMS must still receive their ticket by email.
• Set quiet hours in the attendee's own time zone and keep every message inside them except day-of operational messages within your published event window.
• Cap the pre-event message count. A reasonable ladder is confirmation, session selection, dietary form, agenda at 7 days, reconfirmation at 3 days, logistics the day before, and a door message on the morning. More than that and your opt-out rate climbs, which costs you the reconfirmation you actually need.

Allergies, accessibility, photography and data protection

• Allergy information is safety-critical. It goes on the door screen and the catering list, it is acknowledged in writing by a named human, and no automated message ever tells an attendee that a dish is safe.
• Dietary, allergy and accessibility details are health-related personal data in many jurisdictions. Collect only what the event needs, limit who can see it, share with the caterer only what they need, set a retention period and delete on schedule.
• Capture consent_photography explicitly at registration, make photo-opt-out visible to your photographer and recognisable on the badge, and brief the photographer before the doors open. This is the compliance detail most events discover afterwards.
• If sponsors receive attendee details, say exactly that at registration, make it a separate opt-in, and share only the fields you said you would. A sponsor lead list assembled without consent is a problem that outlives the event.
• Card details belong in your payment processor and nowhere else - not in a field, a note or a message thread.
• None of this is legal advice. Have your own counsel, and the client's where you build this for a client, confirm the refund and transfer terms, consent wording for marketing, sponsor data sharing and photography, the handling of dietary and health information, and your retention schedule in every jurisdiction your attendees come from. To scope a build, book a call at bookings.appbo.io.