System dla punktu gastronomicznego: planowanie odbioru zamówień zbiorowych

Biuro zamawia wspólny obiad dla zespołu. Jedna osoba zbiera wybory w wiadomościach, kolejna przekazuje liczbę posiłków do lokalu, a w dniu odbioru ktoś pyta, która porcja należy do którego pracownika. Wystarczy zmiana jednego zamówienia po wysłaniu listy, żeby kuchnia i osoba odbierająca widziały różne wersje.

System do zamówień zbiorowych może połączyć wybory uczestników, termin zamknięcia listy i informacje potrzebne do przygotowania oraz wydania posiłków. Musi jednak pokazywać, co już potwierdzono, a co jest tylko propozycją. Ważna jest też aktualność informacji o składnikach oraz jasna droga wyjaśnienia niepewności przed złożeniem zamówienia.

Poniższy lokal i zamówienie są fikcyjne. Zasady przygotowania żywności, informacje dla konsumentów oraz sposób obsługi alergii trzeba ustalić dla konkretnej działalności i obowiązujących wymagań. Aplikacja może przekazać informacje od lokalu, ale nie powinna zgadywać składu ani zapewniać, że posiłek jest odpowiedni dla danej osoby.

Kto składa zamówienie, a kto wybiera posiłek

Zacznijcie od podziału ról. Organizator po stronie firmy może tworzyć zamówienie grupowe i ustalać termin, do którego zbierane są wybory. Poszczególne osoby wybierają posiłki dla siebie, a lokal potwierdza, co może przygotować i kiedy. W innym procesie jedna osoba zbiera wszystkie pozycje. System powinien wspierać uzgodniony sposób pracy, zamiast narzucać jeden model wszystkim grupom.

W fikcyjnym przykładzie organizator planuje odbiór w południe. Pracownicy wybierają pozycje z menu, a lokal otrzymuje zestawienie po zatwierdzeniu. Osoba zamawiająca powinna widzieć, czy lista nadal przyjmuje zmiany oraz kto może wysłać ją do lokalu. Samo zapisanie pojedynczego wyboru nie oznacza jeszcze, że kuchnia otrzymała całe zamówienie.

Ustalcie, jakie informacje są rzeczywiście potrzebne do wydania porcji. W zależności od procesu może wystarczyć oznaczenie przypisane do uczestnika lub odbioru. Lokal nie musi automatycznie otrzymywać wszystkich danych o pracownikach firmy. Zakres informacji, dostęp do listy i czas przechowywania należy uzgodnić z osobami odpowiedzialnymi za proces.

Jeśli kilka zespołów zamawia w tym samym terminie, system powinien rozróżniać ich listy oraz osoby uprawnione do zmian. O przydzielaniu dostępu według rzeczywistych obowiązków piszemy w artykule o rolach i uprawnieniach w aplikacji.

Menu musi mieć właściciela i aktualny opis

Lokal powinien wskazać, kto publikuje menu, zmienia dostępność oraz odpowiada na pytania o składniki. Dane w aplikacji muszą odpowiadać rzeczywistej ofercie. Jeśli po rozpoczęciu zbierania zamówień pozycja przestaje być dostępna, organizator i zainteresowane osoby potrzebują informacji oraz możliwości podjęcia kolejnej decyzji.

Nie należy automatycznie podmieniać dania na inne tylko dlatego, że ma podobną nazwę lub cenę. Osoba zamawiająca powinna wiedzieć, co się zmieniło, i potwierdzić wybór zgodnie z uzgodnionym procesem. Zmiana może wpływać na skład, sposób wydania lub warunki zamówienia.

W Polsce IJHARS opisuje wymagania dotyczące przekazywania informacji o żywności nieopakowanej. Zakres obowiązków i sposób ich spełnienia trzeba sprawdzić dla konkretnej działalności. System powinien ułatwiać prezentację informacji dostarczonych i potwierdzonych przez lokal, ale nie zastępuje oceny zgodności ani rozmowy z osobą odpowiedzialną za przygotowanie posiłków.

Jeżeli skład lub opis zmieni się po złożeniu wyboru, należy uzgodnić, jak poinformować osoby, których dotyczy zmiana. Przy pytaniu o alergeny pracownik nie powinien odpowiadać na podstawie niepotwierdzonego opisu ani wyniku wygenerowanego przez model. Potrzebna jest droga do aktualnej informacji od właściwej osoby w lokalu.

Przed publikacją nowego menu warto przejść cały widok z osobą odpowiedzialną po stronie lokalu. Powinna móc sprawdzić nazwę, opis i okres dostępności bez porównywania kilku nieaktualnych plików. Jeśli zmiana wymaga dodatkowej weryfikacji, stan oczekiwania musi być widoczny osobie publikującej ofertę.

