Chatbot WhatsApp dla restauracji: koniec 15-30% prowizji (i gdzie ten model się nie opłaca)

Większość restauratorów, z którymi rozmawiamy, zaczyna od złej diagnozy. Słyszą „chatbot na WhatsApp” i wyobrażają sobie okienko czatu, które odpowiada na pytania o godziny otwarcia i alergeny. To nie jest problem, który kosztuje ich 20% marży. Problemem jest to, że klient, który chce zamówić pierogi w sobotni wieczór, otwiera Pyszne.pl, bo to najkrótsza ścieżka od „chcę jeść” do „zapłacone”. Jeśli chcesz zabrać mu ten nawyk, musisz zbudować ścieżkę równie krótką, tylko bez pośrednika, który zabiera od 15 do 30% wartości zamówienia.

Nie zaczynałbym więc od pytania „jaki chatbot kupić”, tylko od pytania „czy u mnie ten model w ogóle się opłaca”. Bo w połowie przypadków, które widzieliśmy, odpowiedź brzmi: jeszcze nie, albo wcale.

Prowizje platform: skąd się bierze te 15–30%

Pyszne.pl, Glovo i Uber Eats różnią się szczegółami, ale mechanizm jest wspólny: prowizja liczona od wartości zamówienia, w praktyce zwykle w przedziale 15–30%, zależnie od tego, czy restauracja korzysta z własnej dostawy (niższy pakiet) czy z dostawy kurierskiej platformy (wyższy pakiet, bo platforma bierze na siebie flotę i logistykę). Do tego dochodzi czasem opłata za obsługę płatności i koszt widoczności w wyszukiwaniu, jeśli restauracja chce być wyżej na liście.

Dla lokalu ze średnią marżą gastronomiczną rzędu 60–65% na produkcie to różnica, która potrafi zdecydować, czy dzień dostawowy jest rentowny, czy tylko generuje obrót. Restauracja, która sprzedaje przez platformy zamówienia za 15 tysięcy złotych miesięcznie, przy prowizji 25% oddaje im 3750 zł. Rocznie to 45 tysięcy, czyli pensja dodatkowego kucharza albo budżet na remont kuchni.

Platformy dają za to coś realnego: ruch, który sami nie wygenerowaliby, i infrastrukturę płatności i logistyki gotową od pierwszego dnia. Problem zaczyna się, gdy restauracja ma już stałą bazę klientów, którzy i tak wpisaliby w telefon jej numer, gdyby tylko było to równie proste jak kliknięcie w aplikację.

Dlaczego sam chatbot „24/7” nie rozwiązuje problemu

Tu zaczyna się część, w której większość wdrożeń, jakie widzieliśmy u innych, się wywraca. Firma kupuje lub stawia bota konwersacyjnego, który ładnie odpowiada na pytania, pokazuje menu, nawet przyjmuje coś, co wygląda jak zamówienie. I na tym się kończy. Zamówienie trafia jako wiadomość tekstowa, którą ktoś na zmianie musi przeczytać, przepisać do systemu kasowego, policzyć ręcznie i dopiero wtedy przekazać do kuchni. W godzinach szczytu to dokładnie ten sam chaos, który miał zniknąć, tylko przeniesiony z telefonu na czat.

Chatbot, który nie jest podłączony do systemu POS i do płatności, to nie automatyzacja zamówień. To automatyzacja pierwszego kontaktu, a resztę pracy i tak robi człowiek. Jeśli restauracja ma 20 zamówień dziennie przez WhatsApp, a każde wymaga ręcznego przepisania do kasy, to realnie nic nie zyskała, oprócz tego, że ma teraz dwa kanały do monitorowania zamiast jednego.

Jak wygląda to w praktyce: workflow na n8n

Konkretny przykład, oparty na schemacie, który budujemy w podobnych projektach: restauracja z dostawą własną w promieniu kilku kilometrów, menu na 25–40 pozycji, chce przyjmować zamówienia z WhatsApp Business i Messengera bez udziału obsługi przy pierwszym kontakcie.

Krok 1: wejście i wybór

