1 — Tell us the shape of the problem
Write to [email protected] with what you are booking — parent-teacher conferences, rooms, or both — and roughly how much of it. One paragraph is plenty.
Getting started · Appointments.software
There is no sign-up form on this page. That is deliberate.
Self-serve tenant onboarding is one of the things we are still building. A form that does not provision an account is a form that lies about what it does — so a conversation first, and an honest account of what runs today.
The conference-booking and room/resource-booking engines are built and wired to real, persisted HTTP routes right now. What is opening is the standalone product surface and the self-serve setup around them.
What actually happens
Four steps, and you can stop after any of them.
2 — A walkthrough of what is built, not a pitch deck
We show the two engines that exist (conference booking, facility booking) and name what does not: no counselor/nurse calendar, no waitlist, no two-way sync, no live SMS/voice.
3 — A scoped pilot on one surface
Almost nobody should start on both. Pick the one that hurts and run it for one booking cycle — the family wall and the fail-closed overlap check are the same guarantee on one surface as on both.
4 — Widen only when the first one is boring
Conference slots and facility bookings share one overlap engine, so adding the second is a plan change, not a second procurement.
Bring one fictional appointment, with a beginning and an end
A useful first question is small enough to work through on paper. Imagine an adult repair business with one operator, one inspection bay and a forty-minute job. Choose an invented date and write down the requested start and end. Then add a second request that competes for the bay. The question is which commitment should be refused, and why. No name, customer record or exported calendar is needed to describe that conflict.
Keep the resource and the person separate in the example. If the operator is available but the bay is occupied, the appointment is still unsuitable. If the bay is available but the operator is elsewhere, the same conclusion follows for a different reason. That distinction lets an evaluator ask for the evidence behind each decision instead of accepting one green availability label as proof that every dependency was checked.
The output of this preparation is a clear question, not a booking. A written scenario does not reserve the bay, create an account or send a confirmation. Continue using your established scheduling arrangements for real work. The public site can help you describe a requirement; it cannot become an unofficial second calendar merely because the example includes a time.
Ask for a scheduling result and a delivery result separately
Available, requested, recorded and received describe different observations. A proposed time can be available when someone first looks and conflict with another commitment when the request is submitted. A recorded appointment can exist without any reminder reaching a recipient. When discussing a walkthrough, ask which result is being shown and what evidence establishes that result. A message-shaped panel is not a delivery receipt.
The present limitation is explicit: this public site sends no appointment reminder, text or voice call. A reminder plan is a plan. Reading a channel name does not authorize a send, and choosing a navigation link does not contact anybody. If delivery is essential to a requirement, keep it as a separate question instead of treating successful scheduling arithmetic as an answer about transport.
A deposit calculation has the same boundary. The quoted state is queued_not_charged; exact integer-cent arithmetic does not move money. No card is entered here, no checkout runs here and no model acts on an evaluation example. A price discussion, an amount calculated and a payment taken are three separate events. This page supplies no payment confirmation and makes no charge on your behalf.
Explain the mismatch before proposing the integration
An evaluator may already have a booking tool. That is useful context, but a list of product names does not show what needs to change. Describe the mismatch: a shared room is overlooked, a cleanup interval is missing from the conversation, or staff are interpreting a proposed time as a confirmed appointment. An invented before-and-after example makes the requirement inspectable without asking another person to access a live account.
Do not assume that a related product link means shared login, shared records or automatic synchronization. The family pages describe different jobs. A group availability poll, a staff rota and an appointment with a resource dependency have different outputs. The related links are reading choices. This site does not transfer an account or import a schedule when you follow one.
The product account also distinguishes a read-only calendar feed from two-way synchronization. A visible commitment in another calendar does not establish that an edit there returns to its source. If that return path is mandatory, ask about it directly. Neither an example nor an email conversation turns an absent synchronization path into an active integration.
Use the public contact route for a scoped conversation
The contact page provides the published address and explains what its plain email link does. Opening that link asks your own mail application to prepare a draft. This website cannot observe delivery, assign a case number or promise a response time. Review the recipient and sending account yourself. A draft is not a sent message, and a sent message is not an accepted appointment.
A short note can identify the kind of work, the resources that must agree and the refusal that would prevent a bad commitment. Use invented labels and omit attachments containing operational records. Do not send passwords, recovery codes, calendar-access links or card details. Nothing in a public discussion of a fictional overlap requires those secrets, and there is no authenticated intake form on this page.
A useful outcome can be a clearer fit question, including the conclusion that the described product does not perform a required action. You can read the about page, inspect the existing help explanation, or use contact to frame the question. None of those choices provisions an account, signs a contract or commits a resource. Actual operational arrangements remain separate from this reading site.
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 — the pricing on the home page is the planned launch tier, not a price you can be billed at today. A deposit quote inside the product is a computed line, always queued_not_charged; there is no payment provider wired behind it.
Reminders are opt-in per channel and currently send nothing at all. Self-serve onboarding, a counselor/nurse calendar, a waitlist, and two-way calendar sync are all in development or not yet written — named on the home page, not discovered in week two.