Rezerwacje stolików dla restauracji: jak obsłużyć zmianę liczby gości i czasu wizyty

Zmiana rezerwacji dotyczy sali i gościa

Gość rezerwuje stolik dla czterech osób na wieczór. W dniu wizyty prosi o sześć miejsc i późniejszą godzinę. Pracownik restauracji widzi w kalendarzu wolny termin, ale nie wie jeszcze, czy stoliki można połączyć oraz kiedy zakończy się poprzednia rezerwacja. Potrzebne jest uzgodnienie, nie tylko poprawienie liczby w formularzu.

System rezerwacji dla restauracji powinien pokazać, jakie miejsce i czas zostały potwierdzone, kto prowadzi zmianę oraz co należy przekazać obsłudze sali. Może pomagać w planowaniu dostępności, lecz nie powinien obiecywać nowego terminu, zanim sprawdzi warunki przyjęcia grupy.

Opisany lokal jest fikcyjny. Restauracje mają różną liczbę stolików, czas obsługi i zasady przyjmowania gości. Warunki konkretnej rezerwacji należy uzgodnić z lokalem; nie zakładamy jednej polityki przedpłat, czasu wizyty ani anulowania.

Co oznacza dostępne miejsce

Zacznijcie od opisu sali. Stolik może mieć określoną liczbę miejsc, znajdować się wewnątrz albo na zewnątrz i być dostępny tylko w części dnia. Niektóre stoliki da się połączyć, inne nie powinny być łączone z powodu układu przestrzeni. Te reguły trzeba sprawdzić z osobami prowadzącymi salę, zamiast zakładać, że suma wolnych krzeseł zawsze tworzy miejsce dla grupy.

Ustalcie, czy system przydziela gościom konkretny stolik od razu, czy rejestruje liczbę osób i pozostawia obsłudze wybór miejsca. Oba sposoby wymagają kontroli dostępności, ale prowadzą do innych decyzji. Jeśli pracownik może zmienić stolik po przyjęciu rezerwacji, zespół powinien widzieć aktualny przydział oraz sposób obsługi wyjątków.

Przy planowaniu potrzebny jest także czas wizyty lub inna reguła określająca zajętość miejsca. Czas ten może być przybliżony i zależeć od rodzaju rezerwacji. Restauracja powinna ustalić, jak uwzględnia opóźnienie oraz przygotowanie stolika dla następnych gości. System nie powinien przedstawiać szacunku jako gwarancji, że poprzednia grupa skończy dokładnie o wskazanej godzinie.

O rozróżnieniu zasobu i rzeczywistego czasu zajętości piszemy również w artykule o rezerwacji zasobów firmy. Restauracja ma jednak własne potrzeby: liczba osób, układ sali oraz sposób przyjęcia grupy wpływają na to, czy propozycja terminu jest wykonalna.

Preferencja dotycząca miejsca też wymaga ostrożnego opisu. Prośbę o stolik blisko wejścia można zapisać jako życzenie do sprawdzenia przez obsługę, bez obiecywania konkretnego miejsca, jeśli lokal nie przypisuje stolików z wyprzedzeniem. Pracownik powinien widzieć tę informację w momencie planowania sali, a gość - wiedzieć, czy lokal potwierdził prośbę.

Od zapytania do potwierdzenia

Formularz może zebrać datę, godzinę, liczbę osób i sposób kontaktu. Przed dodaniem kolejnych pól ustalcie, kto korzysta z odpowiedzi oraz na jakim etapie jest ona potrzebna. Jeśli lokal pyta o szczególne potrzeby dotyczące miejsca, powinien zapewnić sposób wyjaśnienia ich z obsługą oraz odpowiednio ograniczyć dostęp do informacji.

Zapytanie może wymagać ręcznego sprawdzenia, zwłaszcza przy większej grupie lub nietypowym układzie sali. Osoba składająca prośbę powinna wiedzieć, czy system potwierdził rezerwację, czy dopiero przekazał ją do oceny. „Dziękujemy za wiadomość” i „stolik jest zarezerwowany” opisują różne zdarzenia.

Przy potwierdzeniu pokażcie aktualną datę, godzinę, liczbę gości oraz sposób kontaktu z lokalem. Jeśli planowana wizyta ma dodatkowe warunki, powinny być one uzgodnione i przedstawione w sposób zrozumiały. Nie dopisujcie automatycznie warunków, których restauracja nie stosuje.

Warto zaplanować sytuację, w której odpowiedź nie dotarła do przeglądarki. Gość może nie wiedzieć, czy rezerwacja została przyjęta. System powinien umożliwić sprawdzenie stanu albo kontakt z obsługą, a ponowienie nie powinno bez kontroli tworzyć dwóch niezależnych rezerwacji. O różnicy między przyjęciem wiadomości a wykonaniem zadania piszemy przy API i webhookach.

