Privacy · Classly.software

The safest early-access roster is a synthetic one.

This public site is an explanation of the product plan. It is not the product’s future booking-data boundary and should receive no identifiable attendee information.

The public website

No booking form, roster upload, customer account, or advertising profile.

Classly.software currently renders product information and mail links. It does not accept a booking, create a studio, take payment, upload a roster, or expose an attendee search. It sets no marketing cookie and includes no third-party advertising script. This page does not establish a retention period for the hosting or email systems used around it.

Contact by email with a synthetic adult-studio example. Do not include attendee names, contact details, payment information, health notes, credentials, or another provider’s export. Email is not a substitute for a defined product intake with access, retention, deletion, and incident procedures.

A future booking service

Occurrence, booking, contact, and audit data need distinct purposes and retention.

A functioning adult-studio service may need occurrence details, an identity key, limited contact information, booking status, timestamps, cancellation history, and operator actions. The public roster should never expose the full attendee set. Instructor and studio views need scoped authorization, and an export must preserve the same scope. Payment data should remain with the chosen payment processor rather than becoming a general field in a scheduling database.

Waitlist history needs enough evidence to explain ordering and promotion without retaining unrelated customer detail. Notifications need delivery state but should not become the source of truth for booking. Support access needs an auditable reason and a time boundary. Backups and logs need deletion rules consistent with the service agreement.

Those controls are product work, and this page does not claim they are deployed. Classly does not sell personal information, use roster data for advertising, or claim FERPA, COPPA, SOC2, or VPAT certification. Specific subprocessors, retention periods, and contractual terms must be documented for an actual service before identifiable booking data is collected.

A count can explain the conflict without identifying the group

Use a fictional adult photography workshop with six places to explore a full-session question. The useful facts are the capacity, the number of places already represented and whether a new request repeats an existing fictional identity. None of those facts requires an actual customer name, address or booking reference. Start with counts, then add an invented label only when it changes the decision being discussed. The output should be a small example another reader can understand on its own, without a roster attachment. Calling an export a sample does not make its real participants necessary to the product conversation.

Now consider an adult who cannot attend after the fictional studio changes the date. The scheduling question is how the original commitment and proposed change are explained. The person's private reason for being unavailable usually adds nothing to that question. Describe the objection without the personal circumstance. That keeps an initial evaluation focused on the product requirement and avoids creating a second informal account of a customer's situation. The example remains a manual discussion of a planned surface; it does not cancel a booking, update an attendee record or establish the handling rules of a future service.

Build the example from scratch instead of taking a real record and changing only its name. An original date, booking reference, unusual note or copied contact field may still point back to the real interaction, even when the visible name looks invented. The six-place workshop does not need that history. Choose a new date, use simple labels and describe only the capacity question. The resulting example is easier to share for a product discussion because its purpose and contents are apparent to the next reader. It also prevents an evaluation attachment from quietly becoming a second customer record that someone later has to manage.

Keep the purpose of each record visible in the discussion

A future adult booking workflow could involve several distinct records: the occurrence being offered, a request, a confirmed place and an account of a later change. They answer different questions. An occurrence describes the session; a booking describes a place in it; a message concerns communication. In the fictional workshop, write those purposes beside the sample fields before discussing a complete system. If a proposed field has no clear job in that example, leave it out of the initial brief. A long list of possible information is not evidence that all of it is needed for a scheduling decision.

This exercise also helps when someone asks for an export. State the job the exported view would serve and which part of the fictional session record is relevant. Do not assume that a button labelled export should include every field the future product might hold. Roster export is planned, and this page does not provide one or establish a working permission model for it. The useful result is a bounded question for later review, not a new access procedure. Any operational arrangement would need evidence about its actual users, scope and handling before real information could be treated as appropriately managed.

A public explanation cannot supply an operational privacy agreement

Reading this page and sending an email are different actions. The page renders product information; the contact link opens the reader's mail application. A message contains whatever the sender chooses to include, and the absence of a web form does not prove that email leaves no copies. This page does not promise a deletion deadline, a log-retention period or a special channel for customer records. If an evaluation later depends on such terms, establish them for the actual proposed engagement before sharing the information those terms would govern. A marketing description is not a substitute for that decision.

The same distinction applies to a future instructor or studio console. Proposed limits on a view are requirements, not evidence that the corresponding access control is already deployed. The examples here stay adult-oriented and introduce no minor enrollment or consent mechanism. A different audience or a requirement involving personal records cannot be silently folded into the fictional exercise. Keep it separate and obtain the relevant review before treating it as a supported workflow. The immediate purpose of the privacy guide is practical: help someone explain a session problem with less information and identify the operational questions still unanswered before a working service is considered.

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.