Appointments.software · Early access · the booking engine is built, the brand is new

The appointment book that refuses to double-book.

Most schools do not lack a calendar. They have three or four — a sign-up sheet here, a shared spreadsheet there, a consumer scheduling tool bolted onto a front-office laptop — and none of them know that a parent can only book a conference for their own child, or that the same gym cannot be handed to two teams on the same Tuesday night.

Appointments.software is the specific discipline those tools were never built for: a family-isolation wall that runs in the engine, not a permission a front-office clerk has to remember; a double-booking check that runs the same overlap math whether the resource is a conference slot or a gymnasium; and a reminder system that will not text a family who never consented to texts, no matter how convenient that would be.

And it is honest about the edges. No counselor or nurse appointment calendar yet, no waitlist, no two-way calendar sync, and no live SMS or voice delivery — named below, not discovered later.

132tests across nine files covering the booking, reminder, deposit, calendar, and facility engines, run green before this page was written
2fully wired, persisted HTTP surfaces: parent-teacher conference booking and room/resource booking, both over real tables
0cents ever actually charged. Every deposit quote returns queued_not_charged; there is no payment rail behind it
4surfaces named as not built at all — counselor/nurse booking, a waitlist, two-way sync, and live SMS/voice — listed on this page, not left for you to discover

The honest frame

What this is, and what it is not.

A general-purpose scheduling tool treats every calendar the same: a slot, a booker, a confirmation email. A K-12 building is not that simple. A conference booking is not just an appointment — it is an appointment that only a specific set of adults, the child’s recorded guardians, may make. A room booking is not just an appointment either — it is a shared, finite resource that two different staff members will absolutely try to claim for the same evening at some point in the school year. So this product was built around two refusals before it was built around a calendar grid.

It is a booking engine with a family wall and an overlap check built in, not bolted on. The guardian relationship check and the double-booking check are not validation added at the edge of a generic scheduler; they are the function that decides whether a booking happens at all, and every surface on this page runs through them.

It is not a full replacement for a general scheduling tool. There is no self-serve signup, no mobile app, and no broad third-party integration catalog today. If your school’s need is “book any kind of meeting with anyone, synced everywhere,” a mature consumer scheduling tool is still the better fit, and we would rather say that than oversell.

And it is early access. The conference and facility booking surfaces below are wired to real routes over real tables. Several named surfaces — counselor/nurse booking, a waitlist, two-way sync, and live SMS/voice — are not built. We would rather you read that here than infer it from a quiet quarter after signing.

Built and reachable — a registered handler calls it

The engines that are actually wired.

Each of these is called by a registered API handler behind the platform’s tenant wall. One honest bound on the whole section: reachable is a source-level claim. It means a handler calls the function over a real, persisted table. It does not mean any school has run it in production yet.

Parent-teacher conference booking

A teacher publishes slots. A guardian books one — for their own child, and no one else’s

A teacher (or any conference-staff account) publishes a set of open time slots for a conference window. A guardian sees, for each slot, whether it is free or taken — never another family’s name — and books one for their own student. The booking engine checks four things, in this order, and any failure blocks the whole booking: the slot is open; the guardian is a recorded guardian of the named student, reusing the same family-isolation predicate the parent hub already enforces, never a second copy of that rule; the student’s school matches the slot’s school; and the slot is not already held by a live booking. A slot can be taken at most once. On a successful booking, a confirmation is queued through the same durable notification lane picture-day already uses for its own reminders.

rce-conference-scheduling.ts + routes/conference-booking.ts Free. No fee/charge column is touched on this route.

Room & resource booking

Rooms, gyms, fields, and equipment — booked by staff, double-booking fail-closed

A school registers its bookable estate — rooms, a gym, a field, an auditorium, a cafeteria, equipment — and facilities staff request a half-open time window against one. A requested window that overlaps any live booking on the same resource is rejected outright; nothing is held. Back-to-back bookings (one ending exactly when the next begins) are allowed, and a malformed time window fails closed rather than guessing. Confirm or cancel a booking and the window frees itself. An authorized-only availability view shows occupancy over a query window — never a public roster of who booked what.