Więcej gości nie zawsze mieści się przy tym samym stole

Gdy osoba rezerwująca zmienia liczbę uczestników, sprawdźcie nie tylko wolne miejsca, lecz także to, czy grupa może siedzieć razem w uzgodnionym czasie. Dwa wolne stoliki po przeciwnych stronach sali nie muszą odpowiadać oczekiwaniu gościa. Jeśli decyzja wymaga rozmowy z obsługą, propozycja powinna pozostać w stanie oczekiwania.

Ustalcie, co dzieje się z pierwotną rezerwacją podczas sprawdzania zmiany. Gość powinien wiedzieć, czy dotychczasowy termin i liczba miejsc pozostają potwierdzone, dopóki restauracja nie zaakceptuje nowej propozycji. Odrzucenie zmiany nie powinno niepostrzeżenie usunąć wcześniej uzgodnionej wizyty.

Przy zmianie godziny sprawdźcie cały przedział potrzebny dla nowej wizyty oraz zależności z innymi rezerwacjami. Jeśli lokal przewiduje łączenie stolików lub zmianę układu sali, reguły muszą odpowiadać faktycznym możliwościom obsługi. Osoba prowadząca rezerwację powinna wiedzieć, kiedy potrzebna jest decyzja kierownika sali.

Gdy propozycja nie jest możliwa, pokażcie sposób dalszego kontaktu albo inne sprawdzone możliwości. System nie powinien proponować terminu wyłącznie dlatego, że pasuje do prostego wyliczenia, jeśli wymaga on warunków, których nie potwierdzono. Gość potrzebuje prawdziwej odpowiedzi, nawet jeśli brzmi ona: „sprawdzimy i wrócimy z informacją”.

Połączenie dwóch systemów warto sprawdzić także wtedy, gdy jedno z nich chwilowo nie odpowiada. Rezerwacja przyjęta w lokalu musi mieć czytelny status, a obsługa powinna wiedzieć, czy aktualizacja kalendarza się powiodła. Dopóki nie ma potwierdzenia, ekran nie powinien sugerować, że dane zostały bezpiecznie zapisane w obu miejscach.

Jednoczesne rezerwacje i inne kanały

Dwie osoby mogą zobaczyć wolne miejsce niemal w tym samym czasie. Dostępność trzeba sprawdzić ponownie podczas zapisu oraz rozstrzygnąć konkurujące próby w systemie. Samo odświeżenie widoku nie gwarantuje, że między odczytem a zapisem nikt inny nie otrzymał tego samego miejsca.

Restauracja może przyjmować zgłoszenia telefonicznie, na miejscu i przez zewnętrzne platformy. Ustalcie, gdzie powstaje obowiązujący zapis oraz kto odpowiada za wprowadzenie zmiany z każdego kanału. Jeśli integracja jest opóźniona albo niedostępna, osoba prowadząca salę powinna widzieć ograniczenie i znać sposób wyjaśnienia potencjalnego konfliktu.

Google Calendar API udostępnia operacje odczytu informacji o zajętości kalendarzy oraz aktualizacji wydarzeń. To możliwości konkretnej usługi i odpowiednio uprawnionego konta. Sam odczyt wolnego terminu nie rozwiązuje reguł dotyczących łączenia stolików, liczby gości ani równoczesnych prób rezerwacji. Zakres integracji trzeba sprawdzić dla używanej konfiguracji.

Przed połączeniem narzędzi ustalcie, co ma się stać po anulowaniu lub przesunięciu wizyty oraz który system jest źródłem aktualnego stanu. O odpowiedzialności za informacje między aplikacjami przeczytacie w tekście o źródle danych w integracji.

Anulowanie, spóźnienie i kontakt z lokalem

Gość powinien wiedzieć, jak zgłosić zmianę lub anulowanie oraz czy otrzymał potwierdzenie jej przyjęcia. Jeżeli lokal korzysta z kilku kanałów, zadbajcie o przekazanie informacji obsłudze sali. Wiadomość odczytana w jednym miejscu nie aktualizuje automatycznie innych narzędzi, chyba że zostało to zaprojektowane i sprawdzone.

Przy spóźnieniu potrzebna jest decyzja zgodna z zasadami restauracji oraz aktualną sytuacją na sali. System może wskazać rezerwację i kontakt do osoby prowadzącej, ale nie powinien obiecywać zachowania miejsca przez nieuzgodniony czas. Jeśli lokal proponuje inny termin, gość powinien móc potwierdzić lub odrzucić tę propozycję.

