Getting started · Slotly.software
There is no sign-up form on this page. That is on purpose.
The public booking page — the link, the embed, the white-label overlay — is in development. A sign-up form that cannot create a working booking link would be a form that misstates what it does, so this page does not have one.
What it has instead: a short conversation about how you actually book people, and an honest answer about when your particular use of it will be ready. The engine underneath — the no-double-book guarantee, the capacity lock, the overlap predicate — is built and exercised in the shared core this whole family sits on.
What actually happens
Three steps, and you can stop after any of them.
✓1 — Tell us what you book
One link for one calendar, or a small team sharing a few? A short note to [email protected] with how you book now, and what goes wrong with it, is enough to start.
✓2 — See what is built, and what is not
We walk through the engine that exists — the no-double-book guarantee, the capacity lock, the overlap rejection — and name plainly what is still in development. You should come away able to repeat back what is real and what is not. The full inventory is on the help page.
✓3 — An early-access spot, no commitment
If it fits, we put you on the early-access list so you hear first when the booking page and the pricing are live for your case. No card, no contract, no account created on a web page.
What starting does not involve
No card, no charge, no contract signed on a web page.
There is no live checkout on this site. Reserving early access does not create a payment, does not store a card, and does not commit you to anything — it starts a conversation. The pricing shown on the main page is the planned launch shape, not a live purchase option; no card is charged and the payment seam is switched off.
Prepare one synthetic launch dossier
Describe the practitioner, the offered service, and the calendar rule before discussing screens.
Begin with one fictional adult practitioner and one service that has a fixed duration. Give the practitioner a display time zone, ordinary weekly hours, a preparation buffer, a closing buffer, and two exception dates. Add a second service only if its different duration exposes a real scheduling question. The dossier should fit on one page. It is a decision sample, not a replica of an existing client database.
Write down what the public visitor must know before requesting a time: service name, duration, location or meeting posture, displayed time zone, cancellation terms, and the contact fields actually necessary for confirmation. Separate those public facts from the practitioner’s private calendar details. A useful booking surface reveals candidate windows without exposing why another interval is unavailable.
Define the operator roles even for a small team. Identify who configures hours, who may add an exception, who can review upcoming bookings, and who can cancel or correct one. If a solo practitioner holds every role, record that explicitly. The model should not assume that one-person authority will remain appropriate when a second calendar or administrator is added.
Keep the identities synthetic. Use names such as Practitioner A and Client One, invented email addresses, and dates chosen for the exercise. Do not connect an external calendar, paste a private event feed, or send access tokens during an introductory review. The built engine can demonstrate a slot decision from explicit windows without inheriting real appointment information.
Rehearse the booking lifecycle
Exercise confirmation, collision, overlap, cancellation, and a stale view in a known order.
First request an open synthetic window and preserve the committed result. Confirm that the returned time, resource, status, and display time zone match the selection. Then submit a second live booking for the same resource and window. The expected outcome is an already_booked conflict from the database boundary, with no partial second reservation and a clear instruction to refresh availability.
Next use a capacity example only if the intended service genuinely allows several places in one window. Fill the synthetic capacity, then request one more place and expect slot_full. Keep that case separate from exact uniqueness so an operator can tell whether the collision concerns one exclusive window or a multi-place count. The interface should not translate both reasons into an unexplained apology.
Create a partially overlapping interval for the same practitioner and verify that the overlap predicate refuses it. Then cancel the original synthetic booking through the intended lifecycle and request the released window again. The history should still explain that the first booking existed and was cancelled; freeing capacity must not mean erasing the prior decision.
Finally, model a browser that displayed availability before another request committed. Its later submission should receive the current database answer rather than the optimistic state it saw earlier. This stale-view rehearsal is more useful than repeatedly booking uncontested windows because it tests the exact moment when a polished calendar can mislead a client.
Decide whether the first operating slice is ready
Use entry, stop, handoff, and rollback criteria instead of a feature wishlist.
Entry criteria should name the configured service, time zone, hours, exceptions, operator, synthetic booking identities, and current Slotly surface available for demonstration. If the workflow depends on two-way calendar synchronisation, a custom domain, white-label presentation, group polling, self-serve setup, or billing, mark that dependency before the review. Those pieces remain planned or in development and cannot be substituted with screenshots.
Stop when an essential decision cannot be represented or explained. A missing operator permission, ambiguous time-zone conversion, unsupported calendar connection, unexplained conflict, inaccessible public step, or cancellation state that cannot be reviewed is evidence that the slice is not ready. Recording a stop condition is more valuable than continuing through an easy path that avoids the blocker.
The handoff note should distinguish configured inputs, committed outputs, refusals, notifications, and actions owned by a person. A notification can be late while the booking remains confirmed, so delivery status must not replace booking status. The note should also identify the existing scheduling procedure that remains authoritative during early access. No demonstration should leave a practitioner unsure which calendar governs tomorrow’s appointments.
Plan rollback before widening. Decide who closes the exercise, removes synthetic records, revokes any temporary access, and records unresolved questions. Add another service, practitioner, location, or administrator only after the first slice is understandable under both successful and refused requests. A conversation can reserve interest in early access; it does not authorize a production migration, create a paid subscription, or guarantee a launch date.