Restauracja tajska

Klient to tajska restauracja z otwartą kuchnią i menu, w którym połowa pozycji wymaga wyjaśnienia: nieznane gościom składniki, poziomy ostrości, sosy i desery trudne do wyobrażenia na podstawie samego opisu. Goście są różnorodni: turyści, dla których język restauracji nie jest ojczysty, i lokalni klienci przychodzący „spróbować Tajlandii”. Klasyczne papierowe menu powodowało trzy problemy jednocześnie: szybko się dezaktualizowało — każda zmiana ceny lub pozycji oznaczała dodruk i koszty; nie pokazywało dań „na żywo” — zdjęcia trzeba było doklejać jako osobne wkładki; a do tego przeciążało kelnerów. W godzinach szczytu gość czekał 5–10 minut tylko po to, by złożyć zamówienie, a błędy „źle usłyszał — źle przygotował” zdarzały się regularnie. Osobnym problemem była ewidencja: zamówienia i sumy ze zmian podliczano ręcznie, a właściciel nie miał dokładnego obrazu sali w czasie rzeczywistym. Restauracja chciała umieścić publiczny link do menu w wizytówce Google Maps — miejscu, z którego dziś przychodzi znacząca część nowych gości.

Zaprojektować i zbudować system, w którym jedno menu działa w dwóch trybach, a zamówienie trafia do kuchni bez żadnego

ogniwa „przekazywania dalej”. Zadanie składało się z czterech części. Po pierwsze, publiczne menu pod stałym linkiem, które można umieścić w Google Maps i mediach społecznościowych oraz drukować w materiałach reklamowych. Po drugie, prywatne linki do tego samego menu, które po zeskanowaniu QR na stoliku zmieniają prezentację w pełnoprawne zamówienie: gość wybiera pozycje i wysyła je do Telegram-bota personelu, a numer stolika jest zapisany w samym linku. Po trzecie, Telegram-bot pracowników restauracji, do którego trafiają wszystkie zamówienia, gdzie prowadzona jest ewidencja i obliczane są kwoty. Po czwarte, panel administracyjny, w którym właściciel dodaje, edytuje i usuwa pozycje menu bez programisty. System musiał działać na podstawowych urządzeniach personelu i wymagać od gościa tylko aparatu w telefonie.

Dla gościa system wygląda jak „po prostu strona z menu”, ale pod spodem kryje się przemyślana logika dwóch trybów dostępu i trzech ról: gościa, personelu i administratora menu. Każda decyzja techniczna odpowiadała na jedno pytanie: jak usunąć tarcie ze ścieżki zamówienia?