back-office-facility-booking.ts + routes/facility-booking.ts Honest-off. The engine supports a community-rental fee; this route does not surface it yet — no charge call, no currency import here.

Reminder channel selection, TCPA-aware

A reminder is planned over a chosen channel — and a missing opt-in blocks it, not a default

A reminder is not just “email, always.” It is planned over one of email, SMS, or voice, and each channel carries its own consent purpose. A family that opted into email communications has not thereby opted into an automated text or a robocall — SMS and voice sit behind the stricter bar that law requires, enforced structurally rather than left to a checkbox interpretation. A channel with its own opt-in resolves to queued, not sent; a channel without it resolves to suppressed, no consent and is never queued at all.

cbuild-booking-reminder-channel.ts No money. A planning decision, not a transport.

Deposit / fee quoting at booking

An optional deposit line, computed in exact integer cents, and never charged

When a booking carries a price, this surface can quote a deposit and the balance left over — flat, a percentage (floored to the cent, never rounded up), or the full amount — against a caller-supplied, admin-editable schedule. The deposit is always capped at the base price so the balance can never go negative, and a zero-price booking yields a zero deposit. The payment status on this line is always queued_not_charged with zero cents actually charged — there is no argument and no schedule that flips either, because there is no payment rail behind it.

cbuild-booking-fee-seam.ts Nothing is ever charged. The default schedule quotes no deposit at all.

Subscribe-able calendar feed (.ics)

A real RFC-5545 feed a family or a staff calendar can subscribe to — publish only

Bookings render as a spec-correct .ics feed: CRLF line endings, 75-octet line folding that never splits a multi-byte character, proper text escaping in the summary and description, and a stable UID per event. Staff subscribe to the full board; a guardian’s feed carries only their own family’s bookings. This is a read-only publish: nothing is fetched from anywhere, nothing is sent, and a change made on the family’s own calendar app never flows back in — there is no two-way sync here, and this page does not claim one.

cbuild-booking-ics.ts No money. A calendar feed, not a transaction.

Booking confirmation dispatch

A persisted booking queues a confirmation — “dispatched” means queued, never delivered

The moment a conference booking is actually persisted, a confirmation job is enqueued through the same durable notification lane the platform already runs for picture-day reminders, absence alerts, and low-balance notices — not a one-off invented for this page. The enqueue is best-effort and non-throwing, so a comms hiccup can never fail a booking that already succeeded. The actual email or SMS delivery underneath stays key-gated honest-off: without a configured delivery key, it is a logged no-op, never a faked “sent.” A response field named dispatched means the job was queued. It does not mean a family received anything.

routes/conference-booking.ts (dispatchBookingConfirmation) + packages/notifications No money. A queued job, not a guaranteed delivery.

The one guarantee this whole product turns on

A slot can be taken at most once. That sentence is the product.

Double-booking is the failure mode that makes a school stop trusting a scheduling tool entirely — one bad Tuesday where two families show up for the same conference slot, or two teams show up for the same gym, and the front office goes back to a paper sign-up sheet for the rest of the year. So the check runs at the engine, not at the UI, and it runs the same way for a conference slot and a bookable resource.

Half-open windows, one resourceOutcome
Existing booking: Gym A4:00pm – 5:00pmheld
New request: 4:30pm – 5:30pmOverlaps the existing windowrejected
New request: 5:00pm – 6:00pmStarts exactly when the existing window endsallowed
New request: 3:00pm – 4:00pmEnds exactly when the existing window startsallowed

Illustration with round example times. The rule is exact: two windows conflict only when one starts strictly before the other ends AND the other starts strictly before the first ends. A window that starts exactly when another ends does not conflict — which is what makes back-to-back bookings of the same room, all day, actually work.

