How Do I Add a Waitlist to Webflow Event Registration Forms in 2026?

What happens when 150 people try to register for 50 seats?

In May 2026, a Bengaluru SaaS client of mine ran an in-person product launch in Indiranagar. They had 50 chairs. They got 147 form submissions in 36 hours. The form did not know how to say no. People paid through Stripe for seats that did not exist, and we spent a Saturday refunding cards. According to Eventbrite's 2025 Event Industry Report, the average no-show rate for free events sits near 30 percent, so a waitlist is not a nice extra. It is the safety net that saves a launch. In this post I will walk you through the exact Webflow setup I built after that mess, including the CMS structure, the front-end JS, and the Make.com scenario that promotes the next person when someone cancels.

What is a Webflow event waitlist, really?

A Webflow event waitlist is a second CMS collection that catches registrations after your seat cap is hit. The form decides which collection to write to based on a live seat count. If a registered attendee cancels, automation promotes the top waitlist entry into the main attendee list and emails them.

That is the whole idea. The Webflow Forms element on its own cannot do this, because it does not read CMS data before submission. So you need three moving parts. You need Webflow CMS holding the seat math, a small front-end script that checks the count when the page loads, and an automation layer that handles cancellations. I use Make.com for the automation, though Zapier and n8n work the same way. Pick the one your team already pays for.

How do I build the two CMS collections in Webflow?

Create two collections in Webflow CMS. The first is Attendees, with fields for name, email, ticket type, Stripe payment ID, and a reference to the event. The second is Waitlist, with the same fields plus a numeric position field. On the Event collection itself, add a total seats field and a seats remaining field.

The seats remaining field is the magic one. It is a simple number that gets decremented every time a new Attendee record is created and incremented when one is deleted. I update it through the Webflow CMS API from Make.com, not by hand. Webflow Logic can also do the increment, but the step quota gets tight fast, which I will explain below. Keep your Event collection slug clean, something like product-launch-bengaluru-june-2026, because both the Attendees form and the Waitlist form will reference it through a hidden field.

How do I add the front-end seat-check script?

Drop a small embed inside your registration page that fetches the seats remaining field for the current event, then either shows the registration form or swaps in the waitlist form. The script runs on page load and again right before submission, so a buyer cannot sneak into a sold-out event in the seconds between page open and click.

The embed is roughly 40 lines of vanilla JavaScript. It calls the Webflow CMS API through a Cloudflare Workers proxy, because the Webflow API token should never sit in client code. The Worker reads the seats remaining number, returns it as JSON, and the script flips a CSS class on the form wrapper. If seats are zero, the Attendees form hides and the Waitlist form shows. I also re-run the check on the form's submit event, because someone who left the tab open for two hours could otherwise still grab a phantom seat. For my Bengaluru client, that double-check caught four ghost registrations on launch night.

Webflow Logic or Make.com, which one should I pick?

For free events with under 100 seats, Webflow Logic is fine. For paid events with Stripe, refunds, and email sequences, use Make.com or Zapier. Webflow Logic is faster to set up but its step limits get expensive at scale, while Make.com handles complex branching cheaply.

Per Webflow's June 2026 pricing page, the Core CMS plan includes 1,000 Logic steps per month, and a single registration with confirmation, CMS write, and seat decrement burns three steps. So a 50-seat event with a waitlist of 100 will eat 450 steps before you count cancellations. Make.com's Core plan, per their June 2026 pricing, gives you 10,000 operations a month for about the same price, and a full registration scenario uses around five operations. The math is not subtle. I default to Make.com for any paid event. For a free meetup with a Mailchimp or ConvertKit confirmation, Webflow Logic plus a native email step is perfectly fine.

What if attendees say the waitlist feels sketchy?

The most common objection I hear is that people do not trust waitlists, because they have been burned by silent ones. Fix this with two things on the confirmation page. Show their position number, and tell them exactly what triggers a promotion. Honesty kills the sketch factor.

When I rebuilt the form for my client, the waitlist confirmation page read, You are number 12 on the waitlist for the June 18 launch. If a paid attendee cancels before June 16, we promote in order and email you a Stripe checkout link valid for 24 hours. That single sentence cut the support emails to near zero. I pull the position number from the Waitlist collection by counting existing records before insertion, which Make.com does in one Webflow CMS module. People in Mumbai and Bengaluru are sharp about these things, and they will refresh the page to see if their number moved, so make the position field public and visible.

How do I wire the Webflow form to Make.com end to end?

Set the Webflow form action to a Make.com webhook. The scenario routes on a seats-remaining check, writes to either Attendees or Waitlist, decrements the seat count, fires a Stripe checkout for paid tickets, and sends a confirmation through Beehiiv or ConvertKit. For cancellations, a second scenario listens on Stripe refund webhooks and promotes the top waitlist record.

The promotion scenario is the part most tutorials skip. When Stripe fires a charge.refunded event, Make.com looks up the Attendees record by payment ID, deletes it, increments seats remaining, finds the Waitlist record with the lowest position, creates a new Attendees record from it, deletes the Waitlist row, and emails the promoted person a checkout link. That is seven Webflow CMS API calls in one scenario, which still fits comfortably inside the Core plan's operation budget. I built the same flow once for a free event using Mailchimp instead of Stripe, and the trigger was a manual cancel link in the confirmation email. Same logic, no payment layer.

How do I measure whether the waitlist actually worked?

Track three numbers. The waitlist conversion rate, which is how many promoted people actually showed up, the no-show rate against the Eventbrite 2025 benchmark of 30 percent, and the average promotion time, which is how long someone sits on the waitlist before getting a seat.

For my client's May 2026 event, we promoted 11 people from the waitlist after cancellations, and 9 of them showed up. That is an 82 percent conversion, much higher than the original list, because waitlist people had already been told no once and were hungrier for the seat. No-show rate landed at 14 percent against the Eventbrite 30 percent benchmark, which I credit to the SMS reminder we sent 4 hours before the event through a separate Make.com scenario. I log all three metrics into a simple Webflow CMS collection called Event Metrics, so the client can see year-over-year trends without opening a spreadsheet.

How do I ship this for my own next event?

Start with the CMS structure today. Build the Event, Attendees, and Waitlist collections in Webflow Designer, add the seat fields, and connect a test form to a Make.com webhook before you touch any styling. Get the plumbing working on a hidden page, then bring in design.

If your event also needs confirmation emails that pull from the CMS, you can pair this with my tutorial on Webflow event RSVPs that email confirmations from the CMS, which covers the templating side cleanly. And if your form is long enough that people will abandon it partway, look at my guide on saving Webflow form drafts to local storage, because losing a half-filled registration to a flaky cafe wifi connection in Koramangala is the fastest way to lose a paying attendee.

If you are running an event in the next 60 days and the math above is making your eye twitch, send me a note through the contact form on this site. I will look at your Webflow project, your ticket volume, and your automation stack, and tell you honestly whether you need the full Make.com build or whether Webflow Logic will get you across the line.