Class scheduling — rooms, recurrences, and no-shows

Class scheduling sounds simple until you actually do it. "Every Tuesday at 6:30pm" is one sentence. The implementation is two months of paper cuts: the bank holiday week, the room that's double-booked with a kids' party, the student who no-shows three weeks running, the instructor who calls in sick at 8am.

This is a tour of the hard parts, and the patterns that tend to work.

Room and space conflicts

If you only have one room, you can skip this section. If you have two or more — or if you hire a hall that someone else also hires — this is where most schedules quietly fall apart.

The pattern that works:

• Treat rooms as a first-class scheduling object, not an afterthought. Each class is booked into a room, and the system refuses to let you double-book.
• Build in a buffer (10-15 minutes is typical). If yoga ends at 7:30 and pilates starts at 7:30, you've created a problem. The system should enforce a gap by default.
• For external venues (the church hall you rent), keep a single source of truth for which slots are yours. A shared Google Calendar that the hall manager also writes to is fine, as long as everyone agrees that's the source of truth.

The failure mode is always the same: someone changes a room booking in one place (a paper diary, a WhatsApp thread with the hall manager), forgets to update the other place, and a student turns up to a locked door.

If your room schedule lives in two places, sooner or later they'll disagree. Pick one to be the truth, and make everyone else read from it.

Recurring blocks with exceptions

This is the single most-requested feature in class software, and the single most badly-implemented.

Most tools let you set "every Tuesday for 8 weeks" and then refuse to let you skip one Tuesday without unpicking the whole series. That's not a recurring block — that's eight separate classes pretending to be a series.

What you actually need:

1. Define the series once: title, time, room, duration, capacity, price
2. Add exceptions per-date: skip the bank holiday week, move week 5 to a different room because the usual one is booked, change week 7's time by 30 minutes
3. The students see one block in their account ("Tuesday Pilates, 8 weeks, weeks 1-8"), but the system handles each date individually under the hood
4. Cancelling a single date refunds or credits that one class, without affecting the rest of the block

If your tool makes you choose between "edit the whole series" and "delete and recreate", it's going to drive you mad by the second block.

The no-show problem

The hardest policy question in classes is not "how much do I charge?". It's "when do I forgive?".

A no-show is anyone who books, doesn't cancel, doesn't show up. In a popular class with a waitlist, a no-show is a double loss — you couldn't refill the spot, and you've lost the revenue. So most teachers want some form of no-show charge.

But blanket policies feel mean. A regular who's been coming for two years and missed once because their cat got hit by a car shouldn't be auto-charged £15 the moment they no-show. Equally, a one-time visitor who booked three classes and turned up to none should be charged for all three.

The pattern that works in practice:

• Default policy: card on file, charged automatically for no-shows, with a cancellation window (e.g., cancel up to 4 hours before, no charge)
• Grace window: the first no-show in a rolling 90-day period is forgiven automatically. After that, charges apply.
• Manual override: you can always wave a charge for regulars with genuine reasons, with one click. Don't make this a 20-minute admin job.
• Transparency: the policy is visible at the point of booking, not buried in T&Cs. Students who know the rules generally follow them.

The combination of "auto-charge by default" and "easy to forgive" gets you the revenue protection without the bad-faith feeling.

Waitlist mechanics

A waitlist is only useful if it actually fills cancellations. A list of names that you manually phone through is not a waitlist — it's a contact list.

Decent waitlist mechanics look like:

• When someone cancels, the next person on the list is automatically notified
• They get a short window to claim the spot (15-30 minutes is typical)
• If they don't claim it, the next person is offered, and so on down the list
• Their card is charged automatically when they accept — no extra payment step
• The whole thing happens at 2am if it needs to, without you touching anything

This is the kind of thing that's invisible when it works and embarrassing when it doesn't. A student should be able to join your waitlist and either get the spot or not — not get a phone call from you at 9pm asking if they still want it.

Instructor sick-day fallbacks

The last hard part: it's 6:30am, you have flu, the class is at 9. What's the plan?

The options are usually:

• Cancel and refund. Cleanest, kindest, but you lose the revenue and trust takes a small hit.
• Cover. You have a small bench of cover teachers. The tool needs to let you swap instructor for a single date without unpicking the block.
• Reschedule. You move the class to a different day that week. Students get notified, can opt out for a refund/credit, otherwise rebooked automatically.

Whichever you pick, the tool needs to support it without a 40-minute admin scramble while you're running a temperature. A "cancel this date and notify everyone" button matters more than any other feature on a sick day.

A short policy you can adopt: have a default sick-day plan written down — cancel + refund, or cancel + credit — and pre-write the message you'll send. You'll thank yourself the first time you need it.

If you'd like to see how these patterns work together in one place, Adminished was built around exactly these hard parts — rooms, recurrences, no-shows, waitlists, and sick-day fallbacks all live in the same system.