Both booking paths — a teacher’s conference slot and a school’s bookable resource — ultimately ask the same question: does the requested window overlap any window that is already live? A cancelled or released booking frees its window; a merely-held or pending one still blocks. And a malformed time window (a start that is not strictly before its end, or an unparsable instant) fails closed, treated as a conflict rather than let through on a guess. The permissive failure direction — “when in doubt, allow it” — is never the one this engine takes.

The second guarantee

A parent books a slot only for a child they are a recorded guardian of.

This sounds obvious until you look at what a general scheduling tool actually checks when a conference slot is booked: usually nothing. A link is a link, and whoever has it can book it for whatever name they type in. In a school, that is not a cosmetic gap — it is the difference between a family seeing a private conversation about a child who is not theirs and not.

So the booking engine does not accept a typed name at all. It accepts an opaque student reference and checks it against a recorded guardian relationship — the exact same family-isolation predicate the platform’s parent hub already enforces for every other family surface, reused rather than re-implemented. An unknown or absent relationship returns false and denies the booking; there is no default-allow branch anywhere in the check. On top of the family wall, the student’s school has to match the slot’s school too, so a family in one building cannot book a slot published by a teacher in another.

The same discipline holds for who may publish a slot in the first place. Publishing is a staff-only act, checked before any slot logic runs at all — a parent, a student, or any non-staff session is refused outright, not merely hidden from a menu.

Consent, per channel, not per family

Opting into email is not opting into a text message.

It is tempting to treat “this family said yes to reminders” as one flag. It is not one flag, and the law does not treat it as one either: automated text messages and automated phone calls require their own prior, affirmative opt-in, distinct from and stricter than an email communications consent. A family who agreed to email updates has not thereby agreed to an automated text.

The reminder planner enforces that distinction structurally. Each channel — email, SMS, voice — is checked against its own consent purpose from the family’s granted set. A channel with its opt-in present resolves to queued, not sent; a channel without it resolves to suppressed, no consent and is never queued at all, regardless of how convenient sending it anyway would be.

And we are precise about the other half of that sentence: nothing is actually transmitted by this planner. It decides whether a reminder is allowed to be queued for a channel. The real delivery — an email actually leaving an outbox, a text actually reaching a phone — runs through a separate, key-gated transport layer that today has no carrier wired underneath it. A queued reminder is an honest intention to send, not proof that anyone received anything.

Rooms, gyms, fields, and equipment

The same discipline, a different resource shape.

A school’s bookable estate is not one thing: a room, a gym, a field, an auditorium, a cafeteria, a piece of equipment. Each is registered once, with a kind and a school anchor, and after that it behaves exactly like a conference slot for the purposes of the one rule that matters — a requested window either overlaps a live booking on that resource or it does not, and an overlap is rejected outright.

Facilities staff request the booking, confirm it, or cancel it — cancelling frees the window immediately for the next request. An authorized-only availability view shows how a resource is occupied over a query window, aggregated into booked minutes and a count of live bookings, without exposing a public roster of who booked what.

One honest scope bound. The underlying engine also models renting a facility to the community for a fee — a real revenue line for schools that rent out a gym or an auditorium — and that part is genuinely written, honest-off (queued, never charged, absent a payment provider). This route does not surface it yet: no community-rental table, no charge call, nothing a school could click today. It is a capability in the engine, not a feature on this page.

Pricing — the plan, grounded and honest. Not a live checkout.

Priced for a calendar that grows from one teacher to a whole building.

A conference calendar and a gym calendar are the same overlap check underneath, so the tiers below are not a re-priced generic scheduler — Personal is one calendar publishing conference slots, Pro adds staff and white-label branding, and Business & Teams adds the room-and-resource module this page already documents in the engines that are wired. These figures are the planned launch tiers; they are not a live purchase option today.

Personal

Personal

Free

One calendar · planned

  • Unlimited conference-slot publishing on one calendar
  • Custom domain — not locked behind a top tier
  • Subscribable .ics feed (opaque labels only)
  • The same family-isolation wall every paid tier uses
  • Email notifications when online

