Thai restaurant

The client is a Thai restaurant with an open kitchen and a menu where half the items need explanation: unfamiliar ingredients, spice levels, sauces and desserts that are hard to imagine from a verbal description. The audience is mixed: tourists for whom the restaurant’s language is far from native, and local guests who come to “try Thailand”. A traditional paper menu caused three problems at once: it quickly went out of date, since every price or item change meant reprinting and expense; it did not show dishes “in real life”, so photos had to be pasted in as inserts; and it overloaded waiters. At peak times, guests waited 5–10 minutes just to place an order, and “heard the wrong thing, cooked the wrong thing” mistakes were common. Accounting was another pain: orders and shift totals were compiled by hand, leaving the owner without an accurate real-time picture of the dining room. The restaurant wanted its public menu link on its Google Maps listing, a point from which a significant share of first-time guests now arrive.

Design and build a system where one menu works in two modes and orders reach the kitchen without any “retelling” in

between. The task had four parts. First, a public menu on a stable link for Google Maps, social media and printed promotional materials. Second, private links to the same menu that turn the display into a working order when a table QR is scanned: guests select items and send them to staff in a Telegram bot, with the table number embedded in the link. Third, a Telegram bot for restaurant staff that collects every order, keeps records and totals amounts. Fourth, an admin panel where the owner can add, edit and remove menu items without a developer. The system had to run on the staff’s basic devices and require nothing from guests except their phone camera.

To a guest, the system looks like “just a menu website”, but underneath is carefully designed logic for two access modes and three roles: guest, staff and menu administrator. Every technical decision answered one question: how can we remove friction from the ordering journey?

• Designed a two-mode architecture with one content database and two access paths. The public link opens a showcase menu with categories, photos, ingredients, spice levels and prices—but no order buttons—presenting the cuisine for Google Maps and social media. Table links contain a parameter that activates ordering: a cart, item comments and order submission appear. The content is always the same, so synchronization is unnecessary by design.
• Built a public menu: a fast, responsive page that opens in a second even on mobile data outdoors, since guests often launch it from Google Maps while standing near the restaurant. It includes food photos, descriptions noting spice and ingredients, categories from soups to drinks and desserts, and current prices. Hosting sits outside the restaurant’s internal networks, so the link works reliably regardless of its Wi-Fi or how busy the dining room is.
• Generated table QR codes: each table received a unique QR with its number embedded in the link. Guests do not select “I’m at table N” from a list or tell a waiter where they are—the system identifies the table from the link. This removed the main source of error in similar systems and assigned each order to a table from the first second. QR placards were positioned for convenient scanning from anywhere at the table.
• Built a cart and order submission with no registration. Guests add items, leave a dish comment (“no peanuts”, “spicier”, “sauce on the side”), review the order and confirm it. The order reaches the staff Telegram bot with a unique order number and table number. No app installation, phone number or account is needed: the journey from scan to submission takes one or two minutes and is deliberately shorter than any alternative.
• Developed the staff Telegram bot. All orders arrive in real time with a unique number, table, items, guest comments and total. The bot also keeps records: order history by shift and day, totals by menu and item, resending and processing statuses. Staff work in Telegram, already open on their work devices; there is no separate software to install or training to attend—the interface is a familiar chat.
• Built a menu admin panel for adding items; editing prices, descriptions, photos and categories; deleting items; and instantly marking them “available/unavailable”. Every change immediately appears in both the public menu and ordering mode because they are the same menu. The owner manages the selection from a phone without a developer or contacting us for every small change.
• Thought through edge cases in a live dining room: if a guest orders an item the kitchen has just run out of, an administrator hides it in the panel and it disappears from ordering; if an order is accidentally sent twice, staff see both and reject the duplicate; if a price changes, one edit updates it everywhere. Such everyday situations determine whether a system will take hold in a real restaurant.
• Launched the system and trained staff: printed and placed the QR codes, briefed waiters on the bot, supervised the first shifts, gathered feedback from guests and staff, and adjusted interface details based on live use.

Three decisions determined the project’s success. First, “one menu, two modes”: the restaurant maintains one content set, not two websites, so the public display and ordering path never diverge. Second, Telegram as the staff terminal: no equipment cost, orders arrive where employees already work, and order history is stored automatically rather than in “accounting notebooks”. Third, the table number embedded in the QR link: the system does not ask guests for information it can determine itself. The entire system cost less than one complete reprint of the paper menus and remains in operation without subscriptions, machines or special equipment in the dining room.

What we propose as the restaurant’s next step:

• Payment directly in the menu: guests close the bill from their table without waiting for a waiter, speeding up table turnover and removing the “waiting for the bill” queue at peak times.
• Multiple languages: English and other versions of dish descriptions for tourist traffic, using the same content with translated layers.
• GEO visibility (Generative Engine Optimization): structured facts about the cuisine, menu and atmosphere so AI assistants accurately mention the restaurant in answers to “where can I try Thai food”—a channel more and more guests use to choose restaurants.
• Menu analytics: which dishes guests view but do not order, and which items “pull up” the check, providing a basis for menu optimization and seasonal offers.