Booking Assistant: Appointment Requests by Chat, Around the Clock

With a calendar connection in the Custom package, the assistant reaches your calendar or booking system through defined actions: the calendar_availability shape reads free slots, calendar_booking writes the appointment straight into it. Reading runs without asking, the entry only after the visitor has seen the proposal in plain text and confirmed it. Both shapes are remote tools and therefore need a stored address; the call goes out over exactly one connection with target check, time limit and size limit, and without redirects. An entry carries a one-time key that the database locks against, so the same appointment cannot be created twice. Without that connection the assistant names free times from your stored kinds of appointment, minus the appointments already requested or confirmed in XICBOT, and takes appointment requests that your business confirms. Any system that offers an interface for free slots and for bookings can be connected — ready-made connectors for individual providers are not part of the delivery. Which connection fits your case we clarify in the initial consultation.

The assistant checks occupancy under a lock: the check and the entry happen in one go, so a time slot is not given out twice. Against a double click there is a bolt in the database rather than in the program flow — the same request submitted twice does not create a second request. An appointment request becomes an appointment when your business confirms it. Without a calendar connection the assistant counts the appointments already requested or confirmed in XICBOT; what is only in an external calendar it does not see. With a calendar connection set up in the Custom package it reads free times through the calendar-availability form and writes the entry through the calendar-booking form; then the free times offered follow your calendar — including appointments that came in by phone or email. The check under a lock does not apply on this path: whether a slot taken in the meantime is rejected at booking is decided by your calendar. XICBOT sends each booking with an idempotency key by which your calendar can recognise a booking submitted twice.

Yes, both live in the same tool type as the appointment request: appointment takes appointment requests, reschedules and cancels. Each of these acts writes and therefore requires confirmation, and the proposal names the act as its own sentence — cancel, reschedule or request is spelled out before anything is clicked. The text of the proposal is stored before the confirmation and not generated anew: what gets confirmed is exactly what was read. A new time has to meet the same rules as a new request — known kind of appointment, matching lead time, approved window, occupancy checked under a lock — and a rescheduled appointment is a request again until your business confirms it. If a case turns delicate, the assistant is meant to call the handoff tool type; that sets the conversation to escalated and notifies a person in your company.

Tool control means the assistant does not only read your connected systems but also operates them. Seventeen forms are available: seven in the core — capture a request, take an appointment request, hand over to a human, search the catalogue, put together a cart in the chat, query an external system, pre-fill a form on your site once the visitor confirms — and ten for calendar, inventory, catalogue, customer management and ticketing; querying an external system and these ten come in the Custom package. Every tool is registered as reading, writing or irreversible; confirmation is the default. Anything that does more than read is first shown as a proposal, and only a click by the visitor carries it out. Every call is then recorded in the log, with input, result, duration and the path by which it was approved. How your own processes can be mapped is shown on custom functions.

If a matter becomes personal or sensitive, the assistant is meant to hand over to a human: the conversation is then marked as handed over, the request becomes an enquiry in your account, and your team is notified. The visitor reads the reason for the handover in plain text beforehand and confirms it themselves. A second handover in the same conversation does not trigger a second notification. The visitor is not told by which route your business is notified — they only see that someone will get in touch. The conversation history is preserved, so your team does not start from scratch. How this looks in everyday use is shown by the support assistant.

Yes, and the built state reckons with it. For every question at most five search hits from your sources, plus your text blocks, go to the model, numbered, and sourced answers name the excerpts they rely on. Figures, prices and deadlines that are not in your sources are replaced with a notice. If the search finds nothing, the assistant says that nothing on this is on file instead of composing freely. Four topics are hard-blocked — legal advice, medical information, the assessment of allergies and a binding financing offer. Its rules forbid it to invent contact details, file numbers or appointments, or to pose as a human being. Questions left open are logged and become visible in conversation analytics — and turn into the next source.

The booking assistant belongs to the Pro package: a one-off setup from 2,900 € net plus operation from 149 € per month net, including hosting in Germany, care, updates and GDPR. The chat first creates an appointment request; it only counts as an appointment once your business has confirmed it. The occupancy check and the creation run under the same lock, and a verbatim repeat is recognised as a duplicate through a one-time key. If your workflow needs custom rules or several calendars, it becomes the Custom package from 4,900 € net setup. Details under booking assistant and pricing. All services can be cancelled monthly; there is no minimum term.

It works towards that without us promising a rate. An appointment request in the chat stays a request until your business confirms it — and only a confirmed appointment is ever reminded. The reminder goes out one day before the appointment to the address given in the conversation, if the visitor gave one, and is triggered by an hourly run, not by hand. Before sending, the visitor reads in plain text what is being requested and confirms it themselves; a double click does not create a second request. How many no-shows this saves depends on industry, appointment type and audience — but planning generally becomes more reliable.