An appointment bot that talks to the CRM in real time
A lead form collects a phone. An appointment bot reads live slots, locks one, and writes the CRM before anyone calls back.
Most site bots are contact forms with a chat skin: name, phone, “a manager will call in business hours.” For the operator that counts as a lead. For the visitor nothing has been booked. A message left at 10 p.m. is a competitor’s confirmed slot by morning.
An appointment bot does a different job. It reads the live grid in the CRM, finds an opening, reserves it, and sends a confirmation. With a language model in the loop it becomes a front-desk assistant: it talks in the visitor’s words, answers from the price list, and raises show-up rates with a reminder cascade.
A request is not a booking
In services — clinics, workshops, studios, consultancies — conversion from “left a number” to a visit collapses when more than a quarter of an hour sits between the two.
Evening and night search is a large share of intent. The person wants the question closed while the phone is in their hand. The receptionist is with a client; chat sits twenty minutes. By the callback, the lead is cold.
A form collects a number for a cold call. An automated booking closes the slot.
Three generations
| Tool | How it works | Strength | Failure |
|---|---|---|---|
| Booking widget | Slot grid on the site | Fast to stand up | Long forms; no questions; no objections |
| Button bot | Branch: site → person → day → time | Cheap to sketch | Dies on a sentence; resets to the menu |
| Front-desk assistant | Model plus schedule API | Natural language, live slots, price-list answers | Needs a CRM hook and refusal rules |
People do not speak in buttons.
“Can I see an orthodontist Tuesday after six, not the new one? And what is a first visit with a scan, roughly?”
A button tree replies with a menu. The visitor leaves.
The assistant extracts specialty, day, window, seniority, and the two services. It reads the price list. It asks the CRM for that practitioner’s Tuesday evening. It answers with two times and a range, and waits for a pick — not a diagnosis, not a made-up discount.
Channels, one grid
The visitor chooses the door. The slot table must not.
- Telegram — identity without a new app, history of visits, reminders in the thread.
- WhatsApp — official Business API for the audience that already lives there.
- Site widget — intercepts search and Google Ads traffic without sending the person off-page.
One data core. A booking started in Telegram and a booking started on the site lock the same minute. Two inboxes is how overbooking is born.
Two-phase lock
The reputational failure: the bot confirmed 15:00, the person arrives, the chair is taken by someone who phoned the desk.
Naive integrations ask for a time, then ping a human: “please put Peter down for Friday.” Two hours later the grid has already moved.
A transactional pattern:
- Read the grid at the second of the turn, from the system of record (the booking product, HubSpot, Salesforce, Pipedrive, Google Calendar — whatever actually holds the appointments).
- Soft lock. On a chosen time, hold the interval for about ten minutes as “pending.” Desk and other channels cannot take it.
- Confirm. Phone (or equivalent) confirmed, status becomes booked, a card is written with the thread.
- Timeout. Abandoned dialogue releases the slot.
A double-submit is checked twice: when the grid is shown, and at the confirm tap. The first confirm wins; the second is told the nearest remaining times.
No-show
Booking is half the job. A fifth to a third of booked visits in services simply do not arrive. An empty chair is a direct loss.
A bot that writes back to the grid:
- 24 hours: confirm / move / cancel.
- Cancel or move releases the slot immediately, not at the hour of the visit.
- Waitlist can be offered the opened window.
- Two hours: address, parking, prep (“no food for two hours”).
Show-up is an operations number, not a personality trait of the model.
What the bot must not do
- Invent prices. If the service needs an exam, the bot gives a from-range and says why.
- Hold a furious visitor. “Human,” “operator,” irritation — hand off with the transcript.
- Play doctor. No diagnosis, no drugs. Red-flag symptoms go to a person now.
- Park personal data in a random cloud. GDPR: the operator’s servers, a named processor, a retention rule. Not a public model trained on the thread.
What “it costs” is not a tariff
Depth of CRM integration and the number of channels set the work, not a public package board. A button tree that mails a human is a small brief. Live two-way booking with reminders is a different brief. A multilingual assistant on site plus Telegram and WhatsApp, on a shared memory, is another.
Code, data, and scenarios ship to the operator. There is no per-booking tax to the studio.
If two people tap the same minute, the lock decides. Nights and holidays are the point of the machine. A person is always a button away. Any schedule product with an API is in play; a closed system without one is a different conversation.
Request a scope with the CRM, the channels, and the failure you will not tolerate (overbooking, invented prices, a thread that dies at 19:00).
- Does the bot read live slots from the CRM at the moment of the turn, or mail a request to a person?
- Is there a short soft-lock so two clients cannot confirm the same minute?
- Do 24-hour and 2-hour reminders write confirm / move / cancel back into the grid?
- On 'I want a person', does the transcript go with the handoff?