Termin zamknięcia to decyzja o przekazaniu listy

Ustalcie, do kiedy uczestnicy mogą zmieniać wybory oraz kto zatwierdza gotową listę. Warto pokazać różnicę między otwartym zbiorem propozycji, zamówieniem wysłanym do lokalu i potwierdzeniem jego przyjęcia. Kolorowy znacznik bez opisu nie odpowie na pytanie, czy kuchnia zna już aktualną liczbę porcji.

Przed zamknięciem organizator może potrzebować informacji o osobach, które nie wybrały posiłku, ale system nie powinien sam przypisywać im przypadkowej pozycji. Jeśli brak odpowiedzi oznacza brak zamówienia, trzeba to jasno wyjaśnić. Inna reguła wymaga uzgodnienia z firmą oraz lokalem.

Po wysłaniu listy każda zmiana potrzebuje ustalonej ścieżki. Lokal może jeszcze potwierdzić korektę, zaproponować inną opcję albo poinformować, że jest już za późno na zmianę zgodnie z przyjętymi warunkami. Aplikacja powinna pokazywać stan prośby, a nie automatycznie przedstawiać ją jako przyjętą.

Jeżeli termin zależy od godziny lokalnej punktu odbioru, pokażcie ją w sposób zrozumiały dla uczestników. Przy zespołach pracujących w różnych lokalizacjach trzeba uzgodnić znaczenie godziny oraz informację o strefie. O podobnych decyzjach piszemy w artykule o aplikacji dla międzynarodowego zespołu.

Przy cyklicznych zamówieniach sprawdźcie również, czy wybór dotyczy tylko jednego dnia. Uczestnik nie powinien zakładać, że poprawił wszystkie przyszłe zamówienia, jeśli system przyjął zmianę wyłącznie dla jednego terminu. Interfejs powinien wskazać zakres przed zapisaniem.

Kuchnia potrzebuje zestawienia, które da się sprawdzić

Widok dla lokalu może grupować liczbę porcji według pozycji i wskazywać potwierdzone uwagi potrzebne do realizacji. Powinien też pozwalać przejść do szczegółu, gdy trzeba wyjaśnić zamówienie. Liczba widoczna w zestawieniu musi wynikać z ustalonych stanów: inaczej należy traktować zapisany wybór, a inaczej prośbę o zmianę oczekującą na decyzję.

Jeżeli jedna osoba zmieni wybór po przygotowaniu zestawienia, lokal powinien wiedzieć, czy widzi poprzednią wersję, czy zatwierdzoną korektę. Warto zapisać godzinę oraz osobę odpowiedzialną za przyjęcie zmiany. W projekcie integracji trzeba ustalić, gdzie znajduje się aktualny zapis i jak pojawia się w systemie lokalu. O takich decyzjach piszemy w artykule o źródłach danych w integracji.

Gdy zamówienie trafia do narzędzia kuchni automatycznie, wysłanie wiadomości nie jest równoznaczne z potwierdzeniem realizacji. Jeśli odpowiedź nie nadejdzie, organizator powinien wiedzieć, czy ma sprawdzić stan w lokalu albo skontaktować się innym kanałem. Mechanizmy ponawiania zależą od konkretnej usługi i trzeba je przetestować.

W integracjach API i webhookach opisujemy różnicę między przyjęciem komunikatu a wykonaniem kolejnego zadania. Przy zamówieniu zbiorowym podwójne utworzenie tej samej listy może spowodować niejasność po obu stronach, dlatego identyfikator sprawy i czytelny status są praktyczne.

Jeśli lokal przygotowuje zamówienia dla kilku punktów odbioru, potrzebuje również uzgodnionego planu produkcji i przekazania porcji. Ten etap opisujemy w artykule o planowaniu przygotowania między kuchnią a lokalami.

Wydanie porcji wymaga uzgodnionego oznaczenia

Przed odbiorem ustalcie, kto odbiera zamówienie i jak rozpoznaje poszczególne porcje. Oznaczenie może odwoływać się do pozycji na liście lub innego identyfikatora uzgodnionego z grupą. Powinno być czytelne dla osoby wydającej i odbierającej, a jednocześnie nie ujawniać więcej danych niż potrzeba.

Jeśli lokal pakuje kilka pozycji w jednym zestawie, warto sprawdzić, jak osoba odbierająca porówna je z zamówieniem. Brak jednej porcji lub nieczytelne oznaczenie powinny prowadzić do kontaktu z właściwą osobą, a nie do przypadkowej zamiany. System może zachować zgłoszenie, lecz faktyczną zawartość trzeba sprawdzić w odpowiedni dla procesu sposób.

