How it works · Slotly.software
Publish the hours, request one time, and let the database decide once.
The plain flow has three boundaries: configured availability, an atomic booking decision, and a committed status that later screens and messages must preserve.
Before the link is shared
Define the resource, hours, duration, buffers, and exceptions explicitly.
A practitioner begins with the calendar being offered, the time zone in which its hours are defined, the service duration, any preparation or travel buffer, and the dates that override the usual week. A small team repeats that setup per bookable resource rather than merging everybody into a single vague calendar. The planned setup should preview the exact windows generated before anything becomes public.
The public link then shows candidate windows derived from those facts. It should identify the service, duration, time zone, location or meeting posture, and cancellation terms before a client requests a time. External-calendar conflict subtraction is planned, not live; until it exists, Slotly cannot promise that an outside event automatically removes a window.
At booking time
The browser requests a slot; the database returns the authoritative result.
The request carries the selected resource and exact time window. The engine checks overlap, locks the relevant capacity count, and attempts the live-booking write under its uniqueness constraint. A successful commit owns the window. If another request arrived first, the response identifies the conflict without creating a partial reservation.
A future confirmation view must repeat the committed time and time zone and provide the cancellation route. Cancellation should change live status once, preserve the history needed for support, and release capacity according to policy. A notification may describe that result, but it cannot be the source of truth. Retrying delivery must never retry the booking decision.
The group-poll idea is a separate planned lane. It would collect several people’s stated availability before creating a bookable outcome. It does not weaken the final slot transaction and is not a working poll on this site today.
An original adult planning example
Work out one morning before describing an open slot.
Take a fictional adult modelmaking studio, Finch Bench. Dana offers individual paper-model consultations from 09:00 to 11:00 in the studio's local time. Each conversation lasts thirty minutes, followed by ten minutes for clearing the work surface. This is an invented planning exercise on paper. No calendar is published, and none of the times below is available to book through this page.
Dana's first note says, “Four half-hour appointments fit into two hours.” The arithmetic ignores the clearing time. For this exercise, clearing must finish within the offered morning. The revised list is 09:00–09:30, 09:40–10:10 and 10:20–10:50, with clearing ending at 09:40, 10:20 and 11:00 respectively. The result is three proposed conversations, not four. It follows from the stated human arrangement rather than a demonstrated Slotly availability generator.
The useful inputs are now visible: one named work surface, one date still to be chosen, a local time convention, a thirty-minute service, a ten-minute gap and a closing boundary. Dana should settle the missing date before calling any window a specific appointment. A time-of-day pattern is useful preparation, but it is not an offer tied to an actual day.
A reader might ask why the example is so particular about the final ten minutes. Because a different arrangement produces a different answer. If clearing may continue after 11:00, say so; do not silently use that assumption to squeeze in another conversation. The purpose of the exercise is to expose the rule that creates the candidate list, including the rule an attractive list might otherwise conceal.
An original adult planning example
Separate seeing a time, requesting it and holding it.
Continue the same fictional morning with two adult visitors, Visitor A and Visitor B, both interested in the 09:40 conversation. The paper list shows a candidate time to each person. That shared view does not establish two reservations. Nor does it determine who has a place merely because one person read the list earlier. Looking at availability and obtaining a committed booking are different events.
The built-core distinction described on this site is relevant here: an accepted booking decision and an already_booked refusal cannot be presented as the same result. In an evaluation, ask to see both outcomes identified plainly. The paper exercise can state the expected distinction, but it cannot prove which request a running service accepted because no Slotly booking service is executing these requests here.
The first handoff draft says, “Both visitors selected 09:40, so both are confirmed.” A faithful revision says, “Both requested the same candidate; each needs the authoritative result of their own request.” If one result establishes the committed booking and the other reports a conflict, only the first supports a booked-time statement. A stale list should not be used to overrule the refusal.
The objection is that this sounds less welcoming than immediate confirmation. A clear outcome is more useful than reassurance that must later be withdrawn. In the proposed experience, the unsuccessful request needs a fresh choice and a readable explanation. This marketing example supplies neither a working refresh control nor an alternative reservation; it identifies what those results must mean.
An original adult planning example
A changed appointment is a new scheduling question.
Now Dana learns that Visitor A wants a fifty-minute discussion rather than the thirty-minute consultation used in the plan. Simply changing the service label leaves the old arithmetic in place. A 09:40–10:30 conversation with ten minutes of clearing reaches 10:40, across the proposed 10:20 start. The original candidate list cannot justify both arrangements for the same work surface.
A useful revision records what changed: requested duration, required gap and the later candidate affected by the extension. It does not describe the longer conversation as accepted. The human planning output is a revised question for the operator: retain the original duration, find another suitable window, or change the offered morning through the established process. The example does not choose among those options for the visitor.
Keep cancellation equally distinct. A person's message asking to cancel is an input to a process; a record of a completed cancellation is an outcome. An evaluation should establish how the current state is represented before treating a place as released. This page's description of shared booking mechanics does not supply a customer cancellation link or prove that a particular place has reopened.
The final review is short: which resource, which date and time, which duration, which current state, and which unresolved change? If any answer rests only on the first draft, retain the uncertainty. That is the point where the manual exercise stops and evidence from an actual authorized booking process would be required.