A boutique studio runs a 7 a.m. class with 12 spots. Eleven people book. One cancels at 6:45. Two people are on the waitlist. Who gets the spot, how do they find out, and what happens if the first person does not see the message in time? Generic scheduling software handles none of this, because it was built for appointments, and a class is not an appointment.
Studio and fitness software looks simple from the outside: a schedule, a booking button, a payment. The trouble is that the money and the capacity are tied together. A booking consumes a spot and often a credit. A cancellation returns one or both, or does not, depending on a rule that changed three times last year. Get the model wrong and you spend your days reconciling front-desk disputes.
This is a tour of the rules that break generic products, written for someone deciding what to build or buy.
Capacity is a count, and the count has rules
The naive model is "class has a capacity, bookings less than capacity means open." Real studios need more states than that:
- Spots held for staff, trial guests or a partner program.
- A class that is open for booking at a set time, such as 48 hours ahead, for members only, and later to everyone.
- Equipment capacity that differs from room capacity, such as 10 bikes in a room that holds 14 people.
- Overbooking tolerance, which some studios set deliberately because they know the typical no-show rate.
Model capacity as an explicit count of claims against a class, and enforce it inside a database transaction, not in the interface. Two people tapping "book" on the last spot at the same moment must produce one confirmation and one waitlist entry. This is the same discipline as per-location inventory in retail: a number that two actors can change at once needs a single place that decides.
The waitlist is a small state machine
A waitlist is not a list. It is a process with timing. The version that works in practice looks like this:
- A spot opens and the first waitlisted person is offered it, with a deadline.
- The offer expires after a window. A longer window is kinder to people. A shorter one is needed close to class time, so the window should shrink as the start approaches.
- On accept, the booking is created and payment or credit is applied. On expiry, the offer moves to the next person.
- Within a few hours of class, switch to auto-promote: the system books the next person and charges them, because nobody can respond in time.
Auto-promotion is where billing and capacity collide. If the person has no credits and no payment method on file, promotion must skip them without losing their place in the story. Write those cases down before you write code.
Cancellation rules are money rules
Late cancel and no-show policies are how studios protect revenue, and they are almost always more intricate than a settings page admits. A typical set: free cancellation until 12 hours before, a forfeited credit after that, a fee for a no-show, and an exception for members on an unlimited plan who instead lose a booking privilege after repeated no-shows.
Two implementation choices keep this sane. First, store the policy that applied at the time of booking, because policy changes should not rewrite the past. Second, make every credit movement a ledger entry with a reason, rather than editing a balance. When a member says "I cancelled in time," you want to show the timestamp and the rule, not argue from a number. The same append-only ledger idea underpins reliable billing, and we write about it in reconciliation, ledgers, and why a float is not money.
Credits, packs and expiry
Class packs introduce a second currency. A 10-class pack expires in 90 days. A membership grants 8 classes a month that do not roll over. A gift pack is bought by one person and used by another. Each needs an owner, a source, a balance and an expiry, and consumption order matters: use the credit that expires soonest first. Otherwise members lose credits the studio could have honored, and complaints land at the front desk.
Recurring billing has studio-specific edge cases
- Membership freezes for travel or injury, with a defined return date and a billing pause.
- Mid-cycle upgrades and downgrades that must prorate classes as well as dollars. The billing mechanics here resemble the problems in mid-cycle plan changes.
- Failed payments that should not immediately cancel a member who has a class booked tomorrow.
- Family or corporate accounts where one payer funds several attendees.
- Sales tax that depends on what was sold: memberships, retail items and private sessions may be taxed differently by jurisdiction.
Failed payment handling deserves a note of its own. A reasonable default is a short retry sequence with notices, a grace period during which existing bookings still work, and only then a status change. Cutting someone off after one failed card attempt costs more goodwill than it saves.
The front desk and the floor
Check-in is the product for the person at the desk. They need to find a member by name or phone, see today's bookings, add a drop-in, and fix mistakes, all with a line of people waiting. That means search that tolerates typos, a view of status that includes credits and recent cancellations, and an override with an audit trail for the manager who decides to waive a fee. Instructors need a roster they can open on a phone in a hallway with weak signal, which is where an offline-capable approach pays off.
Where this does not apply
A solo trainer with ten clients does not need a waitlist engine or a credit ledger. A shared calendar and a payment link will serve them better than any platform. The complexity above matters once you have fixed-capacity classes, packs and more than one person who can change a booking. Below that, buy something off the shelf and spend your time on your clients.
If you are building for this sector or somewhere similar, our notes on industries we build for and the retail platform we operate show how we approach rule-heavy domains. When you are ready to scope one, tell us what you are building.
Frequently asked
Why can't a generic appointment scheduler run a fitness studio?
Appointments are one-to-one slots. Classes have shared capacity, waitlists, packs and memberships that consume credits, plus cancellation windows tied to money. A generic scheduler lacks the rules that connect a booking to a credit, a fee or a waitlist promotion.
How should a booking system prevent overbooking?
Enforce capacity inside a database transaction, counting claims against the class, rather than checking in the interface. When two people take the last spot simultaneously, one gets the booking and the other joins the waitlist. Optional overbooking should be an explicit setting, not an accident.
Should credits be stored as a balance or as entries?
Entries. A ledger of credit movements, each with a reason, source and expiry, lets you answer a dispute with a timestamp and the rule that applied. A single mutable balance cannot explain how it got to its current value.
When should a studio skip custom software?
When it has few clients, no fixed-capacity classes and no packs or memberships. A calendar and payment link are enough. Custom booking logic pays off once capacity, credits, waitlists and several staff members editing bookings create real reconciliation work.