How it works · Classly.software

One occurrence, one capacity decision, one roster everyone can explain.

The planned workflow separates publishing, booking, waitlisting, attendance, and notifications so a convenient screen cannot weaken the seat guarantee.

Set up the occurrence

Publish the session facts before asking anyone to book.

An operator begins with one session occurrence: title, start and end, time zone, location, instructor, capacity, booking window, cancellation policy, and the public notes an adult attendee needs. Recurrence may help create future occurrences, but each occurrence keeps its own seat decision and roster. Changing a series should not silently rewrite a session people already booked.

The studio chooses the identity key used to prevent duplicates and decides which fields belong on the booking surface. The smallest useful adult flow may need a name and contact route; an evaluation can use synthetic identities throughout. Capacity and policy are visible before confirmation so a customer is not surprised after submitting.

Make and communicate the decision

Confirm a seat or place the request in a defined queue.

When a request arrives, the engine locks the occurrence, counts active bookings, rejects a duplicate identity, and either confirms the new place or returns that the session is full. The planned product may then offer a waitlist under the studio’s stated policy. A screen cannot promise confirmation before the transaction commits, and a notification cannot serve as the source of truth.

The attendee receives the occurrence, status, cancellation route, and policy that governed the decision. The operator roster displays the same committed state. If a confirmed booking is released, a future promotion worker must claim one eligible waitlist entry exactly once, commit it, and send a retry-safe notice afterward. Classly does not claim that promotion worker is live today.

Work through one evening workshop on paper

Imagine an invented adult improvisation workshop with eight places on a Thursday evening. Six places are already represented by fictional bookings in a paper exercise. Before considering another request, write the session's start, finish, location and booking deadline beside its capacity. The output is a specific offer someone could understand, not merely a calendar label saying workshop. This example uses counts and invented details; it does not publish an occurrence or reserve a seat. Its purpose is to expose the questions a future booking screen has to answer before the studio could reasonably ask someone to make a commitment.

Now introduce two requests. One comes from an adult already represented in the six; the other comes from a new fictional participant. Those requests should not consume two additional places just because two messages arrived. The repeated identity and the new identity raise different decisions. On the paper record, mark the repeated request separately and show the expected roster count after the new request is accepted. If the explanation cannot distinguish those cases, a large remaining-seat number will not rescue it. The exercise tests whether the product story explains the built decision rule without pretending the Classly customer interface is already available.

The paper arithmetic is deliberately small: the repeat leaves six distinct places represented, the new accepted request makes seven, and one place remains in the eight-place session. A later request from another distinct fictional adult could fill that remaining place. Write those intermediate counts beside the events, so a reviewer can spot exactly where a repeated message was accidentally treated as another person. This is a reasoning example, not a measured concurrency test. It shows why a trustworthy customer explanation needs to refer to the actual booking decision instead of counting clicks, email messages or names typed into a demonstration.

Keep an old request separate from a changed offer

Suppose the fictional studio later moves that Thursday workshop to a different evening. The capacity question has not disappeared, but it is no longer the only question. Someone who requested the original evening may not be able to attend the replacement. In the planned workflow, an operator needs to explain which occurrence changed and what commitment the person originally understood. Do not treat a date edit as evidence that everyone agreed to the new time. Write the original and proposed facts side by side, then identify the policy or conversation that the studio would need to handle through its existing arrangements.

A reasonable objection is that this sounds slower than simply editing a calendar cell. The point of the comparison is to show what the quick edit leaves unanswered. A future interface must make the relevant change legible; this page does not supply a working change-notification service or choose a remedy on the studio's behalf. The output of the example should be a clear account of what changed, what booking decision remains recorded and what still requires a human response. If a proposed implementation cannot explain those three things, count accuracy alone would not establish a usable session-management workflow.

Treat a released place as another decision

