Waitlists measure supply, votes measure demand: CrowdPleaser vs your booking system's waitlist
Mindbody, Glofox and Zen Planner waitlists tell you a full class is full. They cannot tell you which class to add. Here is how the two work together.
“We already have a waitlist” is the most common reason an owner gives for not needing a demand tool. It is a fair point about a different problem. A waitlist is a fine answer to “this class is full, who is next?” It has nothing to say about “which class should we add?” This post is about the gap between those two questions, and why the booking system you already pay for will never close it.
What a waitlist does
Mindbody, Glofox, Zen Planner and their peers all work the same way. A class exists on the timetable. It fills. Members who wanted in join a waitlist. When someone cancels, the next person gets a notification, by push, text or email depending on the platform. Some let you tune who gets promoted first by membership tier or purchase history.
That is a supply problem being managed well. The class is popular; the system rations the seats.
What a waitlist cannot do
It only exists after you have scheduled the class. You have already committed a coach, a room and a time slot. The waitlist tells you the bet paid off. It cannot tell you before you place the bet.
It only sees members. Waitlists live inside the member app. A lapsed member, a drop-in customer or someone who has never joined cannot tell you what would bring them in.
It measures one class at a time. A waitlist on the 6pm reformer class says “more 6pm reformer”. It does not say whether members would rather have a 7am express, a prenatal series or a Saturday duet, because none of those exist to be waitlisted.
It captures a name, not a reason. You learn who wants in. You do not learn that the demand is mostly beginners, or mostly parents, or mostly people who can only do weekends.
The short version
| Booking-system waitlist | CrowdPleaser board | |
|---|---|---|
| Exists before the class is scheduled | No | Yes, that is the point |
| Open to non-members and lapsed members | No, member app only | Yes, anyone with an email |
| Ranks competing ideas against each other | No, one class at a time | Yes, one board, many ideas |
| Captures why (tags: level, age, time) | No | Yes, members pick tags when they vote |
| Members can suggest ideas | No | Yes, with your approval |
| Emails everyone interested when it launches | Notifies the next person when a seat opens | One email to every voter with your booking link |
| Manages seats in a running class | Yes, well | No, and it never will |
| Replaces your booking system | It is your booking system | No. Validate here, book there |
How the two work together
The workflow that owners settle on looks like this:
- Put candidate classes on a board. Three to six ideas, tagged by level and time. Share one link in the newsletter, the group chat and on a QR code at the desk.
- Let the votes rank them. A week is usually enough. The tags tell you who the demand is and when they can come.
- Schedule the winner in your booking system. Create the class exactly as you always do.
- Launch to the voters. One click sends every voter an email with the booking link. The class opens with a warm list instead of an announcement.
- Let the waitlist take over. If it fills, the booking system rations the seats. That is its job, and it is good at it.
The board runs before the timetable; the waitlist runs after it. Neither replaces the other.
A note on “we’ll just add it and see”
Adding a class to find out whether it fills is a test that costs a coach’s pay, a room and a marketing push per week, and it takes six to eight weeks to read the result. A board costs a link and a week. If the class wins the vote, you have also collected the list of people who will fill it on day one. If it loses, you saved the coach’s fee and learned what to try instead.
See what a board looks like on the live demo, or work out what an under-filled class is costing you with the break-even calculator.