I Built a Telegram Bot for a Restaurant That Actually Talks Like a Human
Most chatbots are annoying. You ask a simple question, they dump a PDF menu on you and call it a day. So when a restaurant client asked me for a Telegram bot, I promised myself it wouldn’t be one of those.
The goal was simple: a bot that remembers what you said two messages ago, answers in the restaurant’s voice, and doesn’t fall apart when someone asks a two-part question. I built the Telegram side on n8n — a drag-and-drop automation tool — with an AI Agent node doing the brain work. Here’s the honest rundown of what worked and what didn’t.
How the Bot Is Put Together
Think of it like a small restaurant team. When a customer messages the bot on Telegram, a trigger catches the message and passes it along — like a waiter taking the order to the kitchen.
The kitchen is the AI Agent node. Before it ever replies, it’s loaded with a system prompt containing the full menu, opening hours, and a few notes on tone (“be warm, be brief, never say you’re an AI unless asked”). That last part matters more than you’d think. Without tone instructions, every bot sounds like a Terms of Service page.
The result feels different from a canned bot. Ask “got anything spicy under 200 baht?” and it actually answers that question, not just links to the menu.
Where the Simple Version Broke
My first version was naive: one AI node, one prompt, ship it. It died the moment real customers showed up.
The killer was multi-part questions. Someone would type, “Do you have vegetarian options and can I book for 6 on Friday?” A single agent tried to handle both at once and produced a mushy half-answer that was good at neither. Classic case of one chef trying to cook and answer the phone simultaneously.
The fix was splitting the flow in two:
- An intent classifier sits before the agent — a quick step that figures out what the customer actually wants (chat, book, or both).
- Depending on the intent, the message routes to either a dedicated booking sub-flow or the conversational agent.
Once I built the Telegram routing properly, multi-part questions stopped being scary. The classifier spots “book” and hands the reservation bits to the booking flow, while the agent handles the menu chatter.
Two Problems I Didn’t See Coming
1. Traffic spikes drop messages
During lunch rush, the bot got hammered with messages and Telegram’s rate limits kicked in — replies simply got dropped. I added a simple queue node, which is basically a waiting line, so messages get answered one by one instead of all fighting for the door. Cheap fix, huge difference.
2. Memory without over-engineering
For the bot to personalise replies, it needs short-term memory. The heavyweight solution is a vector database — total overkill for a restaurant bot. Instead, I used a lightweight key-value store (think of it as a labelled shoebox per customer) keyed on the Telegram chat ID. It remembers the last few messages per person, and that’s enough. Don’t build a spaceship when a bicycle does the job.
Things You Need If You Want to Build This
- n8n — the automation backbone. Self-hosted or cloud, both work fine for this.
- A Telegram BotFather token — free, takes two minutes to set up inside Telegram itself.
- An OpenAI or Anthropic API key — this powers the AI Agent node’s conversational brain.
Pro tip: keep your system prompt in a separate editable document, not hardcoded. Menus change weekly at some restaurants, and you don’t want to redeploy the whole flow for a new dessert.
Frequently Asked Questions
Do I need to know how to code to build a Telegram bot like this?
Not really. n8n is mostly drag-and-drop. I’d say 90% of this build is connecting nodes and writing good prompts. The remaining 10% is light logic for routing, and you can learn that from free tutorials in an afternoon.
How much does it cost to run per month?
Surprisingly little. Self-hosted n8n can run on a small VPS for about $5-10 a month, and the AI API calls for a single restaurant’s traffic usually land under $20. Way cheaper than paying a human to answer the same questions all day.
Why did a single AI agent fail at multi-part questions?
One agent trying to chat and manage bookings at the same time gets pulled in two directions and does both badly. Splitting intent first — “is this a chat or a booking?” — lets each path focus on one job, and the quality jumps immediately.
Do customers realise they’re talking to a bot?
Most figure it out, and honestly they don’t mind — as long as the replies are useful and on-topic. The tone instructions in the system prompt keep it sounding like the restaurant’s staff rather than a generic robot, which is what people actually care about.
Is a vector database needed for memory?
No, and this was my biggest lesson. For short conversational memory, a simple key-value store keyed on the chat ID does the job. Save the heavy infrastructure for projects that genuinely need it.
Final Thoughts
If I built the Telegram bot again, I’d start with the intent classifier from day one and skip the single-agent fantasy entirely. That one change saved the project. My advice: launch small, watch real conversations, and fix what actually breaks instead of what you imagine might break. The best part? The client’s staff now spend their time on food, not typing “we open at 11” forty times a day.
ชอบบทความนี้? ค้นพบสินค้าที่เกี่ยวข้องบน Shopee