A session sells out, and the work starts. You flip registration off for that week before someone grabs a spot that isn’t there. You open the spreadsheet of hopefuls and add the latest name to the bottom. When a family cancels, you scroll up, find whoever’s next, email them the offer, wait, and hope they answer before the spot goes stale. Somewhere in there two families get told they have the last spot, because the roster and the spreadsheet disagreed by a day.
None of that is hard. It’s just constant, and it lands during the weeks you have the least time. The fix isn’t a better spreadsheet — it’s putting capacity and the waitlist inside registration, so the logic that you’ve been running in your head runs itself. This is how that works: setting capacity, what happens when a session fills, a waitlist that holds its order, filling an opening without chasing anyone, and keeping the count honest as spots move.
Setting capacity on the session
Capacity is a number on the session, not a rule you enforce by watching a list. When you create or edit a session, you set how many campers it holds. That number lives with the session from then on.
From that point the system counts confirmed registrations against the capacity for you. The session detail shows the count against the cap — eighty-three of one hundred, say — so you always know where a week stands without tallying anything. You set the number once when you build the session; the count maintains itself as families register and as cancellations come back out. There’s no separate “how full are we” question to answer, because the session already knows.
That’s the foundation the rest of this rests on. Once a session knows its own capacity, everything that happens at the cap can be automatic — because the system knows the moment it’s reached.
What happens when a session fills
The moment a session’s confirmed count reaches its capacity, the session is full, and the registration form knows it. The next family to register sees the session marked full and is routed to the waitlist — they still complete the same registration, but their spot lands in the waitlist queue instead of the confirmed roster.
This is the part that saves the most hand-work, because it removes a decision you used to make under pressure. You don’t flip registration off before the spot disappears, and you don’t catch the overflow after the fact and apologize to a family who thought they were in. The cap holds the line at the exact spot it should, every time, even at 11pm when you’re not watching. Two families can’t both be told they got the last seat, because the count is the single thing that decides — not a spreadsheet that’s a day behind the form.
A family who lands on the waitlist isn’t left guessing, either, which is the next thing the system handles.
A waitlist that holds its order
A waitlist is only useful if its order is trustworthy. The version that lives in a spreadsheet isn’t, quite — rows get re-sorted, a name gets pasted in the wrong place, and the order you’d defend in front of a parent isn’t the order on the screen.
When the waitlist lives in registration, each waitlisted family holds a position based on when they registered, and that position is computed from the data rather than typed into a cell. The order is fixed and it’s visible. A parent sees their own standing — Waitlist #3 — on their registration, so the “where are we on the list” email mostly stops coming. On your side, the session shows the full ordered list: every waitlisted camper, in line, with the date they registered. You’re not reconstructing the queue from timestamps when a spot opens. The queue is already there, already in order, ready to read.
That ordered list is also what makes the next part — actually filling an opening — something you can let run rather than run yourself.
Filling an open spot without chasing anyone
A spot reopens when a confirmed family cancels. In a by-hand system that’s the start of a small project: notice the cancellation, find who’s next, send the offer, track whether they took it. Inside registration, the cancellation and the promotion are one motion.
When a family cancels, the spot reopens and the next family in line is promoted off the waitlist. If you turn on auto-accept for that session, the promotion happens on its own — the next camper moves from waitlist to confirmed without you touching it, and the order is honored automatically. If you’d rather keep a hand on it, leave auto-accept off and the opening surfaces in your waitlist view, where you accept the next family with one action. Either way you’re choosing a posture once, per session, instead of running the queue by hand every time a spot moves. The spot doesn’t sit empty while you get to your inbox, and the family below the line doesn’t get skipped because you scrolled past them.
The result is the same whether the camp filled in January or a week before opening day: an opening finds the right next family, in order, without you being the thing that connects the two.
Keeping the roster and the count honest as spots move
The quiet failure of a manual waitlist isn’t any single step — it’s drift. The roster, the count, and the waitlist live in different places, and every move you make has to be repeated in all three or they fall out of sync. Miss one, and the next decision is made on a number that’s wrong.
When capacity and the waitlist live inside registration, there’s one set of facts. A confirmed registration counts against capacity; a cancellation frees the spot and triggers the promotion; the promoted family’s status flips and the count adjusts — all from the same change, not from three edits you have to remember. There’s no side spreadsheet to reconcile against the roster at the end of the week, because there’s no side spreadsheet. The position a parent sees, the count you see, and the spot that’s actually open are reads off the same data. When something moves, it all moves together.
That’s also why this composes with the rest of registration instead of sitting beside it. The same camper record that carries a family’s conditional registration forms and payment status carries their session status and waitlist position, so a promoted family doesn’t re-register or re-enter anything — they were already a complete registration, just one in the queue. If your capacity and waitlist still live in a column you update by hand, that’s one of the seams that shows up when a DIY stack scales, alongside the others in where Jotform and Stripe camp registration breaks.
You set the rule; the system keeps it
The judgment in all of this is yours: how many campers a week should hold, whether a session auto-promotes or waits for your nod, who you make an exception for. None of that moves to the software. What moves is the clerical weight underneath it — the counting, the gatekeeping at the cap, the re-sorting of a queue, the one-at-a-time offer emails — the parts that never needed your judgment and only ever cost you time during the busiest weeks of the year.
You set the capacity and you decide who gets in. The registration logic holds the line, keeps the order, and fills the opening — so the full session and its waitlist stop being a thing you tend and become a thing that runs. Waitlists and capacity are one piece of camp registration software that holds together once enrollment gets real. Join the waitlist to build next season’s registration on logic that runs itself — and if you’d rather watch it work first, the registration features walk a full registration end to end.
Common questions
- How does session capacity work in a camp registration system?
- Each session carries a capacity number you set when you create it. As families register, the system counts confirmed spots against that number. When the confirmed count reaches capacity, the session is full — and the next registration goes to the waitlist instead of overbooking the spot. You set the number once; the count maintains itself as registrations come in and cancellations go out.
- What happens when a camp session fills up?
- When a session reaches its capacity, the registration form marks it full and routes the next family to the waitlist automatically. The family still completes the same registration; their spot just lands in the waitlist queue instead of the confirmed roster. Nobody has to watch the count or turn registration off by hand, and no two families get the same last spot.
- Does a waitlist keep families in order?
- Yes. Each waitlisted registration holds a position based on when it came in, so the order is fixed and visible. A parent sees their own position — Waitlist #3 — rather than emailing to ask. You see the full ordered list on the session, so when a spot opens you already know who is next without rebuilding a queue from timestamps.
- How does an open spot get filled from the waitlist?
- When a confirmed family cancels, the spot reopens and the system promotes the next family in line. If you turn on auto-accept for a session, that promotion happens on its own; otherwise the opening surfaces in your waitlist view and you accept the next family with one action. Either way the order is honored and the count stays accurate — you are not chasing the queue one email at a time.
- Can I run a waitlist without a spreadsheet?
- That is the point of capacity and waitlist living inside registration. The session knows its capacity, the registration knows its status, and the waitlist position is computed from the data — so there is no side spreadsheet to keep in sync. When a spot moves, the roster, the count, and every family's position update together instead of in three places you maintain by hand.
