Help · Slotly.software

Everything about booking a slot, on one page.

This is one thick help page with deep sections rather than a dozen thin ones, because a route that has nothing to say is worse than no route. Jump to what you need.

On this page

Five sections.

✓How booking works

Set hours, share one link, and the database — not the booking code — decides who got the slot.

✓What a conflict returns

The two 409s you can actually get, what each means, and why they are retry instructions rather than apology screens.

✓What is built, what is not

The honest inventory: engine mechanics that exist, the slotly.software surfaces in development, and how money and AI are off.

✓Your name and your domain

White-label at Team and a custom domain on every tier — both planned, and stated as planned.

✓Full FAQ

Cost, the “slotly” name, the sibling products, and whether you can use it today.

How booking works

Set hours, share one link, and the database decides once.

Step 1 — Publish the slots

An operator sets working hours, a slot length, and how far ahead someone can book. That is the entire setup. No event-type builder, no branding wizard to click through first.

Step 2 — Share one link

One link, one booking page, showing only the slots that are actually free right now. A client picks a time and confirms. If the operator sent a short list of candidate times instead, the client picks the one that works and that pick becomes the booked slot.

Step 3 — The database, not the booking code, decides who got it

The transaction that books a slot takes a lock on that slot’s live-booking count before it trusts the number, so the count cannot go stale between being read and being spent. Separately, a uniqueness rule on the time window lives in the database itself, so a second live booking for an already-claimed window cannot be written at all. Neither rule sits in the booking code, which is why a future code path cannot forget to apply one. Whoever loses the race gets a clean 409 they can retry — not a double-booked morning.

The two rules in step three are the whole reason a slotly link is different from a shared spreadsheet. A lock is taken on the slot’s live-booking count inside the booking transaction, so the number cannot go stale between being read and being spent; and a partial-unique index on the resource and time window — restricted to live bookings — means a second booking on an already-claimed window cannot be written at all. Both live in the database, not the booking code, so a future code path cannot forget them.

What a conflict actually returns

Two 409s, and both are retry instructions.

✓409 already_booked

Someone else’s booking for that exact window landed first. The partial-unique index in the database caught it — not a check the application performs and can lose a race on. Refresh and pick another open slot.

✓409 slot_full

Only relevant where a slot holds more than one booking. The live count was taken under a lock inside the transaction and was already at capacity when yours arrived — so nothing was over-filled.

What is built, what is not

The honest inventory.

✓Built — in the shared engine

The no-double-book partial-unique index, the per-slot capacity count under a lock, and the overlap-rejection predicate. Built and unit-tested in the shared core this whole family sits on — not on any slotly.software deployment, because there is none.

✓In development — the slotly surface

The public booking page and embed, the white-label overlay, the native group poll (a shared build item with whenly.software), and two-way Google/Microsoft calendar sync plus a CalDAV server. These are the parts with the word slotly on them.

✓Display-only — the pricing

Plus / Team are the planned launch figures. Nothing on the site can take money: there is no payment processor connected to these tiers, no card is charged, and there is no live checkout — the billing seam exists in the codebase and is switched off.

✓Off — money and AI

No live checkout, no card charged. No AI decides who gets a slot, and none is claimed. Slotly.software does not hold FERPA, COPPA, SOC2, or VPAT certification.

Your name and your domain

White-label at Team, a custom domain planned on every tier — both stated as planned.

The plan puts white-label — your own name and colours, the slotly.software mark removed — at the Team tier, priced per seat, rather than behind a custom Enterprise contract the way several tools in this category gate it. The overlay is designed, not yet built.

A custom domain is planned to be included on every tier, the entry Plus plan among them. No slotly.software page serves a customer domain today and the connect-your-domain flow is designed but not built — so read both of these as a commitment about how we intend to package it, not a switch you can flip now. The pricing section states the tiers; there is no live checkout.

Full FAQ

The questions people actually ask

What makes slotly.software different from dibs.software or appointments.software? Aren't they the same tool?

They run on the same shared fixed-slot booking engine, but they are three separate products built for three different buyers. Appointments.software is built for a business with more than one calendar -- multi-staff, multi-location, resource overlap. Dibs.software is a brand-forward “call dibs on a time” front door for a consumer-register solo/small-team buyer. Slotly.software is the plainest of the three: no metaphor, no platform pitch, the flattest possible description of the thing -- a slot, booked -- built for a single practitioner or a very small team who wants the fewest possible words between sharing a link and it being booked, and who eventually wants their own name on the page rather than a personality-forward brand.

Is the entry plan really uncapped, or is there a booking limit hiding somewhere?

As planned, no monthly booking limit gates the Plus plan -- a practitioner who books thirty clients a month and one who books three hundred are on the identical plan. This is a pricing commitment we are stating plainly here, not a live self-serve signup today: the plan as described is planned, not yet shipped as a working signup flow.

Is white-label really available below Enterprise, or is that the usual asterisk?

As designed, white-label -- an operator's own name and colors on the booking page, the slotly.software mark removed -- ships at the Team tier, priced per seat, not gated behind a custom Enterprise contract. It is not live today: the overlay is designed, not yet built. When it ships, the price and the tier it ships at are the ones stated here.

If the product is this small, is the no-double-booking check just an if-statement?

No, and that is the one place we would rather be boring than small. It is a partial-unique index: a UNIQUE constraint on the resource and time window, restricted to bookings whose status is live, so a cancelled booking frees its window and a live one cannot be duplicated. The second concurrent write fails at the database with a unique violation, which the engine turns into a 409. The distinction matters because an if-statement can be raced and a constraint cannot — and it is the same constraint every other booking caller on this engine sits behind, so it is exercised well beyond this brand.

