An appointment bot that talks to the CRM in real time

Design a booking assistant around the scheduling system of record, conflict handling, honest confirmations and a human handoff.

A booking request and a confirmed appointment are different outcomes. Before adding a conversational interface, establish which system owns availability and what response proves that a reservation was accepted.

An assistant can collect preferences, query supported scheduling functions and explain the result. It should not promise that a slot is booked merely because the user selected it in a chat.

Keep one scheduling authority

A website widget, Telegram bot, WhatsApp channel and receptionist may all submit requests. They need a consistent view of the same resource and an authoritative conflict decision. Reading a calendar and then writing it later does not by itself prevent two users from choosing the same slot.

Identify the actual booking product and supported API operations. A CRM may store contacts while another system owns appointments. Confirm which integration can reserve, cancel and reconcile a booking rather than assuming every calendar or CRM exposes equivalent transactional controls.

Compare interface options by the task

Scroll horizontally to compare the columns on a narrow screen.

Interface	Useful capability	Check before accepting
Booking widget	Direct selection of supported slots	Accessibility, required fields and conflict response
Button bot	Guided choices with predictable branches	Recovery when input falls outside a branch
Conversational assistant	Extract preferences and explain supported options	Source grounding, validation and reliable API handoff

Natural language can help a visitor describe a time window or ask an eligibility question. It also adds an interpretation step. Confirm extracted details before a consequential action and provide a clear route to a person. No conversion or show-up improvement is assumed from adding a language model.

A reservation state model to validate

Read availability. Record the system response and the relevant resource, time and timezone.
Hold if supported. A temporary reservation needs an expiry and a conflict rule enforced by the scheduling backend. Choose its duration for the service; a chat timer alone is not a lock.
Confirm. Validate required details and use the supported reservation operation. Send confirmed wording only after the authoritative response is known.
Expire or cancel. Release a hold through the backend’s supported transition and verify the result.

If the backend has no atomic reservation or suitable conflict protection, document that limitation. A request requiring staff confirmation must be presented as a request. Do not hide the gap behind a confident assistant reply.

Test collisions and ambiguous outcomes

Scenario / fixture / test time:
Resource / timezone / initial state:
Request identifier / duplicate protection:
Backend operation / response:
Competing request outcome:
User-visible state: REQUESTED / HELD / CONFIRMED / UNKNOWN
Reconciliation evidence / recovery owner:

In an approved test environment, exercise simultaneous selections, a repeated confirmation, an expired hold and a timeout after a possible write. Check the final booking record before retrying an ambiguous operation. A second request should not create another appointment merely because the first response was lost.

Reminders and human handoff

Choose reminder timing for the service and consent rules rather than treating a fixed cascade as a proven no-show remedy. A cancellation or reschedule must update the scheduling authority and return an accurate confirmation. Test failed delivery and unavailable slots as well as the happy path.

Keep service preparation instructions under the responsible professional’s control. The assistant should not improvise medical advice, diagnoses or treatment. A handoff needs an available destination and a clear status; saying a person will respond is not proof that someone received the request.

Limit data and commitments

Collect only the information needed for the agreed booking process. Review processors, access, retention and data transfers with the responsible owner. Hosting the application on an operator’s server does not by itself establish the privacy of model calls, logs or backups.

Use the approved service catalogue for factual answers. When terms require staff assessment, say what remains unconfirmed. Do not invent discounts, availability or a guaranteed response time.

Request a scope with the scheduling system, supported channels, expected booking states and the failure that must be caught. The acceptance result should be a demonstrated state transition and recovery path, not a claimed improvement in conversion.