Zaplanujcie również brak odpowiedzi po stronie lokalu. Gdy system przesyła prośbę do sprawdzenia, ktoś powinien widzieć kolejkę spraw oczekujących i wiedzieć, kiedy należy wrócić do gościa. O odpowiedzialności za następny krok piszemy w artykule o monitorowaniu procesów.

Jeśli rezerwacja obejmuje większą grupę, zadbajcie o czytelne przekazanie informacji zmianie obsługi. Osoba przyjmująca gości powinna widzieć potwierdzoną liczbę osób, godzinę i uzgodnione uwagi potrzebne do przygotowania miejsca. Szczegóły, których nie trzeba znać przy pracy na sali, nie powinny być automatycznie udostępniane całemu zespołowi.

Przy zgłoszeniu telefonicznym pracownik potrzebuje szybkiego sposobu odnalezienia wizyty, ale pełna historia kontaktów nie musi być dostępna każdej osobie w lokalu. Zakres widocznych danych i czas ich przechowywania należy ustalić z właścicielem procesu. Dzięki temu informacja o rezerwacji pomaga obsłużyć gościa, zamiast zostawać w systemie bez określonego celu.

Co widzi obsługa w dniu wizyty

Widok sali może pokazywać aktualne rezerwacje, czas ich przyjęcia oraz sprawy wymagające decyzji. Ustalcie, kto może zmienić przydział stolika i jak informuje pozostałych pracowników. Jeżeli stolik został połączony z innym, plan powinien odzwierciedlać rzeczywistą decyzję, a nie tylko pierwotny układ.

Gdy grupa przyjdzie w innej liczbie niż zgłoszona, potrzebna jest ocena dostępności przez obsługę. System może pomóc znaleźć możliwe miejsce, lecz ostateczny sposób przyjęcia zależy od lokalu i sytuacji. Nie powinien ukrywać konfliktu z kolejną wizytą ani automatycznie przesuwać innych gości bez decyzji pracownika.

Ustalcie też, co oznacza zakończenie wizyty w systemie. Czy miejsce zwalnia osoba prowadząca salę, czy wynika to z innego uzgodnionego zdarzenia? Rzeczywiste potwierdzenie jest ważne przy kolejnych rezerwacjach. Upływ szacowanego czasu nie zawsze oznacza, że stolik jest gotowy do przyjęcia kolejnej grupy.

Raport może pokazać liczbę zgłoszeń, potwierdzonych wizyt i anulacji, ale każda wartość potrzebuje definicji. Przed porównaniem okresów ustalcie, co jest liczone oraz jak traktowane są zmiany liczby gości. O przygotowaniu takich wskaźników piszemy w artykule o definicjach dashboardu.

Jeśli w ciągu dnia zmienia się układ sali, obsługa potrzebuje prostego sposobu aktualizacji dostępności. Historia zmiany powinna pozwolić ustalić, co zobaczyła osoba przyjmująca kolejne zgłoszenie.

Próba przed przyjęciem prawdziwych rezerwacji

Przygotujcie fikcyjny plan sali i kilka stolików. Przejdźcie zgłoszenie czterech osób, prośbę o sześć miejsc, zmianę godziny i odmowę nowej propozycji. Sprawdźcie, czy pierwotna rezerwacja pozostaje w uzgodnionym stanie oraz czy pracownik sali widzi właściwą liczbę gości.

Dodajcie dwie równoczesne próby, anulowanie przyjęte telefonicznie i brak odpowiedzi z zewnętrznego kalendarza. Dla każdego scenariusza zapiszcie oczekiwany wynik i osobę, która go potwierdzi. Jeśli kanał zewnętrzny jest symulowany, rzeczywistą integrację trzeba sprawdzić osobno w odpowiedniej konfiguracji.

Poproście pracownika restauracji i osobę składającą rezerwację o wykonanie zadania bez podpowiedzi. Sprawdźcie, czy obie rozumieją różnicę między zapytaniem a potwierdzeniem. Takie próby opisujemy w artykule o testowaniu prototypu z pracownikami, a oczekiwane wyniki w kryteriach odbioru aplikacji.

Jeżeli planujesz system rezerwacji restauracji, poznaj zakres aplikacji webowych i mobilnych i skontaktuj się z Archifutura. W briefie opisz układ sali, kanały przyjmowania zgłoszeń oraz sytuacje, w których obsługa musi potwierdzić zmianę. Do pierwszej rozmowy wystarczy fikcyjny przykład.

Warto też przejść próbę od strony osoby, która nie korzysta z komputera przez całą zmianę. Czy na telefonie da się rozpoznać godzinę i liczbę osób? Czy można poprawić literówkę bez anulowania całej wizyty? Czy po odświeżeniu widać zapisany stan? Takie pytania pozwalają wychwycić kłopoty, których nie zdradzi sam wygląd formularza.