Пред десет години работата на хотелскиот PMS беше лесно да се опише. Ги чуваше резервациите, планот на соби и цените. Сè друго — веб-страницата, фактурата, списокот за чистење, ресторанот, спа-центарот — живееше некаде на друго место, обично на хартија, и тоа беше нормално.
Тоа веќе не е нормално, а причината не е што хотелите станаа попребирливи. Причината е што патувањето на гостинот се пресели онлајн од почеток до крај, а софтверот во најголем дел не го следеше.
Денес резервацијата е средината на приказната, а не почетокот и дефинитивно не крајот. Што значи дека интересното прашање за хотелскиот софтвер веќе не е „дали добро управува со резервациите?" туку „каде застанува, и кој ја плаќа празнината?"
Вистинската цена на софтверот е празнината помеѓу алатките
Земете една обична секвенца и избројте ги системите вклучени во објект кој го купил секој дел посебно.
Гостинот го наоѓа хотелот на Google и слетува на веб-страницата. (Алатка за веб-страница.) Проверува достапност и резервира. (Booking engine.) Достапноста мора да исчезне од OTA каналите. (Channel manager.) Резервацијата се појавува на рецепција. (PMS.) Собата треба да се исчисти пред пристигнување. (Excel табела, или хартија.) Гостинот е компанија и му треба соодветна фактура. (Сметководствена алатка.) При пријавување прашува за вечера. (Ресторански систем, или телефонски повик.) И за масажа во сабота. (Тетратка на шанкот на спа-центарот.)
Осум допирни точки. Дури и ако секоја алатка е добра, погледнете што се случува помеѓу нив:
- Името на гостинот се внесува најмалку три пати, а барем еднаш се пишува различно
- Некој секое утро извезува список за да направи друг список
- Адресата за фактура постои на две места и не се совпаѓа на ниту едно
- Резервацијата за вечера не е поврзана со собата, па никој не знае дека гостинот се одјавил порано
- Терминот во спа-центарот се судира со соба за третман веќе зафатена од друг гостин
Ниту едно од овие не е катастрофа. Сите тие се мал данок на секое пристигнување, платен од персоналот, секој ден, засекогаш. Тоа е вистинската цена на хотелскиот софтвер, и таа никогаш не се појавува на ниту една фактура од добавувачот.
Грешките не се случајни, тие се структурни
Overbooking-от што ја уништува саботата ретко е нечија невнимателност. Тоа се два системи кои не комуницирале во моментот кога било важно — цена ажурирана на едно место, канал што се синхронизира по распоред, соба продадена двапати во празнината.
Истото важи и за помалите неуспеси: гостинот наплатен по погрешна цена затоа што понудата живеела во е-пошта; пристигнување за кое никој не се подготвил затоа што резервацијата дошла преку канал што некој го проверува поретко; фактура повторно издадена двапати затоа што податоците на компанијата биле внесени рачно во 22:00 часот.
Овие не можете да ги отстраните со обука. Тие се својства на архитектурата, а не на персоналот. Единствената структурна поправка е да се намали бројот на места каде што се чува истиот податок.
Што мора да покрива еден хотелски систем сега
Ако го мапирате вистинското патување наместо софтверските категории, на еден објект му треба сето ова поврзано:
Пред престојот
- Веб-страница што може да прими директна резервација, а не само да прикаже телефонски број
- Booking engine со реална достапност, вграден во таа веб-страница
- Синхронизација на канали за OTA каналите и директниот engine никогаш да не ја продадат истата соба
- Цени, сезони и ограничувања на едно место
За време на престојот
- Рецепција: пристигнувања, заминувања, промени на соби, продолжувања, walk-in гости
- Хигиена: кој што чисти, по кој редослед, и што е подготвено
- Сè што гостинот бара додека стои таму
Околу престојот
- Ресторанска услуга, ако ја имате
- Услуги закажани по термин — спа, масажа, третмани, тури, сала за семинари
- Понуди и фактурирање, со точни податоци на компанијата и даночен третман
- Картонот на гостинот, кој треба да биде истиот картон секој пат
Тоа не е листа на желби. Тоа е вторник во хотел со средна големина.
Што значи „еден екосистем" во пракса
KIMISUITE го покрива тоа патување во еден работен простор, и поентата не е бројот на модули. Поентата е што гостинот, резервацијата, фактурата и задачата се истите записи насекаде.
Конкретно, во објект што работи на KIMISUITE:
- Веб-страницата носи виџети за резервација — слајдер, листа или пребарување — така што директната резервација започнува на вашиот сопствен домен и не плаќа провизија.
- Booking Hub ја држи резервацијата, планот на соби, цените и профилот на гостинот, и ја одржува достапноста синхронизирана со OTA каналите во реално време.
- Организацијата на чистењето живее во истиот систем како и резервацијата: задачите за хигиена се доделуваат, статусот на собата се следи и дневниот работен тек е видлив, затоа што системот веќе знае кој пристигнува и кој заминува.
- CRM Business Hub ја издава понудата за корпоративната резервација, ја претвора во фактура, ги применува правилата за ДДВ и го следи плаќањето — наспроти истиот запис на клиентот, со е-фактура каде што е потребно.
- Service Manager го води спа-третманот, масажата, турата и салата за семинари, со терапевтот и собата за третман како реални ресурси што можат да се резервираат само еднаш.
- Gastro POS Hub го води ресторанот, поврзан со истиот работен простор наместо со посебен остров.
- Task Hub ги претвора работите што се случуваат во работи што се завршуваат — потврдена резервација може автоматски да ја креира картичката „подготви кошница за добредојде", со рок 24 часа пред пристигнување.
Резултатот не е дека некоја поединечна алатка е драматично подобра од специјализирана. Резултатот е што шевовите ги нема. Никој не го препишува името на гостинот. Фактурата ја знае резервацијата. Спа-центарот го знае датумот на одјавување. Задачата за кошницата за добредојде постои затоа што резервацијата сама се потврдила во неа.
Искрениот контрааргумент
Посветена алатка за една намена понекогаш ќе има повеќе длабочина во својата тесна област отколку еквивалентниот модул во поврзан пакет. Тоа е реален компромис и вреди да се именува наместо да се преправаме дека не постои.
Прашањето е кој проблем всушност ве чини повеќе: функцијата што ја немате во специјализираната алатка, или шесте шевови помеѓу осум алатки што секое пристигнување мора да ги помине.
За голем синџир со посветен ИТ тим и буџет за интеграции, специјализираниот стек може да биде вистинскиот одговор. За објект каде што лицето што го избира софтверот е истото лице што ја покрива рецепцијата во недела, обично не е.
Како да размислувате за одлуката
Престанете да споредувате PMS со PMS. Наместо тоа, споредете го целото патување:
- Нацртајте го патувањето на вашиот гостин од првото пребарување на Google до конечната фактура.
- Обележете ја секоја точка каде што податоците се препишуваат или се извезуваат од едно место на друго.
- Избројте ги најавувањата што вашиот тим ги прави во текот на една нормална смена.
- Соберете ја месечната цена на секоја вклучена алатка, вклучувајќи ги и оние што никој не ги памети.
- Потоа прашајте колку од тоа би отстранил еден поврзан работен простор.
Таа бројка — а не месечната цена на PMS-от — е она што софтверот ве чини денес.
Booking Hub се наплаќа по тип на соба наместо по соба, и бидејќи остатокот од патувањето живее во истиот работен простор, втората и третата алатка не доаѓаат со свои претплати, свои најавувања и своја верзија на името на вашиот гостин.
Хотелскиот PMS веќе подолго време не е само PMS. Системите што сè уште се однесуваат како таков тивко ви наплаќаат за разликата.
Погледнете што покрива Booking Hub — или прочитајте како да изберете хотелски систем на кој можете да му верувате ако сте во средината на одлуката.