• Zaprojektowaliśmy architekturę dwóch trybów: jedna baza treści, dwa zakresy dostępu. Publiczny link otwiera prezentacyjne menu — kategorie, zdjęcia, skład, poziomy ostrości i ceny, bez przycisków zamówienia — do prezentacji kuchni w Google Maps i mediach społecznościowych. Linki stolików zawierają parametr aktywujący tryb zamawiania: pojawia się koszyk, komentarze do pozycji i wysyłka zamówienia. Treść jest zawsze ta sama, więc synchronizacja nie jest potrzebna z założenia.
• Przygotowaliśmy publiczne menu: szybką, responsywną stronę, która otwiera się w sekundę nawet przez mobilny internet na zewnątrz, ponieważ gość często uruchamia ją bezpośrednio z wizytówki Google Maps, stojąc obok restauracji. Są tam zdjęcia dań, opisy z oznaczeniem ostrości i składu, kategorie od zup po napoje i desery oraz aktualne ceny. Hosting działa poza siecią wewnętrzną restauracji, więc link jest stabilny niezależnie od Wi-Fi lokalu i obciążenia sali.
• Wygenerowaliśmy kody QR dla stolików: każdy stolik otrzymał unikalny QR z zapisanym w linku numerem stolika. Gość nie wybiera z listy „siedzę przy stoliku N” ani nie podaje miejsca kelnerowi — system rozpoznaje je z linku. Usunęło to główne źródło błędów w podobnych systemach i od pierwszej sekundy przypisywało zamówienie do właściwego stolika. Tabliczki QR umieściliśmy tak, by wygodnie skanować je z dowolnego miejsca przy stole.
• Zbudowaliśmy koszyk i wysyłkę zamówienia bez rejestracji. Gość dodaje pozycje, wpisuje komentarz do dania („bez orzeszków”, „ostrzejsze”, „sos osobno”), sprawdza wybór i potwierdza. Zamówienie trafia do Telegram-bota personelu z unikalnym numerem zamówienia i numerem stolika. Nie trzeba instalować aplikacji, wpisywać numeru telefonu ani zakładać konta: droga od zeskanowania do wysłania zajmuje jedną–dwie minuty i jest celowo krótsza niż każdy alternatywny scenariusz.
• Opracowaliśmy Telegram-bota personelu. Wszystkie zamówienia przychodzą w czasie rzeczywistym z unikalnym numerem, stolikiem, pozycjami, komentarzami gości i sumą. Oprócz przyjmowania zamówień bot prowadzi ewidencję: historię według zmiany i dnia, sumy dla menu i pozycji, ponowne wysłanie oraz statusy obsługi. Personel pracuje w Telegramie, który i tak jest otwarty na urządzeniach służbowych — nie trzeba instalować osobnego oprogramowania ani szkolić zespołu; interfejsem jest znany czat.
• Zbudowaliśmy panel administracyjny menu: dodawanie pozycji, edycję cen, opisów, zdjęć i kategorii, usuwanie oraz natychmiastowe oznaczanie „dostępne/niedostępne”. Każda zmiana od razu pojawia się w publicznym menu i trybie zamówień, bo to jedno i to samo menu. Właściciel zarządza ofertą z telefonu, bez programisty i bez kontaktowania się z nami w każdej drobnej sprawie.
• Przemyśleliśmy sytuacje brzegowe na sali: jeśli gość zamówi pozycję, której właśnie zabrakło w kuchni, administrator ukrywa ją w panelu i znika z trybu zamawiania; jeśli zamówienie przypadkiem wysłano dwa razy, personel widzi oba i odrzuca duplikat; jeśli zmieni się cena, jedna edycja aktualizuje ją wszędzie. To właśnie takie codzienne sytuacje decydują, czy system sprawdzi się w działającej restauracji.
• Uruchomiliśmy system i przeszkoliliśmy personel: wydrukowaliśmy i rozłożyliśmy kody QR, poinstruowaliśmy kelnerów w obsłudze bota, nadzorowaliśmy pierwsze zmiany, zbieraliśmy opinie gości i personelu oraz poprawialiśmy szczegóły interfejsu na podstawie rzeczywistej eksploatacji.

O sukcesie projektu zdecydowały trzy rozwiązania. Po pierwsze „jedno menu, dwa tryby”: restauracja utrzymuje jedną treść, a nie dwie strony, dzięki czemu publiczna prezentacja i ścieżka zamawiania nigdy się nie rozchodzą. Po drugie Telegram jako terminal personelu: brak kosztów sprzętu, zamówienia przychodzą tam, gdzie pracownicy już są, a historia zapisuje się automatycznie, bez „zeszytów ewidencji”. Po trzecie numer stolika zapisany w linku QR: system nie pyta gościa o coś, co może ustalić sam. Cały system kosztował mniej niż jeden pełny dodruk papierowych menu i działa dalej bez abonamentów, maszyn ani specjalnego wyposażenia sali.

Co proponujemy restauracji jako kolejny krok:

• Płatność bezpośrednio w menu: gość opłaca rachunek przy stoliku bez czekania na kelnera, stoliki szybciej się zwalniają, a w godzinach szczytu znika kolejka „po rachunek”.
• Wielojęzyczność: angielskie i inne wersje opisów dań dla turystów — ta sama treść z przetłumaczonymi warstwami.
• Widoczność GEO (Generative Engine Optimization): uporządkowane informacje o kuchni, menu i atmosferze, aby asystenci AI prawidłowo wymieniali restaurację w odpowiedzi na pytanie „gdzie spróbować kuchni tajskiej” — w kanale, z którego coraz więcej gości wybiera lokale.
• Analityka menu: które dania są oglądane, ale niezamawiane, i które pozycje „podnoszą” rachunek — podstawa optymalizacji asortymentu i ofert sezonowych.