Return to the original fictional session and imagine that it fills. Another adult expresses interest, and a confirmed participant subsequently cancels. There are now several distinct facts: a cancellation, an available place, a person who would like that place and any message explaining the outcome. Classly's waitlist and promotion surface is planned. On paper, record the intended ordering rule and ask which event would actually turn interest into a confirmed booking. A cancellation alone does not prove that the interested person has received or accepted anything. The example should never be presented as a running queue on this site.

Then make the interested person unavailable at the proposed time. That objection reveals why a studio needs a policy rather than a vague promise that the next person automatically gets in. Describe how the studio currently handles the conversation, which result it would need to record and what a future product should refuse to claim before that result exists. The useful output is a set of distinct states with understandable transitions. No notice is sent, no attendee record is created and no payment is taken by the exercise. A product evaluation can settle these meanings before it needs any real participant data.

The mechanism underneath the plan

Capacity-N is built in the shared decision core; the Classly product surface is still being made.

A group session differs from an appointment in one decisive way: several people claim seats in the same scheduled occurrence. The underlying engine treats that as a capacity decision keyed to the person and session. It counts confirmed bookings while holding the session row under a database lock, then accepts or refuses the next claim inside the same transaction. A partial unique index prevents one person from holding the same session twice. Capacity one and capacity thirty use the same law at different values of N.

That decision core exists. A Classly-branded public schedule, roster, waitlist, instructor console, attendance workflow, payment page, and self-serve setup do not exist as a live product today. The distinction is repeated because a polished marketing page can otherwise make a database capability sound like a service someone can buy. Early access starts with a conversation; this site creates no account, charges no card, and books no seat.

The planned public flow is simple enough to inspect: an adult customer chooses a session, sees an honest seat state, identifies themself, and receives either a confirmed place or a waitlist position. A studio operator sees the same occurrence as a roster with capacity, schedule details, and status. An instructor sees only the practical attendance view needed for the session. Those surfaces share a decision but have different disclosure and editing rights.

Waitlist promotion is planned. It must be transactional for the same reason booking is: releasing one confirmed place and promoting the next eligible person cannot be two unrelated writes. Notification delivery must follow the committed decision and remain retryable without creating a second booking. Until those paths and their operator controls exist, this site describes them as planned rather than demonstrating a fake queue.

For evaluation, use a synthetic studio and synthetic adults. A useful example might contain three instructors, six weekly session types, capacities between four and twenty, a cancellation window, and invented attendee names. That is enough to test schedule shape, capacity pressure, waitlist policy, and instructor visibility without bringing real customer records into an early product conversation.

Commercial and operational boundary

Zero commission is a pricing commitment for the planned product, not evidence of a live checkout.

The planned tiers do not take a percentage of session fees. A studio may still choose a payment provider whose processing terms apply, but Classly does not plan to add a marketplace commission. Prices shown on the overview are display-only. There is no subscription checkout, payment token, active trial, or automatic renewal on this website.

White-label presentation, custom domains, roster export, attendance tools, waitlist promotion, and the multi-location console are planned product surfaces. The capacity decision beneath them is built, but that fact does not prove the branded workflow, accessibility review, support process, or operational monitoring around them. Each feature becomes available only when its whole path can be exercised and supported.

Classly makes no adoption, outcome, uptime, or customer-count claim. It presents no testimonial and claims no FERPA, COPPA, SOC2, or VPAT certification. The site contains ordinary product documents and an email link. It sets no marketing cookie, accepts no roster upload, and asks prospects not to send identifiable participant data during evaluation.

An operator also needs a recovery story before a booking surface opens. Session changes must preserve the prior occurrence long enough to explain what attendees originally accepted. Cancellations and capacity changes need named actors and timestamps. Notification delivery can be retried, while the committed roster remains stable. Support staff should be able to inspect a synthetic reproduction without gaining broad access to every studio. Backups, exports, and operational logs need retention and deletion rules. These are ordinary service responsibilities, but none can be inferred from the presence of an atomic booking function. They belong in the readiness decision for each planned surface.