Przy niepewności dotyczącej składu nie należy zakładać, że podobnie wyglądające danie ma te same składniki. Odpowiedź powinna pochodzić od lokalu i jego aktualnych informacji. Aplikacja może wskazać kanał kontaktu oraz zapisać pytanie, ale nie powinna prezentować niepotwierdzonej odpowiedzi jako gwarancji bezpieczeństwa.

Jeżeli zamówienie odbiera jedna osoba dla całej grupy, ustalcie, jakie potwierdzenie jest potrzebne i co zrobić z rozbieżnością. Przyjęcie paczki przez organizatora nie oznacza automatycznie, że każda osoba sprawdziła swoją porcję. Kolejne etapy warto opisać zgodnie z rzeczywistym sposobem wydania.

Uzgodnij płatność i odpowiedzialność za zmianę

Zamówienie grupowe może być opłacane przez firmę, uczestników albo według innych zasad przyjętych przez strony. Przed projektowaniem płatności ustalcie, kto otrzymuje podsumowanie, kiedy zna końcową kwotę i jak przekazywana jest informacja o zmianie liczby porcji. Nie należy dopisywać warunków płatności, których lokal i klient nie uzgodnili.

Jeśli płatność obsługuje zewnętrzna usługa, status widoczny w aplikacji powinien odpowiadać temu, co rzeczywiście zostało potwierdzone. Rozpoczęcie płatności nie jest tym samym co jej zakończenie. W razie braku odpowiedzi potrzebna jest droga sprawdzenia wcześniejszej operacji, zanim użytkownik podejmie kolejną próbę.

Po korekcie listy ustalcie, kto potwierdza nowy zakres oraz czy zmiana wpływa na rozliczenie. Jeżeli system nie może sam ustalić skutku, powinien przekazać sprawę do osoby odpowiedzialnej. Klient i lokal potrzebują zgodnych informacji o tym, co zostało zamówione i jakie pytanie nadal pozostaje otwarte.

Zastępstwo i kontakt w dniu odbioru

Organizator zamówienia może być nieobecny, a lokal nadal potrzebować odpowiedzi na pytanie o godzinę odbioru. Ustalcie, czy można wskazać zastępcę oraz jaki zakres informacji jest mu potrzebny. Zastępstwo nie powinno automatycznie oznaczać dostępu do wszystkich danych innych uczestników, jeśli wystarczy lista porcji i kontakt do lokalu.

Gdy odbiór się opóźnia, obie strony potrzebują uzgodnionego kanału kontaktu. Aplikacja może pokazać aktualny numer lub zadanie do wykonania, ale nie powinna obiecywać, że zmiana godziny została zaakceptowana, dopóki lokal jej nie potwierdzi. Pracownik odpowiedzialny za wydanie powinien widzieć ostatnią potwierdzoną informację.

Po zakończeniu zamówienia warto umożliwić zgłoszenie rozbieżności bez przesyłania danych wszystkich uczestników. Organizator może wskazać pozycję i opisać problem, a lokal wyjaśnić stan sprawy. Ustalcie, kto ma odpowiedzieć oraz jak odróżnić nowe pytanie od sprawy, która została już rozwiązana.

Na podstawie powtarzających się pytań można sprawdzić, czy menu i instrukcja odbioru są zrozumiałe. Jeśli osoby często nie wiedzą, kto może zmienić wybór, warto poprawić opis procesu. Nie trzeba od razu tworzyć kolejnego powiadomienia, które powtórzy tę samą niejasną informację.

Sprawdź zmianę i odbiór przed uruchomieniem

Przygotujcie fikcyjne menu i grupę kilku osób. Sprawdźcie wybór, brak odpowiedzi jednej osoby, zamknięcie listy oraz zmianę pozycji po przekazaniu do lokalu. Następnie przejdźcie potwierdzenie, przygotowanie zestawienia i odbiór. Przed próbą zapiszcie, jaki stan powinien widzieć uczestnik, organizator i lokal.

Dodajcie niedostępny produkt, pytanie o skład oraz brak potwierdzenia z systemu lokalu. Zespół powinien wiedzieć, kto udziela odpowiedzi i jak oznaczyć sprawę wymagającą wyjaśnienia. O odpowiedzialności za problem techniczny piszemy w tekście o monitorowaniu automatyzacji.

Poproście osoby z lokalu i organizatora zamówienia o przetestowanie ekranów bez podpowiadania kolejnych kliknięć. W artykule o testowaniu prototypu opisujemy, jak obserwować rzeczywiste zadanie. Wyniki i ograniczenia próby warto zapisać w kryteriach odbioru aplikacji.

Jeśli chcesz usprawnić zamówienia dla grup, opisz w briefie drogę od wyboru posiłku do odbioru oraz sposób kontaktu między firmą i lokalem. Możemy omówić aplikację webową lub mobilną i zakres pierwszego etapu. Napisz do Archifutura, używając fikcyjnych danych zamiast informacji uczestników.