Contact · Slotly.software

One synthetic calendar is enough to ask whether the product fits.

The early-access conversation should produce a precise account of what the engine can decide and which Slotly surfaces remain unavailable.

One useful note

Describe the schedule shape, the collision, and the outcome you expected.

Email [email protected] with the kind of appointment you offer, common duration, time zone, number of bookable calendars, working-hour pattern, buffers, and how exceptions are handled. Say what fails in the current process: an exact double-book, a partial overlap, a stale open time, a cancellation that did not release capacity, or a team permission that is too broad.

Use a synthetic week and invented client names. Do not send calendar credentials, access links, payment information, private correspondence, or an identifiable client export. The booking law can be evaluated from times, resources, status, and expected outcomes without exposing a real person’s schedule.

What the reply should separate

Engine fit, surface status, integration work, and packaging are different answers.

A useful response can explain whether the shared engine represents the fixed-slot rule and which conflict reason should result. It should then identify the Slotly page, account setup, or calendar connection still needed for the complete workflow. A built predicate does not create an embeddable booking surface, and a planned price does not create a checkout.

If a native group poll, external-calendar connection, white-label overlay, custom domain, payment path, or self-serve signup is essential, state that requirement. Those surfaces remain planned or in development. The answer may be that the current product is not ready for the case.

The mail link opens the visitor’s own email application. The website does not submit a form, store a lead, prove delivery, promise that a mailbox is continuously monitored, or establish a response time. It creates no account and reserves no slot.

An original adult planning example

Give the recipient one question they can actually answer.

For an original fictional inquiry, adult workshop organizer Priya describes one demonstration table with appointments between 14:00 and 16:00, measured in a stated local time convention. A visit lasts twenty minutes and the table needs ten minutes of clearing afterward. Priya is not sending a real calendar. These invented facts are enough to explain the scheduling question without supplying participant identities or appointment notes.

The first email draft says, “Can Slotly handle our bookings?” The revised draft asks, “For one resource, can the described rule distinguish an occupied 14:00–14:20 window from a request that overlaps it at 14:10–14:30? Which Slotly surface can demonstrate that result?” That separates the decision model from the interface requirement. It is a more useful question than a broad request for reassurance.

The desired response is an account of those two things, with any unavailable surface named explicitly. A source explanation can address the rule without proving that a client can open a working booking page. Priya should retain that distinction in the resulting note rather than summarize the entire discussion as “bookings supported.”

The objection is that a potential customer should not need to write a technical specification. They do not. One resource, two times and a sentence about the unexpected result make an ordinary-language case. The extra precision reduces guesswork; it is not a request for logs, credentials or a complete business calendar.

An original adult planning example

Describe the before and after of a change.

A second fictional question comes from Morgan, who initially plans a thirty-minute object-repair demonstration and then needs forty-five minutes. Morgan's rough note says, “Rescheduling must work.” That wording hides whether the time, length, resource or date changed. A reply could address a different problem and still appear relevant.

The revised note states an original 10:00–10:30 window, a requested 10:00–10:45 replacement and a separate proposed 10:40 start on the same resource. It asks how a demonstrated workflow would treat the overlap and distinguish a requested change from an accepted replacement. The examples are synthetic; neither appointment exists through this page.

The output of the conversation should preserve what is known: whether the core can express the collision, which interface is absent, and whether the cancellation or change path required for the complete job is available. A description of how a product ought to behave is useful planning material, but it is not evidence that Morgan's proposed change has been processed.

The stopping point is a missing part of the required workflow. If the branded change surface cannot be exercised, say that in the evaluation note. Do not replace the missing evidence with a promise to use a different link, a presumed notification or an unverified account feature. The contact page supplies a route for asking, not an operational workaround.

An original adult planning example

Keep the reply's scope when passing it to a colleague.

Product enquiries often become shorter as they are forwarded. Priya asks about one resource and an overlap rule; a colleague later hears that the entire studio's scheduling is ready. The example shows why the handoff needs the original question. A narrow answer about a rule does not establish connected calendars, team administration or a deployable client page.

A faithful summary has three parts: the invented case that was discussed, the result the explanation supports, and the requirement that remains unresolved. For Priya, that might be a clear account of an overlap refusal alongside an unavailable branded demonstration. The summary should not introduce response-time promises, purchase terms or a commitment that no participant in the conversation made.

A mail link also has a limited effect. It can open the reader's own mail application; the presence of the link does not prove that a draft was sent, received or answered. Keep the actual conversation in the existing channel through which it takes place. Nothing in this specimen creates a Slotly support ticket, reserves early-access capacity or registers the sender as a customer.

If the reply is incomplete, ask the remaining specific question. “Does this explain only the rule, or is there a working page for this case?” is more productive than treating silence about the page as approval. A useful inquiry can end with a clear refusal. That gives the reader an honest basis for the next decision without pretending the product has changed state.

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.