Professional

Pro

$12 / user / mo

Per user · planned

  • Everything in Personal
  • Multiple staff calendars (more than one teacher publishing slots)
  • White-label branding — your logo, colors, badge gone
  • Reminder channel selection, TCPA-aware per-channel consent
  • Deposit quoting in exact integer cents (queued_not_charged)

Enterprise

Enterprise & White-label

Custom

Volume · self-host · licensable

  • All modules
  • Self-hosted or managed
  • Per-tenant white-label licensing — resell it as your own
  • Public versioned API + webhooks (planned)
  • SLA and dedicated support

These figures are the planned launch tiers; they are not a live purchase option today. No money changes hands through this site, and reserving early access does not create a payment, store a card, or commit you to anything. The deposit line inside the product is computed and always queued_not_charged; there is no payment provider wired behind it.

Your brand, your domain — not the enterprise upsell everyone else makes it

Put your own name on it from the free plan up.

A custom domain is the first thing most appointment-link tools lock behind a paid tier, and full white-label branding is the thing they reserve for an enterprise contract. We inverted it: the custom domain is on every plan, Personal included, and the deeper branding is one step up — not a sales call.

Custom domain — every plan, free included

Claim a hostname you control, drop in the DNS-TXT record we hand you, and once it verifies your booking pages and your subscribable calendar feed serve from your own domain. One host belongs to one account — no overlap, no cross-tenant leak — and releasing it unroutes immediately. Minors are denied domain control at the server, deny-first: claiming a hostname is an adult-gated, audited act. It binds through the same owner-context layer that runs our K-12 and studio arms in production, so there is no separate deployment behind it.

Free on Personal

White-label branding — one step up, at Pro

Your logo, your wordmark, your colors, and the “Powered by Appointments.software” badge gone. Notification emails carry your logo and your display name. Two floors never move, at any tier: the actual sending address stays a platform address (you set display name and reply-to, not the From-address), and the consent/legal footer stays ours — the platform remains the consent data-controller of record.

Pro and up

Which tier unlocks which rung. The consent footer and the sending domain are the two floors that never move.
CapabilityPersonalProBusiness & TeamsEnterprise
Custom domain (DNS-TXT verified claim)YesYesYesYes
Minors denied domain control (deny-first)YesYesYesYes
White-label branding, badge removedYesYesYes
Branded emails (logo, display name, reply-to)YesYesYes
Org-wide inherited brand across every seatYesYes
Per-tenant white-label licensing (resell)Yes
Email sending domainAlways the platform’s — display-name + reply-to only, at every tier
Consent / legal footerAlways the platform’s, at every tier — never white-labelable

The engine that verifies a domain and binds a brand to an account runs in production in our K-12 and studio arms. The self-serve connect-your-domain and theming screen for this product specifically is in active development; we are accepting early access registrations now. No custom sending domain and no custom CSS/favicon selection today — both are roadmap, framed as such, never as live.

Said here, not discovered later

What is not built, in two different senses.

There are two different kinds of “not there” on this product, and they are worth telling apart because they cost different amounts to fix. One row of code is written, tested, and simply not connected to a route. Everything else in this section has not been written at all — there is no module to name, only a plain statement of what exists today instead.

Written, tested, not wired to a route

ModuleWhat it doesWhy it is not reachable
Admissions interview schedulingReuses the exact same slot/booking/availability primitive that publishes conference slots, but swaps the family wall for an admissions-owner-of-lead gate and a funnel-stage gate (a lead must be at or past “contacted” and not terminal) so a campus tour or interview becomes a bookable slot for a prospective family.No route file registers it and app.ts does not import it. The only importers are its own module, its own test, and a sibling rehearsal-planning domain file.

Not written at all

