Dvigubos rezervacijos: užkirsti kelią ir išspręsti


Kodėl	Suprasti, kodėl dvigubos rezervacijos vis dėlto atsiranda esant automatynei sinchronizacijai, ką sistema daro, kad jų nebūtų, ir kur kreiptis, kai konfliktas vis dėlto įvyko.
Kam	Viešbučio administratoriui su prijungtais kanalais.
Ką gausite	Saikingi lūkesčiai – dvigubų rezervacijų visiškai atmesti neįmanoma – ir žinojimas, kur konfliktas matomas ir kaip jis sprendžiamas.
Apribojimai	Čia – kanalų pusė: kodėl sutapimas įmanomas ir kas mažina riziką. Žingsnis po žingsnio konflikto sprendimas – kalendoriaus straipsnyje, nuoroda viršuje.

Sprendimas kalendoriuje – Jei atsiranda dviguba rezervacija. Prevencija kanaluose – šis straipsnis ir apžvalga Channel Manager.

Dviguba rezervacija – atsitiktinis to paties kambario pardavimas du kartus: pavyzdžiui, kanalas spėjo parduoti kambarį tą pačią akimirką, kai jį įrašė recepcija. Prieinamumas visiems kanalams HotelsCalendar sistemoje skaičiuojamas iš vieno kalendoriaus, tačiau tokie sutapimai vis dėlto pasitaiko. Šiame straipsnyje – kodėl jie įmanomi, ką sistema daro, kad jų nebūtų, ir kur kreiptis, kai konfliktas jau yra tinklelyje.

Kodėl dvigubos rezervacijos įmanomos

Priežastis – lenktynės: kanalas pardavė kambarį tą pačią akimirką, kai jis buvo parduotas PMS sistemoje arba kitame kanale. Pardavimo akimirką abi pusės dar viena apie kitą nežinojo: kiekviena sąžiningai laikė kambarį laisvu. Tai dviejų pardavimų sutapimas, o ne konkretaus darbuotojo klaida – kaltųjų ieškoti nereikia, reikia išspręsti konfliktą.

Tokie sutapimai – retenybė, bet ne nulis, todėl dvigubų rezervacijų visiškai atmesti neįmanoma. Pardavimas, viršijantis prieinamumą, nepalieka nepastebėtas: abi rezervacijos patenka į sistemą ir keliauja apdoroti – nė vienas svečias nepasimeta. Kita istorijos pusė tokia pat sąžininga: sistema neslepia sutapimo, o rodo jį tinklelyje ir duoda įrankių jį išspręsti.

Kas mažina riziką

Riziką mažina ne atskiras nustatymas, o pati sistemos sandara – vienas kalendorius visiems kanalams:

Prieinamumas visiems kanalams skaičiuojamas iš vieno PMS kalendoriaus: kiekvienas pardavimas – PMS sistemoje, viešbučio svetainėje ar bet kuriame kanale – perskaičiuoja jį visur. Tipinė dvigubų rezervacijų priežastis dingsta.
Pakeitimai keliauja į kanalus automatiškai – atskiro mygtuko „siųsti“ nėra: sistema juos išsiunčia pati, be rankinio paleidimo.
Pardavimo apribojimai – minimali ir maksimali viešnagės trukmė, atvykimo ir išvykimo datų uždarymai – į kanalus keliauja kartu su kainomis ir prieinamumu. Kanalas neparduoda to, ką parduoti negalima.
Uždarius datą pardavimui, prieinamumas visuose kanaluose nulinamas – data iš karto dingsta iš pardavimo visur.

Išsaugojus susiejimą, kainos ir prieinamumas siunčiami dvejiems metams į priekį: visą tą laiką kanalas gyvena pagal tą patį kalendorių kaip PMS. Recepcijai nereikia prisiminti apie kanalus: tinklelis ir kanalai gyvena viename kalendoriuje, o pardavimas vienoje vietoje pakeičia prieinamumą visuose.

Overbooking matomas iš karto

Jei lenktynės vis dėlto įvyko, konfliktas Planeryje nepalieka nepastebėtas: kambario eilutė apvesta raudonu rėmu, o Plannerio legendoje („Juostos ženklai“) jis įrašytas kaip įspėjimas „Overbooking“. Rėmas išskiria visą kambario eilutę, o ne atskirą datą, ir matomas, kol slinkate tinklelį, – dvigubas pardavimas negyvena sistemoje nepastebėtas iki svečio atvykimo.

Rezervacija iš kanalo, pardavusi jau užimtą kambarį, nepražūva: ji patenka į sistemą be priskirto kambario ir su overbooking žyma – ir laukia sprendimo Planeryje. Kiekvienos iš dviejų rezervacijų šaltinis matomas juostoje ženkliuku – „Tiesioginė (recepcijoje)“, „OTA kanalas“ ir kiti, – bet konflikto ženklai nuo šaltinio nepriklauso.

Užtenka trumpo žvilgsnio ryte, anksčiau nei prasideda dienos įsiregistravimai: anksčiau pastebėtas konfliktas išsprendžiamas be svečio prie recepcijos.

Raudonas rėmas – ne vienintelis legendos įspėjimas: šalia jo gyvena „Neapmokėta“ ir rezervacijos būsenų ženkliukai. Jei legendos dar netyrinėjote, atidarykite „Juostos ženklai“ Plannerio skydelyje – per minutę ji pamoko skaityti tinklelį.

Kaip išspręsti konfliktą

Abi konflikto rezervacijos – tikros, su gyvais svečiais viduje, todėl gydymas – ne atšaukimas, o perkėlimas. Viena iš dviejų persikelia į laisvą to paties tipo kambarį Plannerio tinklelyje, o abi rezervacijos lieka galiojančios. Žingsnis po žingsnio išnagrinėta – įskaitant scenarijų, kai svečias jau stovi prie recepcijos – straipsnyje Jei atsiranda dviguba rezervacija.

Kaip užkirsti kelią pasikartojimui

Konfliktas retas, o įpročiai, kurie sumažina riziką dar labiau, paprasti:

Laikykite susiejimą aktualų. Nesusieta kanalo kategorija – perteklinio rankinio darbo šaltinis: patikrinkite kategorijų ir tarifų poras prieš sezoną ir po kambarių fondo pokyčių. Kaip suderinti poras – straipsnyje Susiejimas: sujungiame kanalo kategorijas ir tarifus su PMS.
Neparduokite apeidami sistemą. Rezervacija telefonu – taip pat rezervacija PMS sistemoje: įrašykite ją į kalendorių kaip bet kurią kitą (Rezervacija per 4 paspaudimus). Viskas, ką parduoda objektas, turi eiti per vieną kalendorių: pardavimas, apeinantis jį, prieinamumo kanaluose neperskaičiuos.
Pereinate iš kitos sistemos ir dirbate iš karto dvejose – uždarykite pardavimus senojoje anksčiau, nei atversite naujojoje. Dvi sistemos su atviru pardavimu atkartoja tas pačias lenktynes, tik kiekvieną dieną.

Rezultatas: vienas kalendorius visiems kanalams, aktualus susiejimas ir jokių pardavimų apeinant sistemą – tada net ir retas konfliktas bus matomas tinklelyje ir išspręstas perkėlimu, o ne atšaukimu.

Taip pat žiūrėkite

Jei atsiranda dviguba rezervacija – žingsnis po žingsnio konflikto sprendimas: pastebėti tinklelyje ir perkelti rezervaciją į laisvą to paties tipo kambarį.
Susiejimas: sujungiame kanalo kategorijas ir tarifus su PMS – kaip laikyti kategorijų ir tarifų poras aktualias.
Pardavimo kanalai: dažni klausimai – trumpi atsakymai apie prijungimą, sinchronizaciją ir rezervacijas iš kanalų.