Bot type
A booking bot that your receptionist does not have to babysit
A Telegram appointment booking bot lets a patient pick a slot, confirm, and reschedule inside a chat, writing every change back to the practitioner calendar your staff already use. It removes the phone-tag layer around scheduling. It does not replace a practice management system, and it will not fix an overbooked diary.
Appointment booking bots: price, timeline and limits
- Fixed price
- $3,800 USD
- Delivery
- 18 calendar days from kickoff
- Broadcast ceiling
- ~30 messages/second bot-wide, ~20/minute per group
- Callback data
- 64 bytes per inline keyboard button
- Cold outreach
- Not possible — the patient must message the bot first
- Binding limit in practice
- The calendar provider API, not Telegram
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Most clinics in the Gulf are not short of enquiries. They are short of the twenty minutes a day it takes to turn enquiries into confirmed slots. Somebody sends a WhatsApp asking whether Thursday evening is free, the front desk is with a patient, the reply goes out ninety minutes later, and by then the person has booked somewhere that answered first. Nothing was mishandled. The queue was simply longer than the patience of the person in it.
The specific failure worth naming is the reschedule. A first booking is a single message; a reschedule is a negotiation, and it is where most manual scheduling collapses. The patient asks to move, the receptionist checks one practitioner diary, offers two slots, the patient takes an hour to answer, and by then one of the slots has gone. Repeat that six times a day and a full-time person is absorbed by it.
A booking bot is worth building when the calendar is the bottleneck rather than the demand. It holds a slot while the conversation is open, so an offered time cannot be taken underneath the person considering it. It sends the reminder that halves no-shows. And it handles the reschedule in the same thread as the original booking, without anyone reading back through a chat history to work out what was agreed.
How the build runs
The patient opens the bot from wherever they found you
A deep link from your Instagram bio, a Google listing or a printed QR code opens the bot with a payload identifying where they came from. The bot greets them by service rather than with a menu, because a person who scanned a code beside a dental chair is not browsing.
deep-linkSlot search runs against real availability, not a published timetable
The bot queries live calendar state for each practitioner who offers the requested service, filters by working hours and existing appointments, and offers the next few genuinely free slots. Offering a time that has already gone is the fastest way to lose the booking.
inline-keyboardThe chosen slot is held while the conversation continues
Selecting a time places a provisional hold with a short expiry. Without it, two people offered the same slot within a minute of each other both believe they have it, and one finds out when they arrive.
inline-keyboardDetails are collected in the order that matters
Name and phone first, because that is enough to salvage the booking if the person disappears halfway through. Anything the clinic needs beyond that — insurance, referral, first visit or returning — comes after the slot is already held.
commandsConfirmation writes to the calendar and back to the patient
The appointment is created in the practitioner calendar with the patient details in the event body, and the patient gets a confirmation carrying the address and a link to reschedule. One write, two audiences, no re-keying.
webhookReminders go out on a schedule the clinic sets
Typically one the day before and one two hours ahead. Each reminder carries the same reschedule button as the confirmation, so a patient who cannot make it moves the appointment instead of silently not arriving.
broadcastRescheduling reuses the same flow rather than starting a new one
The reschedule button reopens slot search with the original appointment attached, releases the old slot only once a new one is confirmed, and updates the calendar event in place so the practitioner sees a move rather than a cancellation and a mystery booking.
inline-keyboard
What Telegram will and will not let you do
A bot may send roughly 30 messages per second in total, and about 20 per minute to the same group.
A reminder run for four hundred patients cannot go out in one burst. It is queued and paced, which means scheduling reminders for a precise minute is not achievable — plan for a window, not a moment.
Telegram gives the bot no access to a phone number unless the user shares it with a contact-request button.
You cannot silently identify a returning patient by number. Either they tap to share it once, or the bot matches them on the Telegram user id it does receive — which is stable, but is not what your practice management system keys on.
Inline keyboard buttons carry at most 64 bytes of callback data.
A slot button cannot encode practitioner, service, date, time and duration as text. The button carries a short identifier and the server holds the rest, which is why slot offers have a server-side expiry rather than living purely in the message.
A bot cannot start a conversation with someone who has never messaged it.
Reminders only reach patients who booked through the bot. Importing an existing patient list and messaging them is not possible, and any vendor who says otherwise is describing a ban.
Editing a message that has already been edited to identical content returns an error rather than succeeding silently.
Slot-picker screens that refresh on a timer have to track their own state. Handled badly it produces a bot that appears frozen after a double tap; it is a small detail that accounts for a surprising share of bad booking-bot experiences.
Calendar providers rate-limit writes far more aggressively than Telegram does.
The binding constraint on a busy clinic is usually the calendar API, not Telegram. Writes are batched and retried with backoff, and a provider outage queues bookings rather than rejecting them.
When not to build this
- Your bookings are already handled inside a practice management system that patients log into and use. A second booking surface that writes into the first adds a reconciliation problem without removing work.
- Scheduling depends on a clinical judgement call — how long this particular procedure will take for this particular patient. A bot that lets patients self-select duration will produce a diary that looks full and runs late.
- Your patients are predominantly over sixty and not on Telegram. The bot will work perfectly and nobody will use it. Check the actual channel mix before building anything.
- You have one practitioner and fewer than ten appointments a day. The scheduling load does not justify the build, and a shared calendar link will get you most of the way.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework. Webhook mode only, with typed update handling. |
| Cloudflare Workers | current | Runtime. No server to keep warm and no cold start on a reminder run. |
| Cloudflare D1 | current | Appointment holds, patient records and the reminder queue. |
| TypeScript | 5.9 | Strict mode throughout. Slot arithmetic is where an untyped codebase quietly fails. |
| Zod | 4.4 | Validation at every boundary, including calendar provider responses. |
Questions people ask before committing
Can the bot write into the calendar our practitioners already use?
Yes, and it should — a booking system that keeps its own separate diary is a second source of truth and will eventually disagree with the first. The bot creates, moves and cancels events in Google Calendar or Outlook, and reads existing events so a manually blocked hour is respected.
What happens when two patients pick the same slot at the same moment?
The first selection places a hold and the second gets told the slot has just gone, with the next available times offered immediately. The hold expires after a few minutes if the conversation stalls, so an abandoned booking does not leave a slot dead for the rest of the day.
Will it reduce no-shows?
Reminders reliably reduce them, and a reschedule button in the reminder reduces them further because it gives a patient who cannot attend an easier action than doing nothing. How much depends on your baseline; anyone quoting you a percentage before seeing your data is guessing.
Can it handle Arabic and English in the same conversation?
Yes. The language is chosen on first contact and can be switched at any point without losing the booking in progress. Right-to-left rendering in Telegram is generally well behaved, though button labels need testing at real Arabic string lengths rather than at translated placeholders.
Do patients need to install anything beyond Telegram?
No. The whole flow runs in the chat, including slot selection and rescheduling. There is no app to download, no account to create and no password, which is most of why booking completion is higher here than on a web form.
Can our front desk override what the bot has done?
Yes. Staff get commands for blocking time, cancelling, moving an appointment and seeing the day ahead. Anything staff do in the calendar directly is also picked up, because the sync runs in both directions rather than treating the bot as the only writer.
What happens if the calendar provider goes down mid-booking?
The booking is recorded and queued rather than rejected. The patient gets a confirmation, the calendar write retries with backoff, and if it still fails a human is alerted with the details. Telling a patient their appointment failed because a third-party API was unavailable is not an acceptable outcome.
How long before it is actually taking bookings?
The build runs to a fixed delivery date agreed before it starts, and you see a working demo against your own calendar before any money moves. The variable is usually how quickly the clinic can decide its own rules — which services, which practitioners, what notice period.