Contact · Classly.software

Describe one real scheduling shape without sending real participant data.

The early-access conversation is a product fit review. It does not create an account, book a seat, or charge a card.

One address

Email [email protected] with the shape of the scheduling problem.

A useful first note names the kind of adult studio or workshop, approximate number of instructors and locations, common session capacities, recurrence pattern, cancellation window, and the problem with the current process. Say whether the difficult case is last-seat concurrency, duplicate reservations, waitlist ordering, schedule changes, instructor preparation, or customer communication.

Use synthetic names and invented examples. Do not send customer rosters, payment details, health information, government identifiers, access credentials, or exports from another system. Early product fit can be discussed from structure and policy. If protected information ever becomes necessary for a later scoped engagement, transfer and retention terms must be established first.

What the reply should do

Separate what the engine proves from what the planned product still needs.

A useful reply maps the example to capacity-N decisions, identifies any assumptions, and states whether the built core can represent the seat rule. It then names the Classly surfaces that remain planned and avoids promising a date or workflow that has not been scoped. If a different tool or a manual process is the better current answer, the conversation should say that plainly.

This email is not an emergency booking-support channel because there is no live Classly booking service. It cannot recover an account, alter a roster, issue a refund, or restore a class. There is also no sales form, automated nurture sequence, card capture, or self-serve contract on the site. A person answers the product question.

For a focused review, bring one synthetic weekly schedule and one edge case. A six-week invented plan with a full session, a cancellation, a waitlist, and an instructor substitution is usually more informative than a list of every desired feature.

Turn a long wish list into one answerable question

Suppose an invented adult cookery workshop has ten places and receives interest through its existing booking arrangement. The operator's concern is that a person sometimes asks twice and staff cannot tell whether the second message is a new request. A useful first note states that situation and asks how the proposed session model distinguishes an existing place from a new claim. It does not need the real messages, a list of customers or a screenshot containing an account. The fictional count and the repeated-request situation are enough to explain the question and the consequence the operator wants to avoid.

A less useful note asks for booking, marketing, membership, payments, accounting and every possible communication feature at once. Those may all matter to the business, but they do not identify the next decision. Start with the capacity or session question, then name any dependency that would prevent a practical fit. For example, a studio might require a working instructor console before it could evaluate the product operationally. That planned dependency belongs in the conversation. Describing it clearly should lead to a scope decision, not an assumption that the public page already contains a way to turn the feature on.

An awkward example is more useful than a polished success story

For a second fictional cookery session, imagine a cancellation just before the studio's stated deadline while another adult is interested in the full session. Write down what the operator expects to happen to the place, what the interested person needs to know and which commercial question is handled elsewhere. Keep those outcomes separate. Classly's waitlist and notification surfaces are planned, and the site does not process a refund. The point of the example is to identify the desired ordering and explanation, not to invite a real cancellation or demonstrate a payment that this page cannot perform.

Include the objection that makes the example difficult. Perhaps the interested adult is no longer available, or the operator wants to change the capacity but has not settled the policy. Explain that uncertainty directly. It helps distinguish an open business decision from a missing interface. An initial response should be able to say which part matches the proposed session model and which part remains unanswered. It should not manufacture a launch date or a working automation to make the reply sound complete. A useful product conversation can end with a narrower question, a dependency or a decision that the current plan is not a fit.

Keep the message separate from a booking or service request

The published address is [email protected]. Opening it uses your email application; sending shares the content you choose to include. The page does not confirm delivery, generate a case number or publish a response-time commitment. If you need to alter an existing appointment or session in another service, continue using that service's established arrangements. A public product inquiry cannot identify the correct operational record or acknowledge that the change happened. This distinction matters even when the subject line contains a date and the email sounds like a booking request.

Before sending, check that the example still works with invented labels and approximate counts. Remove credentials, account links, payment details and personal circumstances that do not change the scheduling question. If a later engagement needs real information, establish the relevant scope and handling arrangement before sending it; a plain email link is not that arrangement. The immediate output should be a clear product question another person can read without opening an attachment. You can return to the feature guide to identify the current limit or the surfaces guide to explain which future view matters to the decision. No account or seat is created by the exchange.

For a problem with this public site itself, use a different kind of brief: the public page address, the link or sentence involved, and what you expected to see. A report that the Features link opened the wrong guide is answerable without a studio account. A report that a sentence sounds like a live waitlist claim should identify the small passage and the interpretation it creates. Neither needs a screenshot of unrelated open tabs or an export. This separates a correctable public-page issue from a product requirement and from an operational request that belongs to a service already in use.

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.