Telegram booking bot: order, build or take ready (2026)

TL;DR. A booking bot looks like a weekend project: a calendar, a slot picker, a payment, a reminder. Development studios quote 1,500–3,500 EUR for exactly that — the low end being one calendar with basic reminders, the high end adding several staff members, prepayment and cancellation rules. The gap between the weekend and the three thousand euros is a second list nobody writes into the brief: race conditions, timezones, overlapping durations, restarted workers. Below: three routes — order it, build it, take a ready one — including where ordering is the correct answer.

The feature list for a booking bot fits in a chat message. A calendar. A slot picker. A payment. A confirmation. Reminders. A cancellation rule. Six items, and a developer reading them estimates a week.

Then the quote comes back at 1,500–3,500 EUR and it reads like padding. It usually isn’t. It’s the second list.

The list nobody writes into the brief

• Two customers tap 15:00 within the same second. Who gets it, and how do you know?
• Your customer is in Lisbon, you are in Warsaw. Whose 15:00 is on the screen?
• A 90-minute session with a 15-minute gap after it — which other slots does that block?
• The reminder job restarts halfway through its run. Who gets a second reminder?
• A booking moves to Thursday. Do its reminders move with it?

None of these appear in a feature list, and every one is a support message when it goes wrong. That’s the part that costs money, whichever route you take. The routes differ mainly in who pays it, and when.

Route 1 — order a custom build

What you get. Exactly what you asked for, in your branding, on your infrastructure, with no plan limits and no vendor. If the job is genuinely unusual, this is the only route that reaches it.

What it costs. Studios put a simple booking bot with basic reminders at the bottom of the 1,500–3,500 EUR band, and one with several practitioners, prepayment and cancellation policy near the top. That’s a market estimate rather than a price list — it varies by country and studio.

The second bill. A booking bot is never finished. Telegram ships API versions, timezone databases update twice a year, a customer finds a state nobody tested. After handover that is either a retainer or your own weekends — and the quote rarely includes it.

Route 2 — build it yourself

n8n templates and GitHub repositories do the visible part convincingly in an afternoon: a slot list, an inline keyboard, a confirmation message. Nothing about that is wrong — if a handful of bookings a week is the whole job, it may be the last answer you need. What goes first is the invisible part.

Double booking. The natural implementation reads the taken slots, checks the requested one, and writes. Two requests inside the same second both pass the check. The fix is a uniqueness rule in the database, not in the code — and it usually arrives after the first apology.

Overlap, not equality. The intuitive gap check compares start times. But a 90-minute booking with a 15-minute buffer conflicts with anything whose range touches it, which is a different question. Comparing start times returns a calendar that looks right and sells slots you cannot serve.

Duplicate reminders. Send them in a loop and any restart replays them. Preventing that means marking each reminder as sent, individually — no template ships with it.

Timezones. The one that survives longest before biting, because it works perfectly until the first customer in another country — or the last Sunday in October.

Route 3 — take a ready one

The trade is the mirror image: no build, no bill — and no unusual requirements either. What you get is a set of decisions already made. In AdminHub’s booking flow:

The calendar. Working hours are intervals per weekday, and a weekday can hold more than one — 10:00–13:00 plus 15:00–18:00 is a lunch break, not a special case. A buffer of 0 to 120 minutes sits on both sides of every booking, and a candidate slot is rejected when its range overlaps a booking, not when its start time matches. Nothing is bookable inside the next two hours, the window ahead is 30 days by default, and closed date ranges take out holidays and a week in August. One timezone per service, sent with every slot so nobody guesses whose clock the 15:00 is.

Reminders. One 24 hours before the slot, one an hour before. Each is stamped the moment it is sent, so a restarted worker cannot repeat it, and both stamps are cleared when a booking moves, so the new time gets its own. They are always sent by your bot — the platform’s bot never messages your customers — so the reminder lands in the chat where they booked, under the name they booked with.

Cancellation. A window you set, 24 hours by default. Inside it the customer cancels themselves; outside it they can’t, and it comes to you. You can cancel or move any booking at any time, and the customer is told in their bot chat. Money is where honesty matters: AdminHub never holds it, so nothing is refunded automatically — a refund is your action, on the rail the payment arrived on. Once the slot’s end time passes the booking closes itself, with no automatic review request: unsolicited “leave a review” prompts teach customers that your bot is spam.

Prepayment. The booking record is created when the invoice is paid, not when the slot is tapped — that is the whole accountability mechanism. There is no partial-deposit field: the invoice is the product’s price, so holding a smaller amount up front is a pricing decision rather than a setting. The note a customer writes while picking a slot travels with the booking, so you walk in knowing why they came.

The payment rail is not a choice

Worth saying plainly, because briefs get written around it. Telegram’s rule is binary. A service delivered in the real world — a visit, a haircut, a call-out — is paid by card through a payment provider. A service delivered digitally, like a video consultation, is paid in Telegram Stars. One product carries one rail. “Let the customer choose” is not something any of the three routes can build.

Who’s who

	Custom build	Self-built on a template	AdminHub bookings
Up-front cost	1,500–3,500 EUR, per studio quotes	Your time	None
Time to first booking	Weeks	An afternoon, then debugging	Same day
Double-booking guard	Developer-dependent	Usually missing	Database constraint
Reminders	Built to spec	Hand-rolled, repeat on restart	24h and 1h, stamped once each
Unusual requirements	Anything you can pay for	Anything you can build	Only what’s already there
Who’s on call	You, or a retainer	You	AdminHub
Running cost	Server plus maintenance	Server	Free tier; Pro is 400 Stars every 30 days

If… then…

If…	Then…
One calendar, one person, customers already in Telegram	Take a ready one — the six-item list is the whole job
Several practitioners sharing rooms or equipment	Order a custom build — that’s a scheduling graph, not a calendar
Bookings must also arrive from a website, a phone line or a marketplace	Order a custom build, or keep a domain SaaS and use Telegram for discovery
A clinic record system, fiscal hardware or an insurer’s API is in the loop	Order a custom build — integration is what the band actually prices
A few bookings a week and building it is the interesting part	Build it yourself — but add the database constraint before the first apology

What to do now

• Write the second list, not the first. Race conditions, timezones, buffers, restarts, cancellation policy — that list is the real scope, for a studio brief or for n8n.
• Briefing a studio, price the second year too — ask what maintenance costs after handover, in writing.
• Building it yourself, put the uniqueness rule in the database first. One constraint, and it prevents the failure customers never forgive.
• If a ready flow covers it, find out in an afternoon. One service, real working hours, one test booking on your own account.

---

For the booking format itself — how prepayment and in-chat reminders work against no-shows — see Services on Telegram. For which rail a product may take, see Stars vs card payments. The same build-or-take question for content pipelines is in From n8n to a ready service. To see the flow, open Services for Telegram.