SurfaceWhat exists today instead
Counselor or nurse appointment calendarNo dedicated bookable-slot route for either role. The counselor caseload/notes workspace and the health-office clinical-visit module are real, wired, and role-gated, but they are a caseload/records surface and a visit-recording surface, not a slot calendar. The same fixed-slot engine that publishes a teacher’s conference slots is keyed by an opaque staff reference, not a role, so extending it to a counselor or nurse is the same mechanism — just not yet wired to its own route.
WaitlistNone. A full slot is a full slot; the engine returns a clean rejection and there is no queue behind it. A family that wants the next opening has to check back.
Two-way calendar syncThe .ics feed is publish-only. A change made in a family’s own Google or Outlook calendar never flows back into a booking here.
SMS or voice deliveryThe per-channel consent wall (TCPA-aware) is real and enforced. No carrier is wired underneath it, so a reminder planned for SMS or voice is honestly queued and never actually sent.
Payment collection at bookingThe deposit/fee line is computed in exact cents and shown. Nothing is ever charged: payStatus is hard-wired to queued_not_charged with no payment rail behind it.

Against the general-purpose category

Eight rows. The general-purpose category wins the first three, outright.

Most vendor comparison tables are a list of things the author is good at, and everyone reading knows it. So here are the three axes where a mature, general-purpose scheduling category beats us, first, without qualification: broad two-way calendar sync, a polished self-serve app with unlimited event types, and a large pre-built integration catalog. Those are real, and for most individual bookings — a parent-teacher call, a vendor meeting — that category is still the better tool.

The rows underneath are the axes where the K-12-specific discipline shows up, and the same rule holds as everywhere else on this page: we describe our own behaviour precisely, because we can read our own source. Where the other column would require asserting what a specific vendor’s internals do, it says not established, because we cannot read another company’s code and a guess in the direction that flatters us is not a comparison.

The left column states our own measured behaviour. The middle column states only what the category openly advertises, or that we could not establish it. Rows are marked for whoever wins them.
What you are buyingA general-purpose scheduling toolAppointments.software
Broad calendar-provider sync (Google, Outlook, iCloud) both waysYes. Two-way sync with major calendar providers is a standard advertised feature of the category.No. The .ics feed is publish-only. A change made on the family’s own calendar never flows back in.
Unlimited event types, a mature mobile app, a polished self-serve UIYes. Years of consumer-product polish and a free mobile app are a real, advertised advantage.No. This is early access with no self-serve signup and no app. The UI is a marketing page and a set of HTTP routes today.
A large pre-built integration catalog (payment processors, video, CRMs)Yes. Broad third-party integrations are a standard, openly advertised part of the category.No. There is no payment rail, no video integration, and no CRM connector here.
A parent may only book for a student they are a recorded guardian ofNot established as a structural guarantee. A general scheduling tool has no concept of a family relationship to enforce.Yes, enforced in the engine itself, reusing the same family-isolation predicate the platform’s parent hub already uses — not a second, weaker copy of the rule.
Double-booking is rejected by an overlap calculation, not a UI lockNot established as a structural guarantee across the category; a specific vendor’s internal collision handling is not something we can read.Yes. A half-open interval overlap check runs at the engine for every booking, on the resource and on the conference slot, with a malformed window failing closed rather than guessing.
A reminder channel checks its own, specific consent purpose before queuingNot established. We have not found this distinction published for the category as a structural guarantee.Yes. Email, SMS, and voice each carry a distinct consent purpose; SMS and voice sit behind the stricter bar the law sets, enforced in code.
A deposit is quoted honestly with no live charge until you wire a processorNot the advertised model. The category’s advertised value includes collecting payment at booking.Yes. The deposit math runs today; the payment status is hard-wired to queued_not_charged with zero cents actually moved, because no processor is wired.
Room and facility booking with the same fail-closed double-booking rule as an appointmentNot established as a single shared engine; some category tools separate rooms and appointments into different products entirely.Yes. Conference slots and bookable resources both run through the same half-open overlap discipline, just with a different resource shape.

The same axes, stated against the category by name

