Privacy · Slotly.software
Keep real calendars and client identities out of an early-access conversation.
The marketing site explains the planned product. It is not the future booking service’s data boundary and should receive no identifiable appointment information.
This public website
No booking form, calendar connection, account, checkout, or advertising profile.
Slotly.software currently serves product documents and mail links. It cannot publish availability, accept a booking, cancel a slot, connect an outside calendar, take payment, or create a practitioner account. The site sets no marketing cookie and includes no advertising tracker. Ordinary short-lived request logs may contain the technical facts needed to operate and protect a public web service.
An introductory email should use an invented calendar and synthetic identities. Do not send a private calendar feed, provider authorization token, client contact list, access credential, payment detail, or confidential appointment note. Email is not a defined booking-data intake or a replacement for agreed transfer, access, retention, deletion, and incident procedures.
A future booking service
Availability, bookings, connections, and operational evidence need distinct purposes.
A working service may need account and resource configuration, time-zone-aware hours, exception dates, service definitions, a limited client identity and contact route, booking status, cancellation history, and operator actions. It should collect the minimum fields needed to perform the requested scheduling job. The client-facing page must not disclose the practitioner’s private calendar or another client’s appointment.
External calendar connections require explicit authorization, scoped tokens, refresh and revocation handling, and a clear account of which event fields are read. Conflict subtraction should not copy an outside calendar into a second general-purpose archive. Support access, exports, logs, and backups need bounded permissions and retention rules.
These are requirements for a future product, not claims about a deployed Slotly environment. The product does not sell booking information or use it for advertising. No certification is claimed. Provider lists, retention periods, contractual privacy terms, and deletion commitments must be documented before a customer surface receives identifiable booking data.
An original adult planning example
Build the example from a scheduling question, not a real calendar.
For a fictional adult woodcraft studio, the question is whether a forty-minute appointment conflicts with a later start on the same bench. The evaluator does not need to copy an actual week to explain it. They can begin with Bench A, an invented date, a 10:00–10:40 interval and another proposed interval beginning at 10:30. Those facts expose the timing question without connecting it to a real client's visit.
The first draft says, “I will remove the names from last week's export.” The better planning choice is to create a new example from scratch. A copied schedule can retain distinctive descriptions, contact information or event links even when one obvious name is gone. This is ordinary advice for preparing a product question, not a claim that Slotly provides redaction, anonymization or an import sanitizer.
The output is a small invented worksheet describing the resource, intervals and expected relationship between them. Its purpose should be written at the top: “Explain a possible overlap; no actual appointments represented.” That helps the next reader understand why names, messages and the rest of a working calendar are absent rather than trying to fill those blanks from memory.
The reasonable objection is that a synthetic example may miss some complexity. Add the particular complexity needed for the question, such as a second resource or a clearing interval. Do not add a real person's schedule merely to make the illustration look convincing. If the question cannot be discussed without confidential operational material, this public marketing conversation is not a defined transfer process for that material.
An original adult planning example
Each detail in the note should have a stated job.
In a separate fictional review, colleagues Robin and Lee prepare a question about a full group demonstration. Their invented worksheet contains a capacity of four and four occupied places. That is enough to explain the quantity condition. Adding the names or reasons for attending would not change the scheduling arithmetic and would distract from the question they are asking.
They then add a second line with capacity four and three occupied places, explicitly labeled as a different snapshot. The difference now has a clear purpose: compare a full state with a state that has one place left on paper. It is not a claim that a real place remains available. A later booking decision still needs its own current result.
This purpose check is a human editing procedure. The page does not inspect an email, remove fields automatically or guarantee that every possible disclosure has been identified. Robin and Lee remain responsible for deciding what they put in their own draft. The exercise simply shows how a narrower question often needs less contextual material to be understandable.
A useful stop condition is finding a detail that the writer cannot explain. If an access link, a copied event description or a contact address appears in the draft but does not help state the invented scheduling case, remove it from the example rather than asking the recipient to ignore it. Removing a detail from one's own draft does not establish deletion from another system or a recipient's copy.
An original adult planning example
A website, an email draft and a booking service are different contexts.
The current page presents documents and a mail link. Clicking that link can take a reader into their own email application, where a separately authored message may be composed. The website's description does not establish that application's handling, delivery behavior or retention. It also does not make the email an appointment record inside a Slotly service.
For the fictional studio evaluation, a careful message therefore stays with the synthetic case and its single question. It should not imply that the website has accepted an upload, connected a provider account or taken responsibility for transferring a working calendar. Those are different operations, and this page supplies none of their controls.
The reply can be summarized without attaching a real calendar: “We discussed an invented overlapping-window case; the product explanation addressed the rule; the customer-facing workflow remains unavailable.” That sentence preserves both the subject and the limit. It does not claim a deletion guarantee, an access entitlement or a contractual privacy arrangement.
The fair question is whether this caution prevents a useful discussion. The examples above show a practical route: select the decision, invent only the facts it needs, and retain the limit in the outcome. If the next step requires identifiable operational information, stop treating the marketing page as the place to provide it. A separately established process would need to answer that question; this page does not invent one.