Event website checklist for a 100-person event: the ship-ready build

Event website checklist for a 100-person event: capacity cap, dietary capture, parking block, ICS export, post-event page — minus the conference overkill.

The event website checklist for a 100-person event is 13 items in four phases — pre-launch, before RSVP opens, nice-to-have, and post-event. This scope sits between a Luma listing (fine under 50) and a full conference site (needed above 200). At 100 attendees you need a capacity cap, an ICS export, a parking-and-transit block, and dietary capture in the form — not live polling, a mobile app, or multi-track tiers.

What you'll accomplish

A site configured for a 100-person, single-day event: the page sells the room, the form caps at venue capacity, and dietary and accessibility needs reach the caterer before the kitchen closes its order window.

Before you start

  • Venue capacity locked. Confirm before wiring the form.
  • Registration backend chosen. Luma (lu.ma) for free or community events; Eventbrite for paid or discoverable events. Canadian organizer fees: 3.5% + C$1.29 service plus 2.9% processing per paid ticket (Eventbrite); Luma's free plan charges 5% on paid events (Luma pricing).
  • Caterer deadline known. Most caterers close head-count 5-7 days out — your RSVP cutoff has to land before that.
  • One owner for copy. Copy-by-committee stalls the page.

Phase 1: must-ship pre-launch (items 1-5)

1. Hero with event name, date, city, one CTA. H1 carries the event name; sub-line carries date and city; one button — "Reserve your seat." AI answer engines lift this block, so it must be crawlable HTML, not text baked into a hero image.

2. What/when/where paragraph naming the audience. Three to five sentences. Name the audience explicitly ("for Waterloo Region SaaS founders running their first launch"), date in full text, venue and city. Search and AI extract this verbatim.

3. Agenda — single track, four to six sessions. No concurrent tracks at this scale. Render as real HTML with titles, start times, and a one-line description — not a PDF. PDFs don't index, don't render on mobile, and break the page-speed budget.

4. Speakers grid with photo and one-line bio. Photo, full name, role and organization, one earned line. Four to eight speakers; consistent crops and a shared background tone do the work. Skip the LinkedIn-summary bios.

5. Mobile-first layout with sticky register button. Mobile web traffic peaked at 62.99% of sessions in Q3 2024 per Statista; 83% of attendees believe phones improve the event experience (Eventbrite TRNDS 2024). Design 390px first, tap targets at 44px, sticky CTA in the mobile footer. Hit the web.dev "good" LCP threshold of ≤ 2.5 seconds at the 75th percentile.

Phase 2: must-ship before RSVP opens (items 6-9)

6. RSVP form with capacity cap. Wire a hard cap to the backend (Luma and Eventbrite both support this) and a visible counter — "83 of 100 seats taken." The counter does more conversion work than any urgency banner. Four fields: name, email, dietary, accessibility. Eventbrite's conversion guide reports every extra step drops conversion ~10%; Baymard's 2024 benchmark puts the ideal at 12 form elements against an industry average of 23.48.

7. Dietary and accessibility capture in the form itself. Two single-line text fields, not 14-option dropdowns. Your caterer needs vegetarian, vegan, gluten-free, and allergy counts — by name — at least 5 days out. Capture at registration, not via follow-up email. Follow-up emails get ignored; the caterer doesn't.

8. Venue block with parking, transit, accessible entrance. Name the parking lot, the nearest GRT or ION stop, the accessible entrance, and gender-neutral washroom locations. Embed or link a map. The University of Waterloo's event brand standards (updated 2025-02-05) treat this as core information; the hierarchy transfers cleanly to community events.

9. ICS calendar export on the confirmation page. The confirmation screen and email both need an "Add to calendar" button that downloads an ICS file with title, date, time, full venue address, and one-line description. Single highest-leverage no-shows-prevention move at this scale. Luma does this by default; in Eventbrite, confirm the order email template includes it.

Phase 3: nice-to-have (items 10-12)

10. Sponsors block (even if half-empty at launch). Three to five logos at consistent height on a neutral background sells the next sponsor faster than a deck. Include a "sponsor this event" CTA to a one-page packet. Dead space signals under-resourced.

11. FAQ block with six real questions. Pulled from your inbox, not invented: parking, food, guests, dress code, accessibility, recording. One to three sentences each. Marks up cleanly to FAQPage schema; AI surfaces extract entries verbatim.

12. Structured data — Event, FAQPage, BreadcrumbList. Event schema with name, startDate, endDate, location, offers, organizer; FAQPage on the Q&A block; BreadcrumbList for navigation. ISO-8601 dates with time zones. Validate with the Rich Results Test before launch.

Phase 4: post-event (item 13)

13. "Thanks for coming" page with photos and a next-event signal. Within 7 days, swap the registration CTA for a thank-you block, a 12-20 image photo grid, a one-paragraph recap, and a "join the list for the next one" capture. For recurring events this page compounds into social proof for the next edition. Bizzabo's State of Events 2025 reports 78% of organizers emphasize the unmatched impact of in-person events; this is where you cash that in.

What to deliberately skip at 100 attendees

  • A mobile event app — built for 500+ rooms; at 100, a printed agenda plus a wayfinding link does the same work.
  • Live polling and Q&A queues — built for concurrent-track rooms. At 100, raised hands work.
  • Multi-tier registration (early bird / general / VIP) — one ticket price, capacity-capped. Tiers add form complexity that doesn't compound at this scale.
  • Complex sponsor activations — a logo wall, a host mention, and a tagged post-event email do the job in a 100-person room.

Troubleshooting

What if the capacity counter is causing holdouts?

Show it only after 60% full. "3 of 100 seats taken" reads as low demand; "63 of 100 taken" reads as social proof. Luma and Eventbrite both support hiding the counter until a threshold.

What if conversion is low even with a fast page?

Test the form on a mid-range Android over throttled 4G — not your dev laptop. Eventbrite's guide reports a 160% lift from mobile-optimized payments, and 1 in 4 buyers abandons a checkout that requires account creation.

What if I can't ship all 13 items before launch?

Ship items 1-7 and add the rest on a rolling basis. The site can go live without sponsors, FAQ, and structured data; it cannot go live without a working RSVP, dietary capture, and a mobile-fast hero.

What to do next

Once the 13 items ship, the next move is promotion — at this scale the social plan matters more than further site tuning. Day-by-day build cadence in ship an event site in a week; the "do I need one at all" call in when you actually need an event website. If you'd rather not run it yourself, the PixelBrain services menu and $500 concept / $1,500 entry retainer cover microsite, swag, and launch handoff for Waterloo Region hosts.

FAQ

How is this different from a generic event website checklist?

Scope. The generic field-by-field reference at event website must-have elements covers every field a site could include. The 100-person version drops conference-scale features and adds mid-size dynamics: capacity caps, dietary capture in the form, parking blocks, ICS export, and a post-event page.

How many form fields should a 100-person RSVP have?

Four: name, email, dietary, accessibility. Industry average is 23.48 (Baymard, 2024). Every extra field drops conversion ~10% per Eventbrite's organizer guide.

What's the right RSVP cutoff?

Seven days before the event. Most caterers close head-count windows at 5 days out, so 7 gives a buffer for dietary clarifications. Cap at 95 of 100 in the backend to leave room for late comps and sponsor walk-ins.

Further reading

Update log

2026-05-15 — Initial publish.