Availability Is a Shape, Not a List
Most booking tools ask you to maintain a list of free times. That is exactly backwards: what you maintain is the pattern — the week, the slot length, the capacity — and an open appointment is what is left over. Exceptions are additions to and subtractions from that shape rather than rows in a table somebody has to keep current.
A week that is actually a week
Monday to Sunday, each with its own opening and closing time, its own slot length, and an on/off switch. Sunday being closed is the absence of slots, not a list of blocked ones.
Additions in four shapes
One specific date, a set of weekdays, a date range, or a start time that repeats until a cut-off. Late-night consultations every second Thursday in March is a thing you describe once, not a thing you enter twelve times.
A slot can hold more than one person
Capacity is per slot, not per calendar. A one-to-one consultation and a twelve-seat group session are the same mechanism with a different number on it.
How soon, and how far ahead
A minimum distance keeps anybody from booking you in eleven minutes, and a maximum keeps the page from offering next March. Both are day counts on the page rather than rules in somebody's head.
More than one calendar
Calendars are named things you create — one per room, per service, per practitioner — and a booking page or an agent is pointed at the set of them it is allowed to see.
Timezones, not a disclaimer
The schedule is authored in your time and rendered in theirs, detected from the browser and overridable from a picker. Nobody has to do arithmetic to find out when 14:00 is.
A Public Page That Reads the Real Schedule
Your logo, your colour, your typeface, on your own slug. It detects the visitor's timezone and language, shows only the slots your schedule actually allows on that day, and collects exactly the fields you asked for — each one required, optional or not shown at all.
One Engine, Three Ways In
This is the reason a double booking does not fall through a crack here. The public page, the agent mid-conversation and your own backend all ask the same place — they are not reading three copies of one calendar that reconcile overnight.
Your booking page
A public URL on your own slug that anybody can open and book from, with no account and no app.
The agent, mid-conversation
Voice or chat. It checks working hours, reads genuine slots, creates the appointment, and can move or cancel it later.
Your own systems
The same operations are reachable from an automation node or over the API, so your site, your app or your CRM can book without a human in the middle.
A slot is not a timestamp. It carries its duration, its capacity and the rules that made it exist at all.
A booking page is a public write endpoint with no login in front of it. Treating it as one is the difference between a full calendar and a flooded one.
The Page Your Customers See
It is part of your presence, not ours. And because it is public and unauthenticated, it carries the unglamorous things nobody puts on a feature list.
It looks like you, not like us
Logo, brand colour, typeface, a profile photo, your own heading and greeting sentence, and a choice of two layouts — the slot list beside the form, or one column the visitor moves down.
In the language they arrived in
You list the languages the page offers and which one is the default; it can also pick one up from the browser. The display language and the booking language are separate settings, because they are separate questions.
The fields you actually need
Name, email, phone, company and notes are each required, optional or hidden, and you can add your own fields beside them with their own labels and placeholders. A form nobody has to skip past.
And the part nobody advertises
A public booking page is a public write endpoint. This one carries human verification, request rate limiting, and caps on how many live bookings a single email address or a single browser may hold at once.
All of it without writing any code
What Happens After the Booking
A booked appointment is the beginning, not the end. The no-show happens between the booking and the day, which on most platforms is exactly where nothing is.
Confirmation by SMS, from a template you own
Automatic on booking, or sent by hand from the appointment. Every send is logged with its status, so "they say they never got it" is a row you can look at rather than an argument.
A cancellation link that belongs to that booking
Each appointment gets its own link. Opening it shows what is being cancelled before anything happens, and the page the booking was made on updates the moment it is.
A meeting link, generated with it
Turn it on and every booking that needs one gets a video link created with the appointment, rather than a separate step somebody has to remember before the day.
The contact, in your own data
Appointments and the people in them live in your data stores, not in a black box, so the same record is readable by an automation, by an agent on the next call, and by whatever you export to.
And whatever should happen next
A booking is an event a workflow can start from: a reminder the day before, an intake form, a call two days after to ask how it went. None of that is a booking feature; all of it is one canvas away.
Or the calendar you already use
Agents can check Google Calendar availability and create events on it, and can drive Cal.com and Calendly event types and bookings, when the schedule of record lives somewhere else.
Reminders, follow-up calls and everything else between the booking and the day are built on the same canvas as the rest: Automations & Workflows. And how well the booking conversations actually go is what the “Appointment Booking” metric pack measures under Performance Analytics.
What Teams Actually Build With It
All six use the same availability engine. Only the way in differs.
The practice phone, answered at 21:00
Somebody calls after hours. The agent finds them in the contact store, reads genuine availability for the right practitioner's calendar, books, and the confirmation SMS is on their phone before they hang up.
Moving one, without losing it
Rescheduling is its own operation rather than cancel-and-rebook, so the slot is released and the new one taken in one move — and the person keeps the same booking rather than a new one with no history.
The no-show call, the evening before
A scheduled workflow reads tomorrow's appointments and calls each one. Confirming takes ten seconds; the ones who cannot make it are moved on the same call, and the slot goes back on the page.
A class, not an appointment
Capacity per slot turns the same machinery into group bookings: twelve seats, eleven taken, and the agent knows the difference between "that time is gone" and "there is one left".
Booked from the website chat
The same availability tools work in chat. A visitor asks a question, the agent answers it, and the booking happens in the same thread rather than behind a link to a different page.
When the day slips, the day tells people
An engineer marks a job as overrunning. A workflow reads the rest of that calendar, calls the next two customers, offers them real alternatives and moves whoever accepts — while somebody is still under a sink.
And you do not have to set any of it up by hand
The schedule, the booking agent, the confirmation copy, the reminder workflow and the page itself are all buildable and editable with AI assistance, the same way everything else on Kilevel is.
The schedule, from a sentence about your week
Describe your opening hours, your appointment length and the evenings you stay late, and the assistant sets up the weekday schedules and the additions that cover the exceptions.
The agent that does the asking
It writes the booking conversation: what to establish before offering a time, how to read three options out loud without sounding like a menu, and what to do when none of them work.
Confirmations and reminders, written
The SMS template, the email body, the placeholders each one interpolates. You review the wording rather than starting from an empty field the day before go-live.
The reminder workflow around it
"Call everybody the evening before and move the ones who cannot make it" is a whole automation — trigger, query, loop, call, branch, update — and it arrives as one reviewable plan.
And the page it all points at
Heading, greeting, which fields to ask for and which to leave out, the languages to offer — described once and filled in, rather than clicked through setting by setting.
It asks what it cannot know
Nobody can guess your buffer between appointments or whether Saturday counts. Those come back as explicit questions rather than as a plausible number quietly written into a field.
Every proposal arrives as an explicit list of edits, with the assumptions it made stated rather than buried. Accept it, reject it, or change it before anything goes near a live calendar.
The page, the voice and chat agents and the API all ask the same place
A single date, weekdays, a date range and repeat-until
Even where the hours you hand out are a great deal narrower
There is no second copy of the schedule to drift out of step