Is the group-poll feature the same thing as whenly.software?

No. Whenly.software is a dedicated find-a-time product -- the overlap of many participants' free windows across a real calendar substrate. Slotly's planned group-poll is a narrower, single-purpose feature inside a fixed-slot booking flow: a short list of candidate times an operator offers before a slot is claimed. The underlying poll-UI build item is shared between the two products, but the products themselves are not the same tool, and neither is a feature of the other.

Do you skim a commission on bookings, or meter by seat below Team?

No commission skim on any transaction, at any tier, as planned. Metering by seat applies only at the Team tier where white-label is priced per seat; Plus is per-account, not per-seat.

Can I actually buy this right now? What happens if I click something in the pricing table?

Nothing happens, because there is nothing wired to it. The prices are the planned launch figures, this is not a live checkout, no card is charged, and there is no payment processor connected to these tiers — the only thing any button on this page does is open an email. If you want in early, that email is the mechanism, and we would talk through what your practice needs before anything is ever billed.

Is the “slotly” name final?

Not yet, and we say so here rather than pretend otherwise. Slotly carries the highest name-collision risk of any mark in this family internally, and a formal trademark/registry check is required before brand launch. That check is a pending process step, not a reason this front door isn't built today -- if the name changes before launch, the product and pricing described here do not.

What can we actually see or use right now?

Honestly: not a booking page with your name on it. What exists is the engine — availability publishing, the capacity guarantee, the uniqueness constraint, the overlap-rejection predicate — built and unit-tested in the shared core this whole family of products is assembled on, and already folded into other booking callers inside the fleet rather than written for this page. What does not exist yet is everything with the word slotly on it: the public booking link, the embed, the white-label overlay, the group poll, the calendar sync. If you want to see the difference concretely rather than take a web page's word for it, ask, and we will walk you through what is built and what is not.

Will a custom domain cost extra, or is it an upsell like everywhere else?

As planned, no — a custom domain is meant to be on every tier, the entry Plus plan included, where most single-link tools paywall it and reserve full white-label for an Enterprise contract. Removing the slotly.software mark and applying your own name and colours is one paid tier up, at Team, not a sales call. Both are planned packaging, not live features: no slotly.software page serves a customer domain today, the connect-your-domain flow is designed but not built, and there is no live checkout on this page.

Where do I go for setup help, or to see exactly what a booking conflict returns?

/help — one page covering how it works, what a conflict actually returns (a 409 already_booked vs. slot_full), what is built versus in development, and the full FAQ. It is one thick page, not a pile of near-empty stub routes.

What the engine decides

A slot becomes unavailable through one committed database decision.

The shared fixed-slot engine treats a booking as a claim on a resource and time window. A partial-unique database index prevents a second live booking from occupying the same window. When a slot permits capacity above one, the live count is read while the slot is locked inside the booking transaction, so two callers cannot both spend the last place. A separate overlap predicate refuses a booking whose time window conflicts with another live booking for that resource.

Those mechanisms are built and unit-tested in the shared core. They are not evidence that a Slotly-branded service is operating. The public booking page, embeddable view, account setup, white-label overlay, custom-domain connection, group poll, calendar synchronisation, notifications, and billing surface remain in development or planned. This site offers documents and an email link; it cannot create a booking or account.

A useful interface must preserve the engine’s answer. It can show open times before a request, but it cannot promise the place until the transaction commits. An already_booked conflict means another live booking owns the window; slot_full means the capacity count was already spent. The interface should refresh availability and invite another choice rather than disguise either response as a server failure.

Cancellation changes which bookings count as live, so a properly cancelled booking can release its window. That does not justify deleting history or rewriting the prior decision. A future operator view needs the booking status, actor, and timestamps required to explain why a slot was open at one moment and unavailable at another. Notifications follow committed changes and must be retryable without creating another booking.

What the product promises and refuses

Plain packaging is planned; money, AI, and availability claims stay off.

The planned Plus tier has no monthly booking cap. A custom domain is planned on every tier, including the entry Plus plan. The white-label overlay is planned at Team rather than hidden behind an Enterprise sales call. The planned tiers take no commission from a booking. These statements describe intended packaging for a surface that is still being built; they are not live subscription terms and cannot be purchased from this site.

There is no checkout, payment form, provider charge, card storage, automatic renewal, or commission collection here. Pricing on the overview is display-only. There is also no AI system choosing times, ranking clients, composing messages, or resolving a collision. Availability comes from explicit schedule data and database rules. A group poll and external-calendar connections are planned and must not be mistaken for working integrations.

Slotly makes no customer-count, adoption, outcome, uptime, or certification claim. It does not present testimonials and does not claim FERPA, COPPA, SOC2, or VPAT certification. The name remains subject to trademark and registry review before brand launch. Early access means a conversation about fit and sequence, with synthetic examples where useful, not a hidden production tenant.

Before a surface can be called available, its full path needs to work: account scope, resource configuration, time-zone handling, availability publication, booking and cancellation, conflict presentation, notification retries, support access, operational logs, and deletion or retention rules. A green engine test establishes the decision law. It does not establish all of those surrounding responsibilities.

Operational review also needs a recovery case. A schedule change should preserve enough history to explain which time a client originally accepted. Revoking an external-calendar connection should stop future reads without corrupting already committed bookings. A support reproduction should use synthetic identities and a narrow account scope. Exports and backups should follow the same deletion and access decisions as the primary store. None of this work makes the booking rule more complicated; it makes the service around that rule accountable when an ordinary mistake, retry, or provider outage occurs.