Structural product categories, not named vendors. Each cell states its verdict in words, so the table reads without color.
Product typeA parent may only book their own recorded childDouble-booking rejected by an overlap calculationA reminder checks its own consent purposeCustom domain on every tier
Appointment-link toolsNo family relationship to enforceUI lock, not an engine checkNot a stated guaranteePaid tiers only
Sign-up-sheet toolsOpen sheet by designCapacity races, not a lockNot a stated guaranteeAd-supported free, no domain
Room / desk booking toolsNo people-booking substrateRooms only, no conference slotsNot a stated guaranteeSpace-metered pricing
Appointments.softwareReused family-isolation predicateHalf-open overlap check, engine-levelPer-channel, TCPA-awareEvery tier, Personal included

One note on the category, since this page makes a claim about it. The general-purpose appointment- scheduling market this product is measured against includes consumer booking-link tools and their K-12-adjacent competitors. They are named here once, only as a factual category reference, and none of their code, copy, or design is used anywhere in this product. Nothing above is a claim about how any specific vendor is built internally — we have not read their source and cannot, so every row either cites our own measured behaviour or says outright that we could not establish theirs. Their advertised capabilities are their own to describe, and any of them may ship any of the things in our column tomorrow.

Measured, not remembered

132 tests across nine files. Here is what each one actually proves.

Every count on this page is a grep of the file named, run by the author before this page was written, not a number recalled from memory. They are presented as test counts — never as a pass rate, an adoption figure, or a quality percentage.

The bound is as important as the number. A green test proves the function returns the right verdict for the input it was given. It says nothing about whether a school has run it against real families and a real building yet — that is a separate claim, and this page does not make it.

25 tests rce-conference-scheduling.test.ts The slot/booking/availability engine: fail-closed order, double-booking, the family wall.
28 tests back-office-facility-booking.test.ts Resource booking: overlap rejection, back-to-back adjacency, malformed-instant fail-closed.
16 tests cbuild-booking-reminder-channel.test.ts Per-channel consent resolution and the TCPA-stricter bar for SMS/voice.
19 tests cbuild-booking-ics.test.ts RFC-5545 correctness: folding, escaping, CRLF, recurrence.
13 tests cbuild-booking-fee-seam.test.ts Deposit math: flooring, capping, the always-honest-off payment status.
7 tests conference-booking-persistence.test.ts The real HTTP route against real persisted tables.
9 tests conference-booking-reminder-fee.test.ts The reminder and deposit surfaces wired into the live route.
3 tests conference-booking-confirmation.test.ts The confirmation job enqueues on a real persisted booking.
12 tests facility-booking.test.ts The real HTTP route: register, book, confirm, cancel, availability.

Data, walls, and what we hold

Scheduling data, not a student record.

A conference booking or a room booking references a student, a guardian, or a requester by an opaque reference only — there is no name, no contact detail, and no directory field carried in the booking record itself. That is a deliberate design choice, not an accident of a minimal schema: a booking is scheduling data, an appointment fact, and it is kept structurally separate from a student’s census and academic record rather than folded into it.

Access is layered. Publishing a conference slot or requesting a facility booking is staff-only, checked before any booking logic runs. Booking a conference slot is a guardian act, gated by the family wall described above — a non-guardian is denied by the engine itself, not merely hidden from a page. A guardian’s own view of the slot board is a read-only availability projection: free or taken, and their own bookings, never another family’s identity.

Money, where it appears at all, is honest-off everywhere on this product. The deposit quote always returns a status of queued_not_charged with zero cents actually charged, because there is no payment provider wired behind either booking surface. Reminders follow the same honesty: a queued reminder means a channel’s consent check passed, not that a message was delivered, because no carrier is wired underneath any channel today.

To be exact rather than flattering: this is not a claim that no sensitive data exists here. A booking still touches a real relationship between a real family and a real school. The honest claim is narrower — the record itself carries opaque references, the write path is gated twice (staff check and, on the write, an engine re-check), and nothing here is public.

Different lanes for different needs

Ten front doors, one scheduling engine underneath.

