Wstęp
Dobra aplikacja do obsługi pokoju hotelowego oferuje więcej niż tylko wyświetlanie menu i pobieranie płatności. Prawdziwa praca zaczyna się w momencie, gdy gość kliknie “Złóż zamówienie”.
Aplikacja musi odpowiedzieć na kilka konkretnych pytań: Czy hotel faktycznie otrzymał zamówienie? Czy kuchnia je przyjęła? Kiedy rozpoczyna się przygotowywanie i jak długo trwa oczekiwanie? Czy zamówienie jest w drodze? Co się stanie, jeśli produkt będzie niedostępny? Czy gość może anulować rezerwację i co stanie się z jego pieniędzmi, jeśli to zrobi?
Pomiń te elementy, a nawet technicznie działające zamówienie wyda się zawodne. Dla operatora sytuacja jest jeszcze gorsza: jedno zamówienie trafia teraz do aplikacji dla gości, personelu kuchennego, dostawcy usług płatniczych, recepcji, dostawców, powiadomień, a często także do systemu PMS. Dlatego cykl życia zamówienia jest jednym z czynników decydujących o powodzeniu projektu rozwoju aplikacji hotelowej.
Dlaczego cykl życia zamówienia w ramach obsługi pokoju jest ważny
Załóżmy, że gość zamawia 45 euro kolację z pokoju. Płatność jest realizowana, ale aplikacja po prostu tam jest “Zamówienie otrzymane” przez 25 minut. Kuchnia już zaczęła gotować. Gość nie ma o tym pojęcia.
Więc dzwonią do recepcji. Albo składają zamówienie ponownie, na wszelki wypadek. Albo stwierdzają, że coś się zepsuło i denerwują się, zanim jeszcze jedzenie wyjedzie z kuchni. Nikt tu nie zrobił nic złego, technicznie rzecz biorąc. I tak doświadczenie gościa jest już zrujnowane.
To właśnie ta część jest często pomijana: dobrze zaprojektowana aplikacja synchronizuje to, co widzi gość, z tym, co faktycznie dzieje się w kuchni. Każda realna zmiana za kulisami powinna być widoczna na ekranie jako realna zmiana statusu. Jeśli to zrobisz, recepcja przestanie odbierać te same telefony z pytaniem “gdzie jest moje jedzenie?” pięć razy dziennie.
Praktyczny cykl życia zamówienia usługi room service
Każda nieruchomość działa inaczej, więc nie ma jednego uniwersalnego modelu statusu. Większość przepływów pracy można jednak zbudować wokół tych samych kilku podstawowych stanów.
1. Zamówienie złożone
Gość ocenia produkty, modyfikatory, szczegóły dostawy, cenę całkowitą i dane dotyczące płatności przed potwierdzeniem. Po potwierdzeniu system tworzy zamówienie i natychmiast przekazuje informację zwrotną, np. “Zamówienie otrzymane, czekamy na potwierdzenie z kuchni.”
To sformułowanie ma znaczenie. Nie mów gościowi, że jedzenie jest przygotowywane, zanim kuchnia nie wyrazi na to zgody.
Sam rekord zamówienia powinien zawierać identyfikator zamówienia, identyfikator pokoju lub gościa, produkty i modyfikatory, alergeny lub instrukcje specjalne, cenę, status płatności, znacznik czasu oraz aktualny status. Od tego momentu ten identyfikator zamówienia będzie współdzielony przez kuchnię, płatności, powiadomienia i wsparcie.
2. Akceptacja kuchni
Następnie następuje akceptacja w kuchni. W zależności od obiektu, zamówienia trafiają na wyświetlacz w kuchni, do systemu POS restauracji, na tablet dla personelu lub do wewnętrznego panelu operacyjnego. Stamtąd kuchnia może zaakceptować, odrzucić, oznaczyć niedostępne danie lub dostosować czas przygotowania.
Po zaakceptowaniu zamówienia gość może zobaczyć komunikat “Zamówienie potwierdzone, szacowany czas dostawy: 30–40 minut”.” Mała aktualizacja, ale robi dużo: informuje gościa, że człowiek zobaczył prośbę i przygotowania faktycznie postępują. W przypadku hotelu, proces akceptacji pozwala również śledzić znacznik czasu, dzięki czemu można zobaczyć, jak długo czeka się na potwierdzenie zamówienia, a także wykryć zmiany, w których obsługa zaczyna się pogarszać.
Ustaw czas przygotowania jako dynamiczny.c
Stałe “30 minut” na każde zamówienie wygląda dobrze w leniwe popołudnie i rozpada się, gdy naraz pojawia się kilkanaście zamówień na obiad. Szacunki powinny odzwierciedlać to, co faktycznie dzieje się w kuchni: aktualne obciążenie pracą, liczbę otwartych zamówień, stopień złożoności dania, porę dnia, obsadę personelu i wszelkie zasady obowiązujące w danym lokalu.
Żaden z tych elementów nie wymaga modelu predykcyjnego od pierwszego dnia. Personel kuchni może po prostu wybrać 20, 30, 45 lub 60 minut po przyjęciu zamówienia, a doświadczenie gościa znacznie się od tego poprawia. Później hotele mogą wykorzystać historyczne dane o zamówieniach, aby doprecyzować szacunki.
Podstawowa zasada: uczciwa ocena jest lepsza od optymistycznej, ale ciągle nietrafionej.
3. Przygotowanie
Gdy kuchnia faktycznie zacznie gotować, status zmieni się na Przygotowywanie. Goście mogą zobaczyć komunikat: “Twoje zamówienie jest przygotowywane. Przewidywana dostawa: 20:10”.”
Nie każdy wewnętrzny etap w kuchni musi być widoczny. System kuchenny może śledzić wewnętrznie stany: Przesłane, Zaakceptowane, Gotowanie, Podawanie, Kontrola jakości, Gotowe, podczas gdy gość widzi tylko stany: Potwierdzone, Przygotowywane, W drodze, Dostarczone. Zazwyczaj to właściwa decyzja. Aktualizacje statusu powinny dodawać przejrzystości, a nie ujawniać całego procesu pracy w kuchni.
4. Gotowe do dostawy
Po zakończeniu przygotowań zamówienie przechodzi do statusu „Gotowe do dostawy”. Ten stan jest uzasadniony operacyjnie, ponieważ oddziela pracę kuchni od dostawy.
Załóżmy, że kuchnia kończy pracę w 22 minuty, ale zamówienie czeka kolejne 15 minut na dostawcę. Bez oddzielnego statusu, kierownictwo mogłoby obwiniać kuchnię za powolne działanie, podczas gdy prawdziwym wąskim gardłem była dostawa. To jeden z głównych powodów, dla których zachęcamy klientów do przemyślenia operacji przed przystąpieniem do projektowania ekranu dotykowego: oprogramowanie powinno odzwierciedlać rzeczywisty sposób funkcjonowania hotelu, a nie zmuszać personelu do procesu wymyślonego na tablicy.
5. W drodze
Gdy personel odbierze zamówienie, zostaje ono oznaczone jako „W drodze”, a gość otrzymuje powiadomienie push lub w aplikacji: “Zamówienie z obsługi pokoju jest już w drodze.”
Hotele nie potrzebują śledzenia na żywo na mapie. Obsługa pokoju odbywa się w jednym budynku, w przeciwieństwie do marketów z dostawą jedzenia, więc jasny status zazwyczaj wystarcza. Nie chodzi o dodawanie technologii dla samej technologii, ale o odpowiedź na pytanie, które zadaje sobie każdy gość: gdzie jest moje jedzenie?
Aby uzyskać szerszy pogląd na strategię powiadomień, zapoznaj się z naszym artykułem Aplikacja Guest Experience dla hoteli: powiadomienia, które pomagają gościom, w którym omawiamy przydatne aktualizacje usług, głębokie linki, czas i nadmiar powiadomień.
6. Dostarczono
Personel zaznacza dostarczone zamówienie; gość widzi “Dostarczone, smacznego” Aplikacja może także oferować paragon, przycisk ponownego zamówienia, możliwość zgłoszenia problemu, monit o ocenę lub inną prośbę.
Zachowaj historię zamówień zarówno dla gości, jak i personelu. Będzie ona stanowić ścieżkę audytu, gdy następnym razem ktoś zapyta o opłatę, brakujący produkt, zwrot pieniędzy lub reklamację usługi.
Powiadomienia powinny następować po istotnych wydarzeniach
Powiadomienia zyskują na znaczeniu, gdy eliminują niepewność. Szybko stają się irytujące, gdy po prostu powtarzają każde zdarzenie w systemie.
Cztery powiadomienia obejmują większość hoteli:
- Zamówienie potwierdzone: “Twoje zamówienie zostało przyjęte. Przewidywany czas dostawy: 30–40 minut.”
- Opóźnienie w realizacji zamówienia: “Realizacja zamówienia trwa nieco dłużej niż oczekiwano. Nowa szacowana godzina dostawy: 20:30”.”
- W drodze: “Zamówienie z obsługi pokoju jest już w drodze.”
- Anulowane lub zwrócone: “Twoje zamówienie zostało anulowane. Zwrot środków został zainicjowany na Twoją pierwotną metodę płatności”.”
Sformułowanie też ma znaczenie. Nigdy nie pokazuj gościowi “”Przetworzono webhook zwrotu transakcji.” Pokaż im komunikat “Twój zwrot został zainicjowany”. Język techniczny powinien być używany w logach i panelach, a nie w treści widocznej dla gości.
Opóźnienia w obsłudze
Zamówienia nie zawsze idą zgodnie z planem. Następują gorączkowe przygotowania do obiadów, psują się sprzęty, kończą się składniki, a personel jest zawalony pracą. Zespół oprogramowania hotelarskiego powinien projektować z uwzględnieniem tego od pierwszego dnia, zamiast traktować to jako przypadek skrajny, którego nikt nie przewidział.
Przyjmij zamówienie szacowane na 30 minut. Jeśli system zauważy, że termin dostawy minął, może oznaczyć zamówienie i poinformować o tym personel, który zaktualizuje szacunkowy czas dostawy (“Nowy szacowany czas dostawy: 45 minut“), a gość otrzymuje powiadomienie wyjaśniające przyczynę. To lepsze niż pozostawienie zamówienia zamrożonego na “Przygotowywaniu”, podczas gdy pierwotny kosztorys po cichu wygasa w tle.
Znacznie opóźnione zamówienia mogą zostać przekazane do kierownika restauracji lub działu obsługi klienta. Idea polega na tym, aby wyjątki uruchamiały przepływ pracy, a nie znikały w systemie do momentu złożenia skargi przez gościa.
Obsługa anulowań
Zasady anulowania muszą być zgodne z rzeczywistym funkcjonowaniem kuchni. Przed akceptacją zamówienia przez kuchnię jest to proste: gość klika “Anuluj zamówienie” i otrzymuje natychmiastowe potwierdzenie.
Po akceptacji robi się jeszcze bardziej chaotycznie; składniki mogą być już przygotowane, jedzenie może być już na kuchence. Dlatego hotele potrzebują jasnych zasad. Przykładowy model działania wygląda następująco:
- Przed akceptacją kuchni: anuluj automatycznie.
- Zaakceptowano, przygotowanie nie rozpoczęte: anulowanie wymaga potwierdzenia przez personel.
- Rozpoczęcie przygotowań: w zależności od polityki hotelu.
- Dostawa: anulowanie wyłączone, gość kontaktuje się bezpośrednio z obsługą.
Udostępnij te zasady gościowi przed ich potwierdzeniem, aby nikogo nie zaskoczyło to, co wydarzy się później.
Anulowanie i zwrot pieniędzy to dwa różne stany.
Jeden szczegół ma większe znaczenie, niż mogłoby się wydawać: anulowanie zamówienia i zwrot płatności są ze sobą powiązane, ale nie są tym samym zdarzeniem.
Oto prawdziwy proces: personel anuluje zamówienie, aplikacja oznacza je jako anulowane, prośba o zwrot pieniędzy trafia do dostawcy usług płatniczych, dostawca ją akceptuje, zwrot przechodzi przez sieć płatniczą i ostatecznie gość otrzymuje zwrot pieniędzy. To wiele kroków i aplikacja nie powinna ich łączyć w jeden.
Nie wyświetlaj komunikatu “Zwrot zrealizowany” zaraz po anulowaniu, chyba że dostawca płatności faktycznie potwierdził ten stan. Zamiast tego wyświetlaj komunikat “Zamówienie anulowane, zainicjowano zwrot”. Własna dokumentacja zwrotów Stripe’a wyznacza tę samą granicę między utworzeniem zwrotu a jego faktycznym przetworzeniem, zaznaczając, że czas zależy od metody płatności i salda konta. Warto się z nią zapoznać przed zaprojektowaniem tego procesu, zwłaszcza gdy w grę wchodzą różne metody płatności.
Częściowe anulowania i zwroty pieniędzy
Przyjmij zamówienie na śniadanie: kawa, omlet, świeże owoce, croissant. W kuchni zabrakło świeżych owoców. Anulowanie całego zamówienia z powodu braku jednej pozycji byłoby przesadą, więc personel powinien móc wycofać tę jedną pozycję i dokonać częściowego zwrotu pieniędzy.
Gość widzi komunikat w stylu: “Świeże owoce są niedostępne i zostały usunięte z zamówienia. Zaktualizowana kwota zamówienia wynosi 28 EUR”.”
Aby to umożliwić, aplikacja potrzebuje czystego łańcucha: suma zamówienia, korekty, zarejestrowana płatność, kwota zwrotu, kwota końcowa. Należy to poprawnie modelować na wczesnym etapie. Problemy z uzgadnianiem są tu trudne do rozwiązania później.
Udostępnij pracownikom panel wyjątków
Aplikacja gościnna to tylko połowa produktu. Zespoły hotelowe potrzebują operacyjnego widoku zamówień, które wymagają natychmiastowej realizacji, na przykład:
| Zamówienie | Pokój | Status | Czas oczekiwania | Działanie |
|---|---|---|---|---|
| #1421 | 504 | Oczekiwanie na akceptację | 4 minuty | Recenzja |
| #1422 | 311 | Przygotowanie | 27 minut | Aktualizacja ETA |
| #1423 | 708 | Gotowy | 8 minut | Przypisz biegacza |
| #1424 | 206 | Zwrot oczekujący | — | Recenzja |
Dzięki temu prosty ekran składania zamówień staje się narzędziem operacyjnym, w którym personel może wykrywać problemy bez konieczności przeglądania poszczególnych zamówień.
Śledź właściwe wskaźniki operacyjne
Gdy stany zamówień będą miały wiarygodne znaczniki czasu, hotele będą mogły zacząć mierzyć rzeczywistą wydajność obsługi pokoju: średni czas przyjęcia zamówienia do kuchni, średni czas przygotowania, średni czas gotowości do dostarczenia, całkowity czas realizacji, procent dostaw w szacowanym przedziale czasowym, wskaźnik anulowanych zamówień, wskaźnik zwrotów, liczbę opóźnionych zamówień, zamówienia wymagające ręcznej interwencji.
To mówi kierownictwu o wiele więcej niż tylko “ile zamówień otrzymaliśmy”. Odpowiada na pytanie, czy zamówienia wieczorne są częściej spóźniane, czy któryś z lokali przyjmuje zamówienia wolniej niż inne, czy wąskim gardłem jest dostawa, czy przygotowywanie posiłków w kuchni, i które pozycje menu powodują opóźnienia. To właśnie tego rodzaju dane usprawniają zarówno oprogramowanie, jak i działające na nim procesy.
Połącz zamawianie z szerszym doświadczeniem hotelowym
Usługa room service rzadko występuje samodzielnie. W zależności od infrastruktury hotelu, może wymagać komunikacji z systemem PMS, POS lub systemem kuchennym, bramkami płatności, profilami gości, platformą cyfrowego concierge, hotelowym systemem CRM, analityką lub usługami powiadomień.
Nie każda integracja powinna znaleźć się w MVP. Prawdziwe pytanie brzmi, które systemy potrzebują danych w czasie rzeczywistym już teraz, a które mogą poczekać. Jeśli chcesz poznać szerszy kontekst, w naszym wcześniejszym artykule Room Service Reimagined omówiliśmy szerszy przypadek zamawiania przez aplikację.
Typowe błędy w cyklu życia zamówienia, których należy unikać
- Wyświetlanie komunikatu “potwierdzono” przed faktycznym przyjęciem zamówienia przez kuchnię
- Poleganie na jednym ogólnym stanie “w toku” we wszystkim
- Obiecują stałe terminy dostaw, które nie są dotrzymywane
- Wysyłanie zbyt wielu powiadomień
- Nie informowanie gości o zmianie szacunkowej
- Zezwalanie na anulowanie rezerwacji bez jasnych zasad obowiązujących w kuchni
- Traktowanie anulowania i zwrotu pieniędzy jako tego samego zdarzenia
- Utrata powiązania między częściowymi zwrotami a objętymi nimi przedmiotami
- Pomijanie pulpitu nawigacyjnego personelu w przypadku opóźnionych zamówień
- Brak historii zamówień i ścieżki audytu
Większości z nich znacznie taniej jest naprawić na etapie planowania niż po wdrożeniu aplikacji w całym portfolio nieruchomości.
Często zadawane pytania
Ile statusów powinna mieć aplikacja do obsługi pokoju hotelowego?
Nie ma ustalonej liczby. Dla gości cztery do sześciu statusów jest zazwyczaj łatwiej śledzić niż ujawniać każdy wewnętrzny krok. Personel może pracować nad czymś bardziej szczegółowym za kulisami.
Czy goście powinni mieć możliwość samodzielnego anulowania zamówienia?
Zazwyczaj tak, przed akceptacją przez kuchnię. Po rozpoczęciu przygotowań, anulowanie rezerwacji powinno odbywać się zgodnie z polityką operacyjną i zasadami zwrotu kosztów obowiązującymi w hotelu.
Czy goście powinni znać dokładny czas dostawy?
Podawaj realistyczne szacunki, a nie gwarancje, chyba że operacje mogą faktycznie potwierdzić dokładny czas. Aktualizacja szacunków w przypadku poślizgu jest ważniejsza niż dokładne ustalenie pierwszej liczby.
Czy obsługa pokoju wymaga śledzenia na mapie na żywo?
Zazwyczaj nie. W obrębie jednego hotelu statusy takie jak „Przygotowuje się”, „Gotowy” i „W drodze” zapewniają gościom wystarczającą przejrzystość bez wprowadzania dodatkowych komplikacji, o które nikt nie prosił.
Czy zwroty pieniędzy powinny być dokonywane automatycznie?
Zależy to od powodu anulowania, metody płatności, polityki hotelu i dostawcy płatności. Modeluj anulowanie i zwrot jako oddzielne procesy i prowadź rejestr audytu dla obu.
W jaki sposób Appricotsoft podchodzi do procesów zamawiania usług pokojowych
Zaczynamy od tego, co faktycznie dzieje się w świecie rzeczywistym, a nie na ekranach gości. W przypadku usługi room service oznacza to odwzorowanie wszystkiego, od momentu kliknięcia przez gościa przycisku “Złóż zamówienie” do momentu dotarcia jedzenia do pokoju, w tym tego, co się dzieje, gdy coś pójdzie nie tak.
Dzięki naszemu frameworkowi Unison skupiamy klienta, nasz zespół produktowy i deweloperski oraz narzędzia wspierające dostarczanie produktów wspomagane sztuczną inteligencją wokół jednego, współdzielonego procesu pracy. Sztuczna inteligencja przyspiesza niektóre etapy kompilacji, ale to ludzie nadal odpowiadają za decyzje dotyczące produktu, weryfikację i wyniki.
W przypadku projektu tego typu zazwyczaj ustalamy:
1. Przepływ pracy operacyjnej – kto przyjmuje zamówienie, gdzie się ono pojawia, kto aktualizuje czas przygotowania, kto je dostarcza.
2. Stany zamówienia – zarówno skierowane do gości, jak i wewnętrzne, z wyraźnym wyzwalaczem dla każdego przejścia.
3. Przepływy wyjątków – niedostępne pozycje, odrzucone zamówienia, opóźnienia, anulowania, częściowe zwroty pieniędzy, nieudane płatności, nieudane powiadomienia, zmapowane zanim prace rozwojowe zajdą za daleko.
4. Integracje – niezależnie od tego, czy produkt wymaga integracji z systemem PMS, systemem POS, systemem płatności hotelowych czy połączenia z istniejącą platformą cyfrowego concierge.
5. Komunikacja z gośćmi – jasne sformułowania dotyczące potwierdzenia, przygotowania, opóźnień, dostawy, anulowania i zwrotów.
6. Pomiar – strukturyzowanie zdarzeń operacyjnych w taki sposób, aby zespoły hotelowe mogły później odczytać czas przyjęcia, czas przygotowania, opóźnienia w dostawie, anulowania i inne kluczowe wskaźniki efektywności usług.
Cotygodniowe demonstracje w trakcie wdrożenia pozwalają klientom zobaczyć działające oprogramowanie, potwierdzić decyzje i dostosować przepływ pracy, zanim drobne nieporozumienie przerodzi się w kosztowną przebudowę. To połączenie przejrzystości, myślenia o produkcie i ścisłej współpracy pozwala nam tworzyć oprogramowanie, które zespoły hotelowe mogą faktycznie obsługiwać.
Wniosek
Ekran składania zamówienia jest najbardziej widoczną częścią aplikacji do obsługi pokoju w hotelu, ale to cykl życia aplikacji decyduje o tym, czy korzystanie z niej będzie satysfakcjonujące.
Solidny system łączy w sobie złożone zamówienie, przyjęcie zamówienia w kuchni, przygotowanie, gotowość, dostawę, a także uwzględnia bardziej skomplikowane ścieżki: opóźniony, zmieniony, odwołany, częściowo zwrócony, zwrócony.
Dla gości to pewność siebie. Dla personelu to przepływ pracy, który mogą faktycznie uruchomić. Dla kadry zarządzającej to dane, na których mogą działać. A dla każdego, kto planuje szerszą strategię cyfrowego doświadczenia gościa, to fundament, który może później objąć aplikację concierge, funkcje sprzedaży dodatkowej, płatności i głębszą integrację operacyjną.
Nie staramy się upchać jak najwięcej ekranów i funkcji. Naszym celem jest oprogramowanie, które rozwiązuje rzeczywisty problem, odpowiada sposobowi pracy Twoich zespołów i nie zamienia się w bałagan, którego nikt nie rozumie po dwóch latach. Jeśli planujesz aplikację do obsługi pokoju lub większy projekt rozwoju aplikacji hotelowej, możemy pomóc przekształcić przepływ pracy operacyjnej w rzeczywisty plan produktu.
