Преди десет години работата на хотелския PMS беше лесна за описание. Той държеше резервациите, стайния план и цените. Всичко останало — уебсайтът, фактурата, списъкът за домакинството, ресторантът, спа центърът — живееше някъде другаде, обикновено на хартия, и това беше нормално.
Вече не е нормално и причината не е, че хотелите са станали по-взискателни. Причината е, че пътят на госта се премести онлайн от край до край, а софтуерът в по-голямата си част не го последва.
Днес резервацията е средата на историята, не началото и определено не краят. Което означава, че интересният въпрос за хотелския софтуер вече не е "дали управлява резервациите добре?", а "къде спира и кой плаща за празнината?".
Истинската цена на софтуера е празнината между инструментите
Вземете една обикновена последователност и пребройте системите, включени в имот, който е купил всяка част поотделно.
Гост намира хотела в Google и попада на уебсайта. (Инструмент за уебсайт.) Проверява наличността и резервира. (Резервационен двигател.) Наличността трябва да изчезне от OTA каналите. (Ченъл мениджър.) Резервацията се появява на рецепцията. (PMS.) Стаята трябва да бъде почистена преди пристигането. (Електронна таблица или хартия.) Гостът е фирма и се нуждае от коректна фактура. (Счетоводен инструмент.) При настаняването пита за вечеря. (Ресторантска система или телефонно обаждане.) И за масаж в събота. (Бележник на рецепцията на спа центъра.)
Осем точки на контакт. Дори всеки инструмент да е добър, вижте какво се случва между тях:
- Името на госта се въвежда поне три пъти и поне веднъж е изписано различно
- Някой експортира списък всяка сутрин, за да направи друг списък
- Адресът за фактурата съществува на две места и не съвпада на нито едно
- Резервацията за вечеря не е свързана със стаята, така че никой не знае, че гостът се е освободил по-рано
- Часът за спа процедура се сблъсква със стая за процедури, вече заета от друг гост
Нито едно от тези неща не е катастрофа. Всички те са малък данък върху всяко едно пристигане, плащан от персонала, всеки ден, завинаги. Това е истинската цена на хотелския софтуер и тя никога не се появява на никоя фактура от доставчик.
Грешките не са случайност, те са структурни
Овърбукингът, който съсипва една събота, рядко е резултат от нечия небрежност. Това са две системи, които не са комуникирали в решаващия момент — цена, обновена на едно място, канал, който се синхронизира по график, стая, продадена два пъти в празнината.
Същото важи и за по-малките провали: гостът, таксуван с грешна цена, защото офертата е живяла в имейл; пристигането, за което никой не се е подготвил, защото резервацията е дошла през канал, който някой проверява по-рядко; фактурата, издадена два пъти, защото фирмените данни са въведени на ръка в 22:00.
Тези неща не могат да се отстранят с обучение. Те са свойства на архитектурата, не на персонала. Единственото структурно решение е да се намали броят на местата, където се съхранява един и същ факт.
Какво трябва да покрива хотелската система сега
Ако картографирате реалния път, а не софтуерните категории, един имот се нуждае от всичко това свързано:
Преди престоя
- Уебсайт, който може да приема директна резервация, а не само да показва телефонен номер
- Резервационен двигател с реална наличност, вграден в този уебсайт
- Синхронизация на каналите, така че OTA каналите и директният двигател никога да не продават една и съща стая
- Цени, сезони и ограничения на едно място
По време на престоя
- Рецепцията: пристигания, заминавания, смени на стаи, удължавания, гости без резервация
- Домакинството: кой какво чисти, в какъв ред и какво е готово
- Всичко, което гостът поиска, докато стои там
Около престоя
- Ресторантско обслужване, ако имате такова
- Услуги с часове — спа, масажи, процедури, екскурзии, семинарна зала
- Оферти и фактуриране, с коректните фирмени данни и данъчно третиране
- Досието на госта, което трябва да бъде едно и също всеки път
Това не е списък с пожелания. Това е един вторник в средно голям хотел.
Какво означава "една екосистема" на практика
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 — или прочетете как да изберете хотелска система, на която можете да се доверите, ако сте в средата на решението.
