Surfaces · Slotly.software
A booking link for clients and a small operating view for the people offering time.
Each surface sees the same committed slot through different permissions. The engine exists; the Slotly-branded pages around it remain in development or planned.
Client-facing surfaces
One booking page, one embeddable view, and one clear confirmation state.
The planned booking page is the smallest useful public surface. It presents the practitioner or team identity, a service, real candidate windows, the display time zone, and the terms needed before a request. The embed is the same flow placed inside an existing site, not a second booking engine. Both need an accessible path that works without assuming a mouse or a particular screen size.
After a committed decision, a client-facing status view should show the booked time, current status, cancellation route, and contact posture. It should disclose only the booking the visitor is entitled to see. It should not expose a practitioner’s private calendar or other clients. These Slotly-branded pages remain in development.
Operator-facing surfaces
A solo schedule stays small; a team view adds scope without hiding whose calendar is whose.
The practitioner view is planned to manage bookable hours, services, exceptions, buffers, upcoming bookings, and cancellations for one account. A team view adds resources and scoped administration. It should always identify which calendar produced a window and which adult operator changed a rule. A team member should not gain organization-wide settings merely because they can view their own bookings.
White-label presentation and custom-domain connection are planned configuration surfaces. Calendar connections are also planned and require authorization, refresh, conflict handling, and revocation paths before they can be described as integrations. The help and status views need to distinguish a booking conflict from a delayed notification or an unavailable external provider.
No demo console on this marketing site stands in for those surfaces. An early-access walkthrough can show the built engine boundary and the proposed information architecture, while stating which browser path cannot yet be exercised.
An original adult planning example
Read a booking page from the visitor's side of the desk.
For an original fictional interface review, adult ceramics instructor Jules offers short glaze-sample discussions. Colleague Morgan reads a paper mockup as if encountering the studio for the first time. The mockup says only “Tuesday, 14:00.” Morgan cannot tell which Tuesday, how long the discussion lasts, whether it takes place at the workbench or elsewhere, or whose time is being offered.
The revision identifies 13 October 2026 as the invented date, the studio-local time convention, a twenty-minute sample discussion and Workbench One. It gives a plain description of the meeting arrangement without adding real contact details. These labels make the specimen easier to interpret. They do not turn it into a public booking page, and the handwritten date is not a Slotly availability response.
The review question is whether the visitor has enough information to make the intended choice. It is different from asking whether the visual design looks finished. A polished card with an unexplained time may be less usable than a plain sentence that names the date, resource and duration. The planned booking surface needs to make those meanings visible before a request, rather than rely on the reader's prior conversation with Jules.
The fair objection is that extra labels can clutter a small page. Remove information that does not change the choice, but keep what distinguishes one commitment from another. The output of this paper review is a clearer information requirement. No contact is created, no appointment is held and no private calendar is opened.
An original adult planning example
Give the operator a different question from the visitor.
The operator's paper view concerns a different job: explaining where a displayed time came from. In this separate fictional case, colleagues Remy and Sol offer consultations at two workbenches. Remy is available in the morning and Sol in the afternoon. A combined list headed “Studio times” can hide which person's arrangement produced a window, even if every printed time looks plausible.
For the manual review, mark each candidate with its resource and the availability rule it follows. An afternoon time attributed to Remy's morning-only arrangement is then recognizable as a mismatch. The corrected draft assigns that afternoon candidate to Sol's arrangement or removes it until the source is established. This is an exercise in explaining a list, not evidence of a working team administration screen.
The result needed by an operator is not the same as the visitor's result. The visitor needs a clear choice and its eventual outcome. The operator needs to understand the source of the choice and which change would affect it. A page that merely repeats the public list may leave the operator unable to answer an ordinary question about an exception date or a moved opening period.
Neither a visible name nor a paper division of work proves an access entitlement. This example adds no account role or permission rule. It shows why the proposed operator view needs a clear resource identity while keeping decisions about who may change the real schedule outside the illustration. If that responsibility is unclear, the review keeps it open.
An original adult planning example
An embedded choice and a result page must tell the same story.
Imagine Jules's proposed booking choice placed in a narrow column beside a studio description. That is the embed case: the surrounding page may change, while the identity of the requested appointment must remain understandable. A useful paper check covers whether the resource, full date and duration remain visible when the wider page heading is absent. It does not claim that Slotly currently supplies an embed.
The same review can compare two static result specimens. One says, “Request received,” and the other says, “Booking confirmed.” Those phrases are not styling alternatives. The first describes a request state; the second needs evidence of the booking decision. An illustrator cannot choose the more reassuring phrase simply because it fits the available space.
A conflict specimen should identify that the requested place was not obtained. It should not keep a large “Confirmed” heading above smaller refusal text. Similarly, a delayed-message explanation should not imply that the booking itself has been repeated. These are product-review requirements drawn from the separation between decision and notification, not a claim that the proposed status surfaces are operating.
The review ends with three distinct artifacts: the information a visitor needs before choosing, the explanation an operator needs to manage the source, and the result language supported by the decision. If a paper mockup cannot make those distinctions, its next task is clearer writing. It has no basis for requesting real bookings merely to make the demonstration appear complete.