These are separate products for separate jobs, each its own brand — not tiers of one app. They share a booking engine (no-double-book at the database, capacity under a lock, an honest waitlist), and nothing else. Naming them here is not a claim that any is live in production — each is its own brand with its own status, stated on its own page.

One link, one slot

slotly.software

The plainest single-link booking front door for a solo practitioner or a very small team.

Call dibs on a time

dibs.software

A first-come, claim-a-slot sign-up sheet with a consumer voice -- the first to grab a time gets it.

Pencil it in

penciled.software

Fixed-slot booking with a real soft-hold state: hold it provisionally, confirm with one tap.

More than one calendar

appointments.software

Appointment booking for a business with multiple staff, locations, or shared resources.

You are here

Classes & studios

classly.software

Recurring class, pack, and waitlist scheduling for studios.

Cohort courses

cohort.software

Session-based scheduling for cohort-run online courses.

Staff shift roster

shiftly.software

Post an open shift and match it to eligible, credentialed staff -- scheduling only.

Shifts + hours record

clockly.software

Shift scheduling with time-clock and hours-record capture for classified staff and shift-work teams.

Find a time

whenly.software

A native, ad-free poll for finding the time that works for a whole group.

The master timetable

schedule.software

Building the institution's whole schedule -- courses, sections, rooms, terms.

Common questions

The questions a front office actually asks.

Can we book counselor or nurse appointments with this today?

Not yet, and we would rather say that here than in a pilot. There is no dedicated bookable-slot route for either role. What exists is a counselor caseload and confidential-notes workspace and a health-office clinical-visit module, and both are real and role-gated — but neither is a slot calendar. The engine that publishes a teacher’s conference slots does not care WHO publishes a slot; it is keyed by an opaque staff reference. Extending it to a counselor or nurse is the same mechanism, not a new one, and it is on the near side of our roadmap, not the far side.

Is there a waitlist when a conference slot is full?

No. A full slot returns a clean, honest rejection, and there is no queue behind it today. A family that wants the next opening has to check back on the availability view rather than being auto-promoted when a spot frees up.

Does the calendar feed sync both ways?

No. The .ics feed is a read-only publish — a spec-correct RFC-5545 feed a family or a staff member can subscribe to in their own calendar app. A change made on that end (moved, deleted, renamed) never flows back into this system. If you need two-way sync today, this is not that product yet.

Do reminders actually get sent by text or by phone call?

Not yet. The consent wall that decides WHICH channel a reminder is even allowed to use is real and enforced — SMS and voice each require their own, stricter opt-in, separate from email. But no carrier is wired underneath any channel today, so every reminder resolves to an honestly queued state and none is actually delivered. We would rather ship the consent wall first and the transport second than the other way around.

Can we charge a deposit when a family books?

The math is there: a flat or percentage deposit, floored to the cent, capped at the base price so the balance is never negative. What is not there is a payment rail — the computed status is always queued_not_charged and zero cents ever actually move. If your workflow requires collecting money at the moment of booking, that piece is not wired yet.

What actually happens when a guardian books a conference slot?

Four checks run, in order, and any one of them blocks the whole booking: the slot has to be open; the guardian has to be a recorded guardian of the named student, checked against the same family relationship data the parent hub itself uses, not a duplicated rule; the student’s school has to match the slot’s school; and the slot must not already be taken by a live booking. If all four hold, the booking is written to a real table and a confirmation job is queued. If any one fails, nothing is booked and nothing is queued.

What happens if two staff members try to book the same gym at the same time?

The second request loses, cleanly. The engine checks the requested window against every live booking already held on that resource using a half-open interval overlap test, and a window that overlaps an existing booking is rejected outright — nothing is held for the losing request. Two bookings that merely touch at the boundary (one ending exactly when the next starts) are not considered a conflict, so back-to-back use of the same room is allowed.

Is any of this AI-assisted?

No. Every decision described on this page — slot availability, the family wall, the overlap check, the consent-channel resolution, the deposit math — is deterministic structure with no model in the loop anywhere. There is no assistant reading booking data on this product.

