Class booking, appointment booking, or room booking: the fork under every platform decision

A recovery studio on a Tuesday afternoon runs three different kinds of booking at once. A member has a forty-minute infrared sauna suite to themselves. Another is halfway through a contrast circuit, moving between a plunge and a sauna on their own timing. A guided breathwork and ice session has eight spots and starts at six. Those are not three variations of the same booking. They have three different scarce resources, and a booking system has to model whichever one it was built around.

Platform sales conversations do not put it this way. They present a feature list on which every product appears to do all three, because every product can be forced into all three with enough configuration. The distinction that survives the demo is which model is native: the one the data model, the calendar view, the capacity logic and the reports were designed around. Everything else is a workaround, and workarounds in a booking system are not cosmetic. They corrupt your utilisation numbers, they leak double bookings onto a live floor, and they compound quietly for the whole life of the contract.

The good news is that the native model is usually a published fact you can read off a vendor's own pages in about fifteen minutes, without a call. This page describes the three models, what breaks in each mismatch, and how to identify a platform's native shape from what it publishes. Vendor pages were checked in September 2026 and vendors change them, so re-check anything you plan to act on.

Three models, and what each one treats as scarce

The difference between the models is not the booking screen. It is the answer to one question: when the system decides whether a booking is possible, what is it counting? Everything downstream, from double-booking prevention to utilisation reports to how you sell a membership, follows from that answer.

Read the three descriptions below against your own week, not against a feature grid. Most studios can say within a minute which one describes the majority of their bookable capacity, and that majority is the model you want native.

• Room-and-time. The scarce resource is a physical space for a duration. The system holds an availability calendar and a capacity per room, and a booking consumes room-minutes. Arketa publishes this model on its recovery vertical page[1]: booking by the hour, the session or the whole day, with each room carrying its own availability, capacity and calendar so nothing double-books.
• Staff appointment. The scarce resource is a named person's calendar, and services attach to providers who can perform them. Boulevard, Mangomint, Zenoti and Vagaro sit here. The shape shows even in how the product is priced: Boulevard's entry tier is capped by professional count[3], because the professional is the unit the product is organised around.
• Class roster. The scarce resource is one of N spots at a fixed start time, with a waitlist behind it. Mindbody, Mariana Tek, Walla, Momence, Punchpass, TeamUp, Glofox and Clubworx sit here. Mariana Tek describes itself as boutique fitness software for pilates[6], lagree, yoga, cycling, HIIT, barre and group fitness, which is the class model stated as a vertical.
• A fourth thing that is not a model: open access with no booking at all, where a membership grants entry and the floor manages itself. It works until a modality with a hard capacity limit appears on the floor, and then it becomes one of the three above.

The phantom employee: a sauna suite on a staff calendar

The most common workaround in recovery is also the most expensive. A studio buys an appointment platform, discovers there is nowhere to put a room, and does the obvious thing: it creates a staff member called Sauna 1. The room now has a calendar, bookings land on it, and the front desk stops complaining. The invention is invisible for about a month.

Then the reports arrive. Utilisation is computed per provider, so your utilisation number now averages real humans against rooms and means nothing. Payroll and commission modules see staff records with revenue attached to them. Staff-count-based pricing tiers count your rooms as professionals, so you pay per room for a seat nobody logs into. Any report that asks how productive your team was returns a number that includes four saunas. If you later add real providers for assisted stretch or manual work, you cannot separate the two populations without hand-editing exports.

The failure that costs money is subtler. A staff calendar assumes the resource is the person, so when the person is unavailable the slot is gone, and when the person is booked they are booked once. That is exactly wrong for a room with capacity above one. A sauna suite that seats three, or a plunge room that can hold two members in sequence within a session block, cannot be expressed as a person. You either sell it as capacity one and leave revenue in the room, or you overlay a second phantom staff record for the same physical space and remove the system's ability to stop a double booking.

None of this argues that appointment platforms are bad. They are precise about a genuinely hard problem: matching a qualified provider to a service in a time slot. If your revenue majority is one member with one practitioner, the appointment model is the right native shape and the phantom-employee trap never appears. The trap is specific to studios whose scarce resource is the room.

One number for two rooms: a contrast circuit on a class roster

A class roster models capacity as a single integer against a single start time. That is a good model for a room of eight people doing the same thing for the same forty-five minutes. A contrast circuit is not that. A member moves between a plunge and a sauna on their own timing, holds one room while the other is free, and finishes when they finish. A circuit has no single capacity. It has a set of room capacities that interact over time, and the binding one moves through the evening.

Forced onto a roster, this breaks in both directions at once. If you set the roster size to the sauna's capacity, the plunge sits idle while the system reports the circuit as full and turns away a member who only wanted the cold. If you set it to the combined capacity, the roster happily sells more members than the sauna can hold at the moment they all arrive at it, and your staff manages the overflow by asking people to wait. Neither of those is a scheduling preference. One turns away bookable revenue and the other degrades the session a member paid for.

The second-order damage is to your data. Roster systems report attendance against a class, so a circuit that ran with six members in the plunge and two in the sauna is recorded as a single class of eight. You cannot see which room is the constraint, which means you cannot answer the only capital question that matters: whether the next unit you buy should be a second plunge or a second sauna. A studio can run this way for a year and end up making a five-figure equipment decision on a number the system was never able to compute.

Class rosters are the right native model for guided sessions with a fixed start, a leader and a shared duration. Guided ice bath and breathwork classes, group recovery circuits run on a coach's clock, and anything sold as a scheduled group experience all fit cleanly. If most of your calendar looks like that, take the class-native platform and model the individual bookings around it, not the other way round.

