Features · Classly.software

A feature earns its label from the whole path, not from a mockup.

The inventory below begins with the built database decision, then names the customer and studio workflows still planned around it.

Decision features

Atomic capacity and duplicate prevention are the built foundation.

The engine accepts a session capacity greater than one, counts active bookings under a database lock, and commits the next claim only when room remains. A database uniqueness rule prevents one identity from claiming the same occurrence twice. Those controls address the concurrency failure that application-level counters miss when several requests reach the last seat together.

Planned policy features include booking open and close windows, cancellation cutoffs, ordered waitlists, promotion eligibility, and retry-safe notifications. Each policy must be visible to the operator and customer. A promotion should be tied to a released place and recorded once; a late email should not change the committed roster.

Studio features

Recurring planning, instructor scope, branding, and export sit above the seat law.

Classly plans session templates and recurrence tools that create reviewable occurrences rather than one opaque repeating object. Operators should be able to change a future subset without rewriting attendance history. Instructor assignment, room or location, duration, capacity, and public notes belong to the occurrence and remain inspectable when a series changes.

Custom domains and white-label presentation are planned so a studio can own the customer relationship. Instructor views, attendance, roster export, and multi-location administration are also planned. They require complete authorization and accessibility work in addition to HTML. The overview labels these features by status, and this page does not promote a planned label into availability.

The proposed commercial model adds no Classly commission to a studio’s session fee. That statement does not remove a studio’s own payment-processing costs and does not mean checkout exists here. Billing, subscription management, refunds, and payment disputes are outside the built surface today.

Turn a capacity feature into an acceptance question

Consider an invented adult movement session with twelve places. A feature review should ask what happens when twelve distinct fictional people have places and another requests one. It should also ask what happens when one of the twelve repeats the request. Full capacity and a duplicate are different reasons to avoid creating another confirmed place. Write the expected outcome for each case before discussing the interface. The shared capacity decision provides a foundation for the distinction, but the Classly booking surface is still in development. A feature label does not demonstrate the complete customer interaction around either result.

The next question is how an adult reader would understand the refusal. A full session may lead to interest in a future waitlist, while a repeated request may require showing an existing outcome. Neither should be presented as a new successful booking merely to avoid disappointing the person. The output of this review is a pair of concrete expectations that a future surface would have to satisfy. An attractive calendar and a remaining-seat badge cannot substitute for them. No actual customer identity, transaction or private studio record is needed to work through these examples and identify the expected distinction.

Give each feature a short acceptance note containing the starting situation, the requested action and the evidence needed afterward. For capacity, the note concerns whether another confirmed place was created. For the future waitlist, it concerns an explicitly different state and the rule that would govern a later offer. For a message, it concerns delivery rather than a change in roster size. Keeping those notes separate makes a comparison more precise: a product may satisfy one requirement while another remains planned. A buyer can then identify the missing dependency instead of awarding a single complete label to several unrelated outcomes.

Cancellation policy and refunds are separate capabilities

A studio may allow a participant to release a place until a stated deadline. That policy answers whether the booking can change under the proposed rules; it does not, by itself, answer whether money should move. Use a fictional cancellation before the deadline and another after it. Describe what the studio expects the scheduling record to say in each case, then put any commercial treatment in a separate column. Classly's public site has no live checkout or refund action. The exercise must not turn a release-of-place example into an implied payment feature.

A common objection is that customers experience the cancellation and refund as one request. That is understandable, and a future product would need a clear explanation of both results. It still needs to distinguish them. An operator might settle a commercial question through another established process while the session capacity changes separately. The feature discussion should expose that dependency rather than call the whole event complete after the first step. The useful deliverable is a written policy question with two named outcomes. It is not a new billing integration, a payment promise or evidence that a studio's commercial terms have already been configured.

Choose the feature that changes the decision you are making

For an invented adult workshop business, the most attractive feature may be a branded page, while the hardest daily problem is explaining whether a person has a place. Those are different needs. A custom domain changes presentation and the address a visitor uses; it cannot make an unclear booking state correct. An instructor view serves preparation; an export serves another use of the record. In the product plan these surfaces sit above the seat decision. Before putting them on a shortlist, write which decision each one would improve and what evidence would demonstrate that improvement.

This method can also reveal a feature you do not need yet. A small studio may be able to discuss its intended session policy without a multi-location console, while a larger operation may depend on that planned control. Neither case is evidence of current availability. Record the dependency and compare it with the status ledger. If the fit requires a working dashboard, waitlist or export that is still planned, the right outcome may be to wait. The feature guide is useful when it makes that choice clearer, not when it turns every proposed capability into an immediate reason to sign up.

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.