What does it cost?

There is a plan, not a live checkout. Personal is free (one calendar, unlimited conference-slot publishing). Pro is $12/user/mo and adds white-label branding and reminder/deposit quoting. Business & Teams is $18/user/mo and adds room and resource booking. Enterprise is custom, for per-tenant licensing. None of these are a live purchase option today — reserving early access does not create a payment or store a card.

Do I need to pay extra to use my own domain and remove your branding?

No, not for the domain. A custom domain is on every plan, the free one included — most appointment-link tools charge for that and reserve full white-label for an enterprise contract. Removing our branding and applying your logo and colors is one paid tier up (Pro), not a sales call. The engine that verifies a domain and binds a brand to an account runs in production in our K-12 and studio arms; the self-serve setup screen for this product is in development. Notification emails carry your display name and reply-to; the sending domain and the legal/consent footer stay ours by design, at every tier.

Is Appointments.software a school, a district, or a nonprofit?

No. It is a for-profit software product built by Stanley Studios. It is not a school, not a district, and not a nonprofit, and nothing here is a charitable gift of any kind.

Does any of this touch a student’s academic record?

No. A conference booking or a room booking is scheduling data — an appointment fact — not a student-record or census fact. A booking references a student by an opaque reference and carries no grade, no discipline history, no health record, and no directory field.

Who can publish conference slots or book a room?

Publishing a conference slot is staff-only, gated before any slot logic runs at all — a parent, student, or any non-staff session is refused outright. Booking a room or resource is likewise a facilities-staff action; the route computes the staff check and the engine re-checks it again on the write, so the gate is enforced twice, not once.

Related surfaces

Adjacent products, each its own thing.

Appointments.software is one booking against a fixed slot. These are the neighbouring surfaces, kept as separate products rather than folded into a suite. Naming them here is not a claim that either is live in production — each is its own brand with its own status, stated on its own page.

schedule.software

A different problem in the same neighbourhood: building the school’s master timetable (courses, sections, rooms, terms) rather than booking an individual appointment against it. A separate product, kept separate on purpose.

slotly.software

The plain, single-link booking front door for a single practitioner or a very small team — a consultant, a coach, a tutor. Not a K-12 platform surface; a different buyer entirely, kept as its own brand.

What this page is and is not claiming

The whole posture, in one paragraph.

Appointments.software is early access: the conference-booking and facility-booking engines are built and wired to real, persisted routes, and the brand around them is new. Parent-teacher conference booking and room/resource booking are real: wired to registered HTTP routes over real persisted tables, both double-booking fail-closed, and the conference path adds a family-isolation wall reused from the platform’s parent hub rather than re-implemented. A reminder channel is planned with a real, per-channel consent check, and a deposit can be quoted in exact integer cents — but nothing is ever actually sent or charged: every reminder resolves to queued or suppressed and every deposit resolves to queued_not_charged, because no transport and no payment provider is wired behind either. The calendar feed is a real, spec-correct RFC-5545 publish, and it is publish-only: there is no two-way sync. Admissions interview scheduling is written and correct and has no registered route — named above rather than counted as a feature. There is no counselor or nurse appointment calendar and no waitlist at all today — not built, not partially built, simply not written yet. There are no adoption counts, no customers named, no testimonials, and no invented figures anywhere on this page; the only measurement quoted is 132 tests across nine files, run green before the page was written. Bookings carry opaque references, never a name or contact field. Pricing above is the planned launch tiers, not a live purchase option; there is no live checkout anywhere on this site. The honest next step is a conversation.

Appointments.software is early access. The conference-booking and room/resource-booking engines below are written, wired to real HTTP routes over real persisted tables, and covered by measured, green test suites. What does not exist yet is a counselor or nurse appointment calendar, a waitlist, two-way calendar sync, or a real SMS/voice transport -- and we would rather tell you that on the first screen than in a pilot debrief.