Double-booked rooms: an open floor on an appointment book

The third mismatch is the quietest, because it produces no error message. An open recovery floor sells access, and members move between compression boots, a red light bed and a percussion station according to what is free when they arrive. Modelled as appointments, each station becomes a service on somebody's calendar and each visit becomes a chain of bookings, which is administratively heavy but functional. The failure comes from the fact that the appointment model tracks who is free rather than what is free.

Two members can hold overlapping bookings for the same physical station if those bookings were created against different staff records, different service types, or a walk-in path that bypasses the calendar. There is no room object to collide with, so nothing collides. The front desk finds out when both members walk to the same bed. Add a member who runs eight minutes long, which is normal in recovery and abnormal in a haircut, and the drift compounds across the afternoon with nothing in the system tracking that the room, rather than the staff member, is what ran late.

The related gap is turnover time. Recovery rooms need cleaning, water changes, cooldown and reset between users, and that time belongs to the room rather than to a person. Appointment platforms usually express padding as buffer time before or after a provider's appointment, which is the correct concept attached to the wrong object. When the room is the constraint, buffers modelled per provider either underprotect the room or block a provider who has nothing to do with it.

• The symptom to watch for: double bookings that appear only on the floor and never in the system's own conflict warnings.
• The second symptom: cleaning and reset time that exists in your staff's heads and nowhere in the schedule.
• The third: an average session that runs longer than its booked length, with no field anywhere recording how much longer.

Reading a vendor's native model off its published pages

You can usually settle this before a call. Vendors describe their native model plainly, because it is what they are proud of, and the absences are as informative as the claims. What follows is what to look for, with examples from pages checked in September 2026.

The strongest signal is a published capacity object. If a vendor publishes per-room availability, capacity and calendars, and offers booking by the hour, session or day, that vendor is room-native and it will say so. If a vendor's feature set never mentions class booking anywhere, as is the case with Mangomint[2]'s published documentation, it is appointment-native by its own account. Where a vendor publishes neither, you have not learned its model from the page: ABC Glofox's pricing page carries no tier names, no prices and no feature detail, only a quote request[5], so its native model has to come out of a demo instead.

Absences are worth recording as absences. Punchpass publishes class booking, and its published feature set does not mention point of sale or retail[4], multi-location, or an API. That is a scope statement rather than a hidden flaw, and for a single-location studio that sells no retail and needs no integrations it may be entirely sufficient. Write down what is not published instead of concluding it does not exist, then ask about each one directly.

• Search the vendor's site for the words room, resource and capacity. A room-native product uses them as nouns in its feature set; the others use them incidentally or not at all.
• Check whether pricing is banded by staff or professional count. If it is, the professional is the organising unit and you will pay per phantom room.
• Check the vertical page. A vendor naming saunas, cold plunge and contrast therapy has thought about your floor; a vendor naming pilates, cycling and barre has thought about a roster; one naming salon, medspa and barber has thought about a chair.
• Check whether recovery appears as its own vertical or as an adjunct. Hapana names wellness and recovery, mentioning saunas and ice baths, compression, stretching, physiotherapy and breathwork, but frames the category as prehab and post-workout support around fitness, which is a different centre of gravity from a standalone recovery floor.
• Ask for a demo of the mismatch case specifically: a room with capacity greater than one, booked back to back, with cleaning time between users, and watch what object the system creates.

If you genuinely run all three, decide which one to make native

Most established recovery studios do run all three, so the choice is not about eliminating the mismatch; it is about placing it where it costs least. The rule that holds up: make native whichever model carries the majority of your bookable minutes, then absorb the other two as the smaller, better-understood workaround.

Count it. Do not estimate it. Take four typical weeks and total the booked minutes in each category: room-and-time sessions, one-to-one appointments with a named provider, and roster sessions with a fixed start. The largest of the three is what your platform should be native to. If the split is close, weight it by revenue and not by minutes, because the model that carries your margin is the one whose reporting you need to trust.

Then decide the workaround deliberately, before you are mid-migration and improvising. A class-native platform can hold one-to-one appointments as a class of one, which works and costs you a slightly odd member-facing label. A room-native platform can hold roster sessions as a room booked at capacity with a fixed start, which works and gives you less roster tooling. An appointment-native platform can hold rooms only by inventing a staff record, which is the workaround that damages the most reports, so if rooms are more than a small minority of your minutes, that is the mismatch to avoid taking on.

Praxium is none of the three models and does not replace one. It is a directory carrying studio profiles for city and modality searches, and its optional protocol layer describes what a member should do across visits, which is a different object from what a booking system reserves for the next forty minutes.

The demo questions that settle it

Booking model questions are easy to answer vaguely and hard to answer vaguely twice, so ask them as specific tasks and watch the screen instead of listening to the answer. Ask the sales engineer to build your actual floor during the call (your rooms, your capacities, your worst Saturday) and keep the recording.

• Create a room with capacity three, then book two members into it at overlapping times. Does the system model the room as a first-class object, or did you just create a staff member?
• Add fifteen minutes of cleaning time that belongs to the room and not to a person, then show me it blocking the room for the next member.
• Sell a member a contrast session that uses two rooms with different capacities, then show me the report that says which of the two was the constraint last month.
• Show me utilisation for a room, expressed as booked minutes over available minutes, without any staff record involved in the calculation.
• Book a session with no staff member attached at all, and show me it appearing on the daily floor view.
• Show me what a member sees when the plunge is available and the sauna is full at the same start time.