Klient pisze do numeru WhatsApp Business restauracji (ten sam numer może odbierać wiadomości z reklamy w Meta Ads albo z kodu QR na stoliku). Bot, zbudowany jako przepływ w n8n połączony z API WhatsApp Business, prezentuje menu jako listę interaktywną albo link do krótkiej strony z koszykiem, nie jako ścianę tekstu. To jest moment, w którym najwięcej wdrożeń traci klienta: jeśli menu trzeba przewijać przez 15 wiadomości, ludzie wracają do aplikacji.

Krok 2: zamówienie trafia do kuchni, nie do skrzynki

Po potwierdzeniu koszyka n8n tworzy zamówienie przez API systemu kasowego, na przykład Gastro POS albo Dotykačka, zamiast wysyłać je jako powiadomienie do pracownika. Zamówienie pojawia się na ekranie kuchennym tak samo, jak zamówienie wpisane przez kelnera. To jest clou całego rozwiązania: bez tej integracji wszystko, co opisałem w kroku 1, to tylko ładniejszy formularz kontaktowy.

Integracja z API POS gastronomicznego to w naszych realizacjach praca na 1–3 tygodnie, zależnie od tego, czy system ma dokumentację API dla partnerów (jak Dotykačka), czy integrację trzeba negocjować indywidualnie z dostawcą (częstsze przy starszych wdrożeniach Gastro POS). Koszt jednorazowy mieści się zwykle w przedziale kilku do kilkunastu tysięcy złotych, w zależności od tego, czy integrujemy tylko tworzenie zamówień, czy też dwustronną synchronizację menu i stanów magazynowych.

Krok 3: płatność bez przepisywania numeru karty na czacie

Płatność idzie przez link do bramki płatniczej (Blik, karta) generowany automatycznie po złożeniu zamówienia, albo przez płatność przy odbiorze, jeśli restauracja woli nie ryzykować dodatkowej prowizji bramki. n8n odkłada status płatności i dopiero po jej potwierdzeniu zmienia status zamówienia w POS na „do realizacji”. Bez tego ryzykujemy sytuację, w której kuchnia gotuje zamówienie, za które nikt nie zapłacił.

Krok 4: aktualizacje statusu i powrót klienta

Klient dostaje wiadomość, gdy zamówienie jest w realizacji i gdy kurier (własny albo zewnętrzny) wyjeżdża. To są wiadomości typu „utility”, nie marketingowe, co ma znaczenie dla kosztów, o czym za chwilę. Dobrze zbudowany bot zapisuje też historię zamówień klienta, żeby przy kolejnym kontakcie zapytać „zamówienie jak ostatnio?” zamiast zaczynać całą rozmowę od zera. To jest przewaga, której żadna platforma dostawcza nigdy nie odda restauracji, bo dane klienta zostają u niej, a nie u pośrednika.

Jeśli restauracja ma już system zamówień online, ale chce domknąć całość wokół obsługi i automatyzacji rozmów z klientem, warto zobaczyć szerzej, jak wygląda automatyzacja obsługi klienta w praktyce, bo kanał WhatsApp rzadko działa w oderwaniu od reszty komunikacji z klientami.

Ile to kosztuje: WhatsApp Business API w praktyce

Tu jest szczegół, który często ucieka w rozmowach o „darmowym kanale”. WhatsApp Business API nie jest darmowy, choć struktura kosztów jest korzystna dla modelu zamówieniowego, jeśli rozumie się różnicę między typami wiadomości.

Wiadomości w ramach okna obsługi klienta, czyli odpowiedzi w ciągu 24 godzin od wiadomości zainicjowanej przez klienta, są bezpłatne. To pokrywa całą ścieżkę zamówienia opisaną wyżej: klient pisze pierwszy, więc odpowiedzi bota, potwierdzenie, status realizacji, to wszystko mieści się w darmowym oknie serwisowym. Płaci się za wiadomości inicjowane przez firmę poza tym oknem, czyli szablony typu utility (przypomnienie o zamówieniu, powiadomienie po dłuższej przerwie) i szablony marketingowe (promocje, oferty). Od 2025 roku Meta rozlicza te wiadomości per wysłaną wiadomość, a nie per „rozmowę” jak wcześniej, z wyższą stawką dla wiadomości marketingowych niż dla wiadomości usługowych. Koszt jednostkowy jest niski, rzędu groszy za wiadomość, ale przy restauracji wysyłającej tysiące powiadomień promocyjnych miesięcznie trzeba to już wliczyć do budżetu, zamiast traktować kanał jak w pełni bezkosztowy.

