The Booking Engine publishes your availability so people outside your organisation can book time without an exchange of emails.
That much every scheduling tool does. The reason to use this one is what happens to the booking afterwards.
Where a booking lands
A booking made here is not a calendar entry with a name attached. It arrives inside the platform, which means it arrives next to everything else you know.
On your calendar, tinted as a booking, alongside your meetings, your tasks and your team's leave.
Attached to a person, so a returning customer is recognised rather than being a fresh name.
With its context, which is the distinctive part: what they said they wanted to talk about, how urgent it is, and whether they can actually decide.
With its origin, so a booking that began in a WhatsApp conversation shows as having come from there, and one from the website shows as web.
The practical difference: a booking is a lead with a time on it rather than an appointment you now have to research.
What you set up
Two things, and only two are built today.
Meeting types. What can be booked: the length, who it is with, where it happens, and what you want to know before it starts.
Availability. Working days, hours, and how much of each day you are willing to give away.
What is not built yet
Three sections appear in the navigation and do not work yet. They show a "coming next" panel rather than anything functional.
Teams, for pooled availability across several people.
Routing, for sending different enquiries to different people automatically.
Insights, for booking volume, conversion and no-show analytics.
They are visible so you can see what is planned. If you need pooled team booking or automatic routing today, the honest answer is that this is not there yet, and the workaround is one meeting type per person.
What a visitor never sees
Availability is exposed as free slots and nothing else.
They cannot see your other meetings, their titles, who they are with, or anything about your colleagues. The same boundary applies here as everywhere else in the platform: busy is busy, and what you are busy with is yours.
Worth knowing so you can share a link without hesitating, and so you can answer the question when a cautious colleague asks what a public booking page gives away.
How somebody books
They open a link, or meet an embedded booking widget on your website.
They pick a meeting type, answer whatever context questions you configured, choose a slot from your real availability, and confirm.
No account, no app. The same principle as document signing: every step between somebody and a booking loses a proportion of them.
What happens next
Depending on how you set the meeting type up, the booking either confirms immediately or waits for you to accept.
Either way it appears on your calendar, the person is attached to a record, and the meeting can be recorded and analysed like any other if you send the recorder to it.
A booking is a record, not an event
The distinction that explains most of this section.
A calendar event is a time with a title. A booking is a person, an organisation, a stated reason, an origin, a state, and a time. The calendar entry is one view of it.
That is why marking a booking completed matters, why the context answers are worth reading, and why a returning customer is recognised. None of it would be possible if the only thing stored were an appointment.
Where it fits with the rest
Against the calendar: the calendar shows your commitments. The Booking Engine is how outsiders create one.
Against Sales: a booking is frequently the first real contact with a prospect, which is why the context step exists. What somebody says before a call is genuinely useful, and it disappears if the meeting was arranged over email.
Against Comms: a conversation on WhatsApp or web chat can end in a booking, and that booking remembers where it came from.
Who should set this up
Whoever owns the meeting matters more than whoever owns the platform. A salesperson should shape their own discovery call; a support lead should shape their own triage call.
The configuration is not technical. Naming a meeting type, choosing a length and deciding what to ask beforehand are all judgement about your own process rather than settings.
What it costs
Nothing per booking. The page, the embed, the confirmations and the calendar writes carry no usage charge.
Recording a booked meeting draws on your organisation's included meeting hours, the same as any other meeting, and only if you send the recorder to it.
The one thing to get right
Availability. Everything else on this surface is adjustable and forgiving; availability is what determines whether the page helps you or costs you.
A page that offers too much fills your week with meetings you did not choose. A page that offers too little shows nothing and sends people elsewhere.
The rest of these articles are detail. That one setting is the decision.
Two things it will not do
It will not take payment. A booking is a commitment of time, not a transaction. Anything involving money follows in Finance.
It will not reschedule on its own. A visitor who needs a different time cancels and rebooks, or asks you. There is no automatic negotiation, which is a limitation and also the reason nothing surprising happens to your calendar.
Where to start
Make one meeting type, for the meeting you have most.
Set your availability honestly rather than optimistically.
Book it yourself, from the public link, in a private browser window. Five minutes, and it is the only way to see what your customers see.
Then put it somewhere. A link in your email signature does more work than a widget on a page nobody visits.
Did this answer your question?
No, ask a person