Restauracja nie potrzebuje kolejnej aplikacji w App Store i Google Play, żeby pozwolić gościowi zamówić obiad z telefonu. W większości lokali instalowanie aplikacji byłoby wręcz dodatkowym problemem: klient przychodzi zjeść, a nie zakładać konto, podawać e-mail i czekać na pobranie kilkudziesięciu megabajtów danych. Znacznie prostszy model zaczyna się od kodu QR przypisanego do stolika, a kończy na zamówieniu wysłanym z przeglądarki bezpośrednio do obsługi lub kuchni.
Technicznie nie jest to szczególnie egzotyczny produkt. Mobilna aplikacja webowa może działać w Safari, Chrome czy Firefoxie, a użytkownik nie musi niczego instalować. Trudność zaczyna się gdzie indziej: przy synchronizacji dostępności dań, płatnościach, obsłudze anulowanych transakcji, przekazywaniu zamówień do właściwego stanowiska, fiskalizacji i sytuacji, w której w sobotę o 19:30 restauracja ma pełną salę, a system przestaje odpowiadać.
Dlatego cyfrowe menu z zamawianiem przy stoliku jest dobrym pomysłem na usługę technologiczną, ale tylko wtedy, gdy projektuje się je jako narzędzie operacyjne restauracji, a nie efektowną kartę dań z kodem QR.
Nie buduj aplikacji. Zbuduj możliwie krótki proces od zeskanowania QR do kuchni
Najlepszy scenariusz dla gościa ma pięć kroków: skanowanie kodu, wybór produktów, konfiguracja zamówienia, płatność lub potwierdzenie, wysłanie zamówienia. Rejestracja konta nie powinna być jednym z nich.
Kod QR przy stoliku powinien identyfikować lokal i konkretny stolik. Przykładowo stolik 12 prowadzi do adresu w rodzaju menu.restauracja.pl/t/12. Gość nie wpisuje numeru stolika ręcznie, więc odpada jedna z częstszych przyczyn pomyłek.
Jeszcze lepiej, jeśli kod nie prowadzi bezpośrednio do długiego adresu dostawcy systemu. Restauracja może używać własnej domeny albo kontrolowanego adresu przekierowującego. Dzięki temu po zmianie dostawcy technologii nie trzeba wymieniać 40 tabliczek QR na stolikach — wystarczy zmienić cel przekierowania.
Po otwarciu menu użytkownik powinien od razu zobaczyć:
-
kategorie i aktualne ceny,
-
produkty chwilowo niedostępne,
-
warianty, np. 250 lub 400 g,
-
dodatki i zamienniki,
-
informacje o składzie oraz alergenach,
-
czas oczekiwania, jeśli lokal chce go publikować,
-
jednoznaczną informację, że zamówienie dotyczy konkretnego stolika.
Największy błąd projektowy to skopiowanie papierowego menu do PDF. PDF nie jest dobrym menu mobilnym: trzeba go powiększać, trudno aktualizować pojedyncze pozycje, nie prowadzi naturalnie do koszyka i zwykle fatalnie działa na ekranie o szerokości 360–430 pikseli.
Produkty powinny więc funkcjonować jako rekordy w bazie danych. „Burger klasyczny” ma cenę, kategorię, status dostępności, opis, skład, alergeny, warianty oraz listę możliwych dodatków. Jeżeli kuchni skończy się wołowina, manager wyłącza produkt jednym przełącznikiem. Zmiana powinna pojawić się na telefonach klientów praktycznie od razu, a nie po pół godzinie z powodu agresywnego cache’owania.
To właśnie zarządzanie dostępnością jest ważniejsze niż efektowna animacja przewijania karty.
Samo zamawianie można prowadzić w dwóch modelach.
Pierwszy to zamów i zapłać. Gość płaci BLIK-iem, kartą, Apple Pay lub Google Pay, a dopiero potwierdzona płatność uruchamia zamówienie. Ten model ogranicza fałszywe zamówienia i upraszcza rozliczenie stolika.
Drugi to zamów teraz, zapłać później. Jest wygodny w restauracjach z tradycyjną obsługą kelnerską, ale stwarza więcej problemów. Zdjęcie kodu QR ze stolika można zachować i wykorzystać poza lokalem. Jeżeli każde bezpłatne zamówienie automatycznie trafia na kuchnię, ktoś może złożyć fikcyjne zamówienie do stolika 8 z drugiego końca miasta.
Nie warto próbować rozwiązywać tego wyłącznie geolokalizacją telefonu. GPS wewnątrz budynków bywa zbyt niedokładny. Bezpieczniejsza zasada brzmi: zamówienia opłacone można automatycznie kierować dalej, a zamówienia z płatnością późniejszą powinny wymagać potwierdzenia przez obsługę, przynajmniej w pierwszej wersji systemu.
W tle potrzebny jest prosty, ale rygorystyczny mechanizm statusów:
koszyk → oczekiwanie na płatność → opłacone → przyjęte → przygotowywane → gotowe/wydane → zamknięte.
Nie wolno uznać zamówienia za zapłacone tylko dlatego, że klient wrócił z bramki płatniczej na stronę restauracji. Potwierdzenie powinno przyjść bezpośrednio od operatora płatności. System musi też obsługiwać ponowione komunikaty w taki sposób, aby ten sam burger nie został wysłany na kuchnię dwa razy. W praktyce oznacza to stosowanie unikalnego identyfikatora zamówienia i mechanizmu idempotencji.
To mało efektowna część produktu. I właśnie ona odróżnia użyteczny system restauracyjny od demonstracyjnego projektu programistycznego.
Co musi zawierać wersja, za którą restaurator rzeczywiście będzie chciał płacić
Najprostszy produkt można uruchomić bez integracji z POS. Restauracja dostaje panel administracyjny, menu QR i tablet, na którym pojawiają się nowe zamówienia. To rozsądny sposób na pilotaż, ponieważ integracja z systemami sprzedażowymi potrafi pochłonąć więcej pracy niż cały frontend dla klienta.
MVP powinno obejmować przede wszystkim:
-
osobny kod QR dla każdego stolika,
-
mobilne menu bez instalowania aplikacji,
-
panel do edycji cen, pozycji i dostępności,
-
warianty i dodatki do produktów,
-
skład oraz alergeny,
-
koszyk,
-
zamówienia do stolika,
-
panel obsługi lub prosty KDS, czyli ekran zamówień kuchennych,
-
powiadomienie o nowym zamówieniu,
-
możliwość anulowania pozycji,
-
historię zamówień,
-
podstawowy raport sprzedaży,
-
eksport danych,
-
minimum dwie wersje językowe tam, gdzie lokal obsługuje turystów.
Płatności online warto dołożyć zaraz po sprawdzeniu procesu zamówienia, a integrację z POS dopiero wtedy, gdy ręczne przenoszenie danych rzeczywiście zaczyna przeszkadzać.
Przy 5–10 zamówieniach QR dziennie dodatkowy tablet może wystarczyć. Przy kilkudziesięciu zamówieniach samoobsługowych każdego dnia przepisywanie każdej pozycji do POS staje się absurdalne. Pojawiają się opóźnienia, różnice w rachunkach i błędy przy dodatkach. Wtedy synchronizacja powinna objąć przynajmniej produkty, ceny, dostępność i zamówienia.
Trzeba też uwzględnić routing. Kawa powinna trafić do baru, pizza na stanowisko kuchenne, a deser do odpowiedniej sekcji. Jedno zamówienie klienta może więc wygenerować kilka komunikatów produkcyjnych.
Nie zaczynałbym natomiast od:
-
programu punktowego,
-
rozbudowanych profili klientów,
-
push notifications,
-
systemu rezerwacji,
-
własnej aplikacji iOS i Android,
-
rekomendacji dań opartych na AI,
-
skomplikowanego dzielenia rachunku między pięć osób.
Zwłaszcza split payment przy jednym stoliku szybko komplikuje logikę. Trzeba obsłużyć częściowo opłacone zamówienie, napiwki, zwroty jednej pozycji, zmianę liczby osób i sytuację, gdy ostatni klient nie zapłaci swojej części. To funkcja na późniejszy etap, nie na pierwsze wdrożenie.
Ceny konkurencyjnych usług pokazują, w jakim przedziale trzeba się zmieścić. We wrześniu 2026 r. publiczny cennik Choice pokazuje m.in. 100 zł miesięcznie za plan Standard, 219 zł za Smart i 309 zł za Pro przy płatności rocznej. UpMenu podaje 169 zł miesięcznie za lokal w Basic, 289 zł w Standard i 499 zł w Premium, a cyfrowe menu QR jest oferowane od 169 zł miesięcznie za lokal.
Nowa usługa nie może więc kosztować 1500 zł miesięcznie tylko dlatego, że ma kod QR i panel React. Taki produkt musi rozwiązywać zdecydowanie więcej problemów, żeby restaurator zaakceptował tę cenę.
Rozsądny cennik do przetestowania na rynku mógłby wyglądać następująco:
-
149 zł/mies. – Menu: menu QR, panel, składniki, alergeny, wersje językowe i kody stolików;
-
299 zł/mies. – Order: menu, zamówienia przy stoliku, tablet/KDS, statusy i raporty;
-
499 zł/mies. – Pay/POS: zamówienia, płatności, API oraz gotowe integracje;
-
490–990 zł jednorazowo za wdrożenie: konfiguracja lokalu, import menu, przygotowanie QR i szkolenie;
-
przy budowie nietypowego konektora do POS trzeba liczyć osobny budżet — roboczo 2–8 tys. zł za prostą integrację, a przy zamkniętym lub słabo udokumentowanym systemie kwota może być wyraźnie wyższa.
To nie powinien być cennik prowizyjny przypominający marketplace dostawczy. Właściciel lokalu łatwiej zaakceptuje stały abonament plus rzeczywisty koszt operatora płatności niż kolejną kilkuprocentową prowizję od każdego rachunku.
Koszt płatności też trzeba policzyć, a nie schować drobnym drukiem. Przy standardowej stawce Stripe dla karty z Europejskiego Obszaru Gospodarczego opłata wynosi obecnie 1,5% + 1 zł, natomiast BLIK 1,6% + 1 zł.
Przy rachunku 45 zł oznacza to około:
-
1,68 zł za standardową kartę EOG,
-
1,72 zł za BLIK.
Przy rachunku 120 zł będzie to odpowiednio około:
-
2,80 zł za kartę,
-
2,92 zł za BLIK.
Stała złotówka w opłacie sprawia, że mikropłatności wyglądają procentowo gorzej. Dlatego nie ma sensu zachęcać gościa do osobnego opłacania kawy za 12 zł, potem deseru za 18 zł i kolejnego napoju za 15 zł, jeżeli cały stolik może prowadzić jeden otwarty koszyk.
Najpierw niezawodność operacyjna, dopiero później skalowanie usługi
Pierwszy lokal powinien być poligonem doświadczalnym, a nie klientem numer jeden w planowanej sieci stu restauracji. Dobry pilotaż to jeden lokal, około 15–30 stolików i 30 dni rzeczywistej pracy.
Nie trzeba od razu podłączać każdego systemu restauracyjnego. Najpierw trzeba sprawdzić, czy goście w ogóle korzystają z rozwiązania oraz gdzie pojawiają się interwencje personelu.
W czasie pilota warto mierzyć nie tylko liczbę zamówień, ale przede wszystkim:
-
ile osób skanuje QR i przechodzi do koszyka,
-
ile rozpoczętych płatności kończy się powodzeniem,
-
ile zamówień trzeba poprawić ręcznie,
-
ile razy produkt był dostępny cyfrowo, choć kuchnia już go nie miała,
-
ile pojawiło się zamówień podwójnych,
-
ile minut mija od złożenia zamówienia do pojawienia się go na ekranie kuchni,
-
ile razy pracownik musi tłumaczyć klientowi, jak użyć systemu,
-
jak często gość wybiera tradycyjną obsługę zamiast QR.
Jedno kryterium techniczne powinno być bezwzględne: opłacone zamówienie nie może zginąć. System, który raz na sto transakcji przyjmuje pieniądze i nie przekazuje zamówienia restauracji, nie jest „prawie gotowy”. Jest niegotowy.
Drugi problem to internet. Lokal potrzebuje procedury na awarię Wi-Fi, terminala, operatora płatności albo samego systemu SaaS. Kod QR nie może być jedyną drogą złożenia zamówienia. Kelner i tradycyjna sprzedaż muszą pozostać planem awaryjnym.
Jest też mniej oczywisty problem prawny. Cyfrowego menu nie należy traktować jako pretekstu do usunięcia z lokalu wszystkich innych informacji o składzie dań. Polskie zasady dotyczące żywności nieopakowanej wymagają udostępnienia klientowi m.in. nazwy produktu, wykazu składników i informacji o alergenach. Lista unijna obejmuje 14 grup alergenów.
Co szczególnie ważne, polska Inspekcja Jakości Handlowej Artykułów Rolno-Spożywczych wskazuje, że sam kod QR lub odesłanie klienta do strony internetowej nie jest wystarczającą formą udostępnienia obowiązkowych informacji o składzie w lokalu. Klient powinien mieć do nich bezpośredni dostęp bez konieczności pytania pracownika.
Dobrze zaprojektowana usługa powinna więc automatycznie generować z tej samej bazy danych:
-
mobilne menu QR,
-
kartę składników i alergenów do wydruku,
-
wersję przeznaczoną na restauracyjny tablet lub ekran,
-
plik aktualizacyjny, który można wydrukować po zmianie receptury.
To ma dodatkową zaletę: kuchnia i sala pracują na jednej wersji danych zamiast trzech różnych arkuszy Excela.
Trzeba również rozwiązać fiskalizację. Sam fakt, że klient zamówił i zapłacił w przeglądarce, nie zastępuje ewidencji sprzedaży. Stacjonarne placówki gastronomiczne należą do branż objętych obowiązkiem stosowania kas online. System zamówień musi więc pasować do faktycznego procesu fiskalnego lokalu — przez integrację z POS, odpowiednie oprogramowanie fiskalne albo jasno opisaną procedurę po stronie obsługi.
Nie można sprzedawać restauratorowi obietnicy: „BLIK wpada bezpośrednio, więc kasa nie jest potrzebna”. To proszenie się o problem.
Podobnie z danymi klientów. Przy zamówieniu do stolika nie ma powodu wymagać imienia, nazwiska, numeru telefonu, daty urodzenia i utworzenia profilu. Do realizacji zamówienia wystarczy najczęściej identyfikator transakcji oraz stolik. Dane karty powinien przetwarzać operator płatności; aplikacja restauracyjna potrzebuje statusu płatności, a nie numeru karty.
Dopiero po uruchomieniu podstawowego procesu można rozwijać produkt jako usługę dla wielu lokali. Wtedy naprawdę potrzebne stają się:
1. Architektura wielolokalowa.
Jeden panel operatora, ale oddzielne dane, użytkownicy, menu i raporty każdego klienta.
2. Role i uprawnienia.
Kelner nie powinien zmieniać konfiguracji płatności, a franczyzobiorca z Krakowa nie powinien widzieć raportów lokalu z Gdańska.
3. Historia zmian.
Jeżeli ktoś zmienił cenę burgera z 39 na 3,90 zł o 18:47, właściciel musi móc sprawdzić kto i kiedy to zrobił.
4. Monitoring.
Błąd płatności albo niedziałający webhook powinien zostać wykryty automatycznie, zanim zadzwoni kierownik restauracji.
5. Kopie zapasowe i możliwość eksportu.
Menu i historia sprzedaży nie mogą istnieć wyłącznie w interfejsie dostawcy.
6. Dokumentacja integracji.
Jeżeli biznes ma rosnąć, kolejne POS-y powinno dać się dołączać przez stabilne API, a nie przez ręcznie napisany wyjątek w kodzie dla każdego nowego klienta.
Przy sprzedaży alkoholu potrzebny jest jeszcze jeden bezpiecznik. Cyfrowe zamówienie nie znosi obowiązku kontroli wieku. Produkt alkoholowy można oznaczyć jako 18+, natomiast jego wydanie powinno pozwalać obsłudze zweryfikować klienta. Pełna automatyzacja tego fragmentu procesu nie jest dobrym miejscem do szukania oszczędności.
FAQ – cyfrowe menu i zamawianie przy stoliku
Czy klient musi instalować aplikację?
Nie. Najprostsze rozwiązanie działa jako mobilna aplikacja webowa otwierana po zeskanowaniu kodu QR. Instalacja z App Store lub Google Play nie jest potrzebna.
Ile może kosztować taki system dla jednego lokalu?
Gotowe usługi działające w modelu SaaS kosztują obecnie mniej więcej od 100 do 500 zł miesięcznie za lokal, zależnie od zakresu funkcji. Dla nowej usługi sensownym punktem testowym jest około 149 zł za samo menu, 299 zł za zamawianie oraz około 499 zł za bardziej rozbudowany wariant z płatnościami i integracjami.
Czy kod QR może całkowicie zastąpić papierowe informacje o składzie dań?
Nie powinien. W Polsce obowiązkowe informacje o składnikach i alergenach muszą być dostępne klientowi bezpośrednio w lokalu. QR można wykorzystywać dodatkowo, ale bezpieczny model przewiduje również wydruk, katalog, lokalny tablet lub inny bezpośrednio dostępny nośnik.
Czy od początku trzeba integrować system z POS-em?
Nie. Pilotaż można przeprowadzić na osobnym tablecie. Integracja zaczyna mieć wysoki priorytet wtedy, gdy liczba zamówień sprawia, że personel regularnie przepisuje dane między systemami albo pojawiają się różnice w cenach i dostępności.
Jak szybko można uruchomić pierwszy lokal?
Przy gotowym produkcie, menu przekazanym w uporządkowanym pliku i bez integracji z POS realny pilotaż można skonfigurować w około 3–5 dni roboczych. Integracja z zewnętrznym POS-em może wydłużyć wdrożenie do 2–6 tygodni, zależnie od jakości API, procedur dostawcy i koniecznych testów.
Czy restauracja powinna płacić prowizję od każdego zamówienia?
Nie jest to konieczne. Przy zamówieniach do stolika łatwiejszy do sprzedaży jest stały abonament. Osobno pozostaje koszt operatora płatności. Restauratorzy znający wysokie prowizje marketplace’ów są szczególnie wyczuleni na kolejny procent pobierany od obrotu.
Co zrobić, jeżeli internet albo system przestanie działać w godzinach szczytu?
Restauracja musi mieć procedurę awaryjną: tradycyjne zamówienie u kelnera, możliwość ręcznego wprowadzenia sprzedaży i dostęp do aktualnego menu poza systemem QR. Usługa, której awaria uniemożliwia sprzedaż w całym lokalu, jest źle zaprojektowana.
Co sprawdzić jako pierwsze przed budową produktu?
Nie zaczynaj od aplikacji mobilnej, programu lojalnościowego ani integracji z dziesięcioma systemami POS. Najpierw uruchom jeden lokal i sprawdź trzy rzeczy: czy kod konkretnego stolika poprawnie identyfikuje zamówienie, czy opłacona transakcja zawsze trafia do obsługi dokładnie jeden raz oraz czy pracownik potrafi natychmiast wyłączyć niedostępne danie. Jeżeli którykolwiek z tych trzech procesów zawodzi, właśnie ten błąd trzeba usunąć przed dodaniem kolejnej funkcji.
Więcej informacji na: https://hd-biznes.com/blog