W praktyce oznacza to, że sam model zamówieniowy (klient pisze, bot odpowiada, zamówienie realizowane) kosztuje w warstwie komunikacji bardzo mało, bliżej zera niż prowizji platformy. Koszt rośnie, gdy restauracja zaczyna używać tego samego kanału do marketingu, czyli wysyłania ofert do bazy klientów. To już inny budżet i inna decyzja, bliższa automatyzacji marketingu niż samej obsłudze zamówień, i warto je rozdzielać w kalkulacji, żeby nie liczyć kosztu kampanii promocyjnej jako kosztu „obsługi zamówień”.

Gdzie ten model się nie opłaca

Tu muszę być szczery, bo to część, którą sprzedawcy automatyzacji zwykle przemilczają. Chatbot zamówieniowy podłączony do POS i płatności to projekt, nie wtyczka za 200 zł miesięcznie. Ma sens tylko wtedy, gdy wolumen zamówień i struktura dostawy na to pozwalają.

Jeśli restauracja ma 5 zamówień dziennie z dostawy, koszt integracji (kilka do kilkunastu tysięcy złotych jednorazowo plus bieżące opłaty za API i hosting automatyzacji) się po prostu nie zwróci w rozsądnym czasie. W takiej sytuacji prowizja 20–25% od niewielkiego obrotu to mniejszy koszt niż utrzymanie własnej infrastruktury zamówieniowej. To nie jest popularna opinia w branży, która sprzedaje automatyzacje, ale jest zgodna z tym, co liczymy w arkuszu kalkulacyjnym przy każdym takim projekcie.

Podobnie, jeśli restauracja nie ma własnej dostawy i nie planuje jej budować, chatbot na WhatsApp rozwiąże może komunikację z klientem, ale zamówienia i tak trzeba będzie kierować przez jakiegoś przewoźnika, co wraca do punktu wyjścia: albo platforma ze swoją flotą, albo lokalna firma kurierska, która też bierze swoją marżę.

Jak to wdrożyć: realne kroki, nie lista życzeń

Zakładając, że wolumen i logistyka się zgadzają, kolejność, którą stosujemy, jest prawie zawsze taka sama. Najpierw audyt systemu kasowego: czy ma otwarte API, jaką dokumentację, czy dostawca systemu w ogóle odpowiada na zapytania integracyjne (niektórzy dostawcy POS w Polsce traktują to jako usługę premium i każą czekać tygodniami na dostęp testowy). Potem projekt przepływu zamówienia w n8n, zwykle najpierw na środowisku testowym z fałszywymi zamówieniami, dopiero potem podłączenie realnego numeru WhatsApp Business i realnej bramki płatności. Na końcu, nie na początku, dochodzi warstwa „ładnego bota”, czyli ton rozmowy, obsługa pytań o alergeny, rekomendacje dań.

Błąd, który widzimy najczęściej, to odwrócenie tej kolejności: firma najpierw inwestuje w ładny interfejs konwersacyjny, a dopiero później odkrywa, że integracja z kasą jest trudniejsza niż myślała, albo że dostawca POS nie udostępnia API bez dodatkowej umowy. Wtedy cały budżet czasu idzie na rzeczy widoczne, a fundament, czyli połączenie z kuchnią i płatnością, zostaje na później, czyli nigdy.

Decyzje przy wyjątkach, czyli na przykład reklamacja, błąd w zamówieniu, klient pytający o coś spoza menu, zostają po naszej stronie zawsze przy człowieku. Automat prowadzi 80–90% standardowych zamówień od początku do końca, ale moment, w którym rozmowa wychodzi poza schemat, powinien przełączać na obsługę, nie próbować zgadywać odpowiedzi botem. To różnica między botem, który buduje zaufanie, i botem, który je psuje przy pierwszej nietypowej sytuacji.