Surfaces · Classly.software

Different jobs deserve different views of the same committed session.

A customer needs a clear seat state. An instructor needs a working roster. A studio operator needs policy and history. Combining those permissions into one dashboard would make every role harder to trust.

Customer surfaces

Discovery, session detail, booking status, and self-service cancellation should agree.

The planned public schedule groups available sessions by date, type, instructor, and location without pretending that a calendar cell is the booking itself. A session page explains capacity state, duration, location, accessibility notes supplied by the studio, price information supplied by the studio, booking window, and cancellation policy. An adult can then request a place and receive a committed status.

A customer status page should show only that person’s booking or waitlist entry. It needs a stable cancellation path and a plain account of what happens next. It should not expose the roster or allow a guessed URL to reveal other attendees. A custom domain and studio styling are planned, so the booking relationship can remain visibly with the studio.

Staff surfaces

Operators configure policy; instructors prepare for the session.

The studio console is planned to manage session types, individual occurrences, instructors, locations, capacities, windows, and cancellation rules. It should show why a request was confirmed, refused, or waitlisted and preserve the relevant event history. Multi-location controls need explicit scope so one manager does not accidentally edit another location’s occurrence.

The instructor view is narrower: upcoming assigned sessions, the practical roster, attendance state, and studio-provided notes needed to run the class. It should not inherit billing administration or organization-wide customer search merely because the instructor works for the studio. Export is planned and must reflect the operator’s scope at the moment it is generated.

Support and status surfaces complete the picture. Operators need to distinguish a capacity refusal from a delivery delay, and customers need the committed booking state even if email is late. None of these branded interfaces is represented as live on this page.

Read one workshop as a visitor and as its organizer

Use a fictional adult printmaking session to sketch two views on separate sheets of paper. The visitor's sheet answers whether the date, duration, location and session description fit the visit they are considering. The organizer's sheet answers how many places are intended, which policy applies and what still needs preparation. Both refer to the same occurrence, but they serve different decisions. Adding every field to both sheets would make the visitor sort through administrative work and would obscure the organizer's next action. The planned Classly surfaces need that distinction even when the information begins with the same session record.

Ask a second reader to explain the offer using only the visitor's sheet. If they cannot tell which evening they would attend or whether the displayed state is merely an example, the public explanation needs work. Then ask the organizer what they would do if the session becomes full. The answer should identify the planned waitlist boundary rather than assume a working queue is hidden behind the picture. This readback produces a useful output: the minimum facts each role needs for its immediate decision. It requires no roster, account connection or live booking, and it does not prove an access mechanism has been built.

A simple disagreement makes the exercise useful: put a revised start time on the organizer's draft while leaving the old time on the visitor's draft. Both pages may look tidy, yet they no longer describe the same offer. Ask the reviewer to identify the discrepancy using the occurrence facts, without consulting a participant list. The proposed surface needs a way to make the applicable version understandable. A different role, a different layout or a different studio color does not excuse contradictory session details. This comparison reveals a content requirement before anyone mistakes a collection of attractive screens for a coherent booking experience.

Give the instructor a preparation question, not the whole business

In the same fictional printmaking example, the instructor needs to prepare a room for an expected group. A count, the specific session, the intended materials and studio-provided preparation notes may explain that job without reproducing every administrative detail. Sketch the task first and only then discuss a future view. A list of all possible customer fields is not a substitute for understanding what the instructor must do before the session begins. This is an adult evaluation scenario, and the instructor dashboard remains planned; no actual attendee information should be copied into the sketch to make it feel realistic.

Now change the instructor while keeping the session date. The new person needs to understand the assignment and preparation, while the operator needs to understand what changed. That is a different handoff from changing the date for every participant. An objection such as everyone should see everything because the studio is small does not answer either task more clearly. Use the paper example to name the information needed for each decision and the questions still open about a future working interface. The exercise defines requirements; it does not grant a role, create access or assert that the planned permissions are already enforced.

A returning visitor needs their outcome to make sense

Imagine the fictional participant returns to the session page after discussing a place with the studio through its current process. They may be trying to answer a very small question: is there a recorded place for this occurrence, or did they only express interest? A future status surface needs language that makes those states distinguishable. A friendly confirmation-shaped message is not enough when no booking has been committed. The current marketing site performs neither action, so its illustration should remain visibly an explanation. It must not invite a reader to mistake a page visit for a completed reservation.

A delayed email creates another useful test of the proposed view. What would the participant rely on to understand the booking, and what would the operator inspect to understand the communication? Those outcomes should be described separately. The fact that a message is discussed does not establish delivery, and a different studio logo would not establish that a status is current. Finish the sketch with the exact question each side can answer and the unresolved action each side must still take. That is more useful than a single all-purpose dashboard, and it preserves the distinction between planned surfaces and a functioning customer service.

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.