One Calendar for Everything: Bookings, PT Sessions, and Club Events

Photo: anonymous · Rijksmuseum (CC0 1.0), via Openverse

Time is the one resource you can never reorder. Yet almost every organization we support with Xircuit manages it across four or five different places: a booking tool for appointments, a spreadsheet for trainer hours, a WhatsApp group for the next club event. As soon as someone is active in more than one of these worlds, the overview turns into a puzzle whose pieces never quite fit together.

This week is about the attempt to solve that puzzle. I explain how the calendar in Xircuit is built, why it brings three very different kinds of appointments under one roof, and which building blocks in the background make a booking possible in the first place.

Three Sources, One View

The calendar lives at /calendar, and its central job is banal and difficult at the same time: it brings three sources together. Bookings, personal-training sessions, and club events all land in the same view, even though they come from completely different corners of the platform and are also modeled differently internally.

Why unify them at all? Because the separation is a technical artifact, not a need of the users. For a trainer who gives one-on-one sessions in the morning and leads a club training session in the evening, those are simply two entries on the same day. Whether one comes from the booking system and the other from club administration shouldn't have to matter to her. The calendar abstracts this origin away and shows a single, unified stream of appointments, sorted by time rather than by source.

Technically this is a union across three data sources with different shapes, projected onto a shared display model. Each source brings its own fields — a booking knows a resource and a service, a club event knows a participant list — but all of them share the minimum the calendar needs: a title, a time window, an organization, and a type that tells the UI how to treat the entry.

Self-Service Booking Around the Clock

The first source is online booking, and it's also the one that removes the most day-to-day pain. For us, online booking means three things: self-service booking around the clock, automatic reminders, and a conflict-free calendar. These three properties sound like a given, but each one carries a real cost behind the scenes.

Self-service booking around the clock means nobody has to call back anymore. A customer sees the open slots, picks one, and is done — at three in the morning just as easily as at noon. For that to work, the free slot has to genuinely be free at that moment, and it has to stay that way until the booking is complete. That's exactly what the conflict-free calendar means: no double-booking, because the system checks availability before confirming an appointment, and then locks the slot in a binding way.

Automatic reminders are the third element, and the quiet hero against no-shows. Instead of someone manually calling through every appointment the day before, the platform sends the reminder on its own. This is one of the places where the architecture pays off: reminders run as a background process through their own worker, decoupled from the web interface, so that a stuck send never slows down the booking itself.

The Building Blocks Behind a Booking

For a self-service booking to happen at all, it takes more than a single click. Three building blocks form the foundation: bookable resources, a service catalog, and staff availability. Only their interplay produces a bookable slot.

Bookable resources are what gets occupied — a treatment room, a piece of equipment, a spot. A resource can only be assigned once at a time, and that's exactly where the conflict the calendar must avoid comes from.
The service catalog defines what can be booked, and for how long. A 30-minute initial consultation and a 90-minute treatment are two entries in the catalog, and their length determines how the system carves up the free time windows.
Staff availability determines who offers what, and when. Without an available person, there is no bookable slot, even if the room and service are free.

The actual calculation of a free slot is the intersection of these three dimensions: a time when the person is available, the resource is free, and the desired service fits into the window. That sounds simple, but in practice it's exactly where most booking systems either offer too much or too little. I made a deliberate point of keeping this logic server-side and authoritative — the UI suggests slots, but the binding check happens only at confirmation, so that two simultaneous bookings can't grab the same slot.

Booking an appointment on a smartphone Photo: Rawpixel (CC0 1.0), via Openverse

RSVP and Waitlists for Club Events

The third source is club events, and they follow a different logic than individual bookings. An appointment with a trainer belongs to one person; a club event or a group hike belongs to many. That's why club events support RSVP and waitlists — so that limited spots are allocated fairly.

RSVP means members commit to a firm yes or no before the event takes place. That gives the organization planning certainty: it knows whether five or fifty people are coming and can prepare rooms, catering, or materials accordingly. Once the number of confirmations reaches capacity, the waitlist kicks in. Anyone who signs up after that automatically moves up if someone ahead of them drops out — in the order they registered, not by chance or by who hits "refresh" first.

The waitlist is deliberately built as a fair, deterministic order. Fairness here isn't a soft word but a concrete requirement: a spot that opens up must go to the person who's next in line, and that transition must be traceable. This is a different way of handling scarcity than with individual bookings, where an occupied slot simply disappears. With a club event, the demand stays visible, and the waitlist makes it manageable.

Thinking Across Industries

Perhaps the most important decision isn't embedded in any single feature but in how the view itself is scoped: it's cross-industry. Anyone active in multiple organizations sees all their appointments in one place. That's not a side effect — it's the actual reason for bringing the three sources together.

People rarely live within just one organization. The same person may be a customer at a studio, a member of a club, and perhaps also a client of a therapist. In most systems, that means three separate logins and three separate calendars. Xircuit flips this around: the person is at the center, and the calendar pulls together their appointments from every organization in which they have a role. A booking here, a club event there, a PT session somewhere else — all in one chronological picture.

This is possible because membership in an organization is already a central concept in Xircuit. The calendar doesn't ask "which appointments exist in this organization," but "which appointments concern this person, across all their memberships." That's a small shift in perspective with a large effect, and it's the point where the platform's cross-industry idea shows most clearly.