Что такое PMS для отеля и как её выбрать

PMS (Property Management System, система управления объектом размещения) — это программа, в которой живёт вся работа отеля: номерной фонд, брони, гости, заселение и выезд, оплаты, уборка и отчёты. Если у отеля есть одно место, где видно, кто в каком номере сегодня живёт, кто приезжает завтра, кто сколько заплатил и какие номера свободны на август, — это и есть PMS.

Слово звучит как что-то для крупных сетей, но задача у него бытовая: перестать держать состояние отеля в голове администратора, в чужом экране агрегатора и в файле, который лежит на одном компьютере. Ниже — что именно входит в PMS, чем она отличается от соседних продуктов, с которыми её постоянно путают, и как её выбирать, чтобы не переезжать снова через год.

Что входит в PMS

Набор модулей у разных систем называется по-разному, но задачи под ними одни и те же. Вот блоки, без которых система не будет PMS.

Шахматка — календарь номерного фонда

Главный экран. По вертикали — номера или категории, по горизонтали — даты, внутри — брони полосками. Отвечает на вопрос «что у нас свободно и когда» за одну секунду вместо десяти минут сверки. Из неё же обычно двигают брони между номерами, ставят номер на ремонт и видят, где остались одиночные пустые ночи между заездами.

Брони и их статусы

Бронь — центральная сущность всей системы: даты, номер, гость, цена, оплата, источник. Статус показывает, где она в жизненном цикле: запрос, подтверждена, оплачена, заселён, выехал, отменена, не заехал. Смысл статусов не в бюрократии, а в том, что по ним считается всё остальное: кого встречать завтра, с кого просить предоплату, кому вернуть деньги.

Карточка гостя

История приездов, контакты, предпочтения, суммы, которые человек у вас оставил. Это то, что превращает разовые сделки в базу: гость, который приезжал три года подряд, стоит дешевле любого рекламного канала — но только если вы знаете, что он существует. В отеле без PMS эта база физически не накапливается.

Тарифы и цены

Правила, по которым считается стоимость: базовый тариф, невозвратный, с питанием и без, сезонные периоды, минимальная длительность, детские места, условия отмены. Задача блока — чтобы цену не считал человек в уме. Как только цена считается вручную, она начинает расходиться между сайтом, каналами и тем, что сказали по телефону.

Оплаты и документы

Предоплаты, доплаты, возвраты, счета, кассовые чеки. В России тут же живёт требование ФЗ-54: при оплате гостю нужен чек. Важный вопрос к любой системе — умеет ли она закрывать чек сама или это остаётся ручной работой администратора в отдельной программе.

Отчёты

Загрузка, выручка, ADR (средняя цена проданного номера), RevPAR (выручка на доступный номер), источники броней, долги по оплатам. Это единственная причина, по которой решения принимаются на факте, а не на ощущении «вроде неплохой был месяц». Подробнее — в разборе метрик отеля.

Уборка (housekeeping)

Список номеров на сегодня: кто выезжает, где нужна текущая уборка, где генеральная, что уже готово к заселению. Блок кажется второстепенным, пока не наступает день с двадцатью выездами и двадцатью заездами — тогда именно он определяет, будет ли гость ждать номер в холле.

PMS против Excel и тетради

Честно: таблица — нормальный инструмент, и много объектов живут на ней годами. Она бесплатная, её не нужно осваивать, она никогда не «упадёт» из-за проблем на чужом сервере. Пока выполняются три условия, менять её не на что.

• Номеров мало. До 5–10 единиц состояние отеля целиком помещается в голову одного человека, и файл — просто внешняя память.
• Продажи идут через один канал. Один агрегатор или только звонки — синхронизировать наличие в этом случае не с чем и не с кем.
• Работает один человек. Нет ситуации, когда двое одновременно распоряжаются одним и тем же номером.

Проблема в том, что ломается таблица не постепенно, а в конкретных точках — и почти всегда в высокий сезон, когда цена ошибки максимальна.

• Двое правят одновременно. Администратор ставит бронь, владелец в это же время ставит свою — один из них перезаписывает другого. Номер продан дважды, и это выясняется на стойке при заезде.
• Нет истории изменений. Цена в брони другая, чем договаривались. Кто её поменял и когда — установить нечем, остаётся только спорить.
• Нельзя ответить «кто и когда снял бронь». Строка просто исчезла. Кто её удалил — случайно, специально, вчера, неделю назад — неизвестно. Разбор превращается в поиск виноватого без доказательств.
• Нечем синхронизировать каналы. Продали номер по телефону — его нужно вручную закрыть в каждом канале, где он выставлен. Забыли на час — получили овербукинг и отзыв, который стоит дороже самой брони.
• Потеря файла = потеря всего. Сломался ноутбук, файл перезаписан, папка удалена — вместе с ним исчезают и брони, и вся история гостей за годы. Восстанавливать неоткуда.

PMS, channel manager и booking engine — три разные задачи

Эти три слова путают чаще всего, и путаница дорого стоит: отель покупает одно, а ждёт от него другого. Разница простая — они смотрят в разные стороны.

То есть PMS знает, что номер занят. Channel manager отвечает за то, чтобы об этом за минуту узнали все каналы, где вы выставлены, — подробнее в разборе что такое channel manager. А booking engine — это то, через что гость бронирует на сайте отеля, минуя комиссию агрегатора. Одно без другого работает, но плохо: PMS без channel manager не спасает от овербукинга, channel manager без PMS не знает, что номер продали по телефону.

Три продукта или одна система

Исторически это были три отдельных продукта от трёх поставщиков, которые связывали между собой интеграциями. Сейчас рынок движется в сторону единых систем, где все три задачи закрыты в одном кабинете. У обоих подходов есть честная цена.

• Минус единой системы — зависимость от одного поставщика. Всё в одних руках: цена, качество поддержки, скорость развития, судьба ваших данных. Не устроило что-то одно — переезжать придётся целиком, а не заменять один кубик.
• Минус трёх раздельных — стыки рвутся, и виноватого не найти. Наличие разъехалось между PMS и каналом. PMS говорит, что отдала данные; channel manager — что не получил. Вы между двумя поддержками, а овербукинг уже ваш. Каждый стык — это ещё и отдельный договор, отдельный счёт и отдельное обновление, которое может сломать соседа.

Практическое правило: чем меньше у вас людей, тем дороже вам обходятся стыки. Крупная сеть может позволить себе человека, который разбирается, чья это ошибка. Отель на 40 номеров с одним администратором — нет.

Как выбирать: вопросы поставщику

Это главный раздел. Демонстрация всегда выглядит хорошо — на ней показывают счастливый сценарий. Реальная стоимость владения выясняется в другом: что будет, когда вы захотите уйти, когда что-то сломается и когда придёт счёт за то, о чём не говорили. Ниже — вопросы, ответы на которые стоит получить письменно до оплаты.

Данные

• Где физически хранятся данные гостей? Для России это требование закона о персональных данных (152-ФЗ), а не вкусовщина: данные гостей должны храниться на серверах в РФ. Ответ «в облаке» — не ответ. Правильный ответ называет страну.
• Отдадите ли вы мне мои данные при уходе, в каком формате и за какие деньги? Брони, гости, история, документы — это ваш актив, а не актив поставщика. Хороший признак — выгрузка доступна вам самим в любой момент и в машиночитаемом формате. Плохой — «напишите в поддержку, мы подготовим».
• Кто и как переносит данные при подключении? Уточните, что именно переносится: только текущие брони или ещё и история гостей за прошлые годы. История — это ваша база повторных продаж, и потерять её при переезде обиднее всего.

Российская специфика

• Какие каналы продаж поддержаны в РФ? Не «более 100 каналов» вообще, а конкретно те, где продаётесь вы. Спросите список поимённо и когда каждый из них последний раз обновлялся.
• Как обстоит дело с онлайн-кассой и чеками? По ФЗ-54 гостю при оплате нужен чек. Выясните, закрывает ли систему чек сама, через какого оператора, и что остаётся делать администратору руками.
• Куда идут деньги гостя при онлайн-оплате? Прямо на счёт отеля или сначала к посреднику. Это разные истории и по срокам поступления, и по рискам.

Деньги

• Сколько это стоит на самом деле? Сложите всё: подписка, внедрение, обучение, поддержка, каждый модуль отдельно, процент с броней, доплата за дополнительного пользователя, за второй объект, за интеграцию. Просите итог за год, а не цену за месяц.
• Есть ли процент с броней и с чего он берётся? С прямых броней, со всех, с прожитых или с забронированных. Разница в деньгах — кратная.
• Что войдёт в счёт через год? Уточните, как и на сколько меняется цена при продлении и что происходит, когда у вас становится больше номеров.

Что будет, когда сломается

• Что происходит, когда система встаёт в высокий сезон, и кто отвечает? Спросите про режим работы поддержки (в субботу в августе в 22:00 — тоже?), канал связи, скорость реакции и что написано про это в договоре, а не на лендинге.
• Как я узнаю о проблеме — от вас или от гостя? Зрелый поставщик сообщает о сбое сам.
• Что делать отелю, пока система недоступна? Хороший ответ — понятный запасной сценарий. Отсутствие ответа — тоже ответ.

Запуск и люди

• Можно ли попробовать до оплаты? На своих номерах, своих тарифах, без карты и без обязательств. Это единственный способ проверить, что система подходит именно вашему объекту.
• Сколько времени займёт запуск? От «мы начали» до «принимаем брони». Спросите, что требуется от вас, — обычно именно это и есть настоящий срок.
• За сколько обучится менеджер? Не «есть база знаний», а сколько часов до самостоятельной работы у человека без опыта. Если ответ — «две недели обучения», это не сложный продукт, это ваш будущий фонд оплаты труда.

Выбор и внедрение по шагам

Порядок важен: большинство неудачных внедрений — это правильные шаги, сделанные не в том порядке. Сначала бесплатное и обратимое, потом дорогое и необратимое.

1. 1

   Опишите, что у вас ломается сейчас

   Не «нужна PMS», а конкретно: снимаем брони из-за овербукинга, теряем запросы ночью, не знаем реальную выручку по каналам, администратор час в день переносит данные руками. Список из 3–5 болей — это ваше техзадание. Без него вы будете выбирать по красоте интерфейса, а через год обнаружите, что ни одна боль не закрыта.

2. 2

   Определите обязательный минимум

   Разделите функции на «без этого не работаем» и «было бы неплохо». В первый список обычно попадает 5–7 пунктов: ваши каналы продаж, чеки, модуль бронирования на сайте, шахматка, отчёты. Всё остальное — второй список. Он нужен, чтобы не платить за модули, которые вы не откроете.

3. 3

   Отберите 2–3 кандидата и задайте вопросы из чек-листа

   Письменно. Ответы про хранение данных, экспорт, полную стоимость за год, поддержку в сезон и срок запуска сравните в одной таблице. На этом этапе обычно отпадает половина — не из-за функций, а из-за отказа отвечать прямо.

4. 4

   Попробуйте сами, до оплаты и до внедрения

   Заведите свои категории, свои тарифы, поставьте пару тестовых броней, проведите оплату, выгрузите отчёт. Пятнадцать минут работы руками говорят больше, чем часовая презентация. И главное — сажайте за это того человека, который будет работать в системе каждый день, а не только себя.

5. 5

   Дайте попробовать менеджеру и послушайте, что он скажет

   Пользоваться системой будет он, а не вы. Если администратор не находит, как поставить бронь, за пять минут — это не он плохой, это система вам не подходит. Сопротивление персонала — главная причина, по которой купленные PMS стоят неиспользованными.

6. 6

   Выберите время переезда: не сезон

   Переезд в низкий сезон — это обучение в спокойном режиме и право на ошибку. Переезд в июле — это ошибки на живых гостях. Если объект курортный, окно обычно одно: осень или ранняя весна.

7. 7

   Перенесите данные, включая историю гостей

   Текущие брони перенести придётся в любом случае. Историю приездов — тоже, даже если кажется, что «старое не нужно»: это ваша база повторных продаж, и второй возможности её забрать не будет. Проверьте перенос выборочно: возьмите десяток известных вам гостей и убедитесь, что их история на месте.

8. 8

   Первый месяц ведите параллельно и сверяйтесь

   Старый файл ещё жив, но решения принимаются уже в новой системе. Раз в неделю сверяйте загрузку и выручку между старым и новым — так вы поймаете расхождения, пока они дешёвые. Через месяц спокойных сверок старый файл можно закрывать.

Красные флаги при выборе

Это не про конкретные компании — это общие признаки категории, которые стоит замечать у кого угодно, включая нас. Каждый из них сам по себе не приговор, но требует объяснения.

• «Цена по запросу» без калькулятора. Если стоимость нельзя посчитать самому, она зависит не от вашего объекта, а от того, как вы разговариваете с менеджером. Сравнить такие предложения между собой невозможно — и именно в этом смысл.
• Платное внедрение до того, как вы увидели продукт. Оплата за настройку вперёд — это когда вы платите за то, чтобы узнать, подходит ли вам продукт. Проверка должна быть бесплатной, платить имеет смысл за пользу.
• Обязательный многолетний договор. Долгий контракт со скидкой — нормально, если это ваш выбор. Долгий контракт как единственный вариант — это признание, что удерживать вас качеством не рассчитывают.
• Экспорт данных за деньги или «через поддержку». Ваши брони и ваши гости — ваш актив. Если забрать его можно только по заявке, за отдельную плату и в неудобном формате, вы не клиент, вы заложник.
• Демо только со звонком продавца. Отсутствие возможности просто зайти и посмотреть обычно означает, что продукт продаётся разговором, а не собой. Иногда за этим стоит сложность, которую нельзя показать без сопровождения — но тогда вспомните вопрос про обучение менеджера.

Типичные ошибки внедрения

Три ошибки повторяются чаще всех остальных вместе взятых. Все три совершают не по незнанию, а из лучших побуждений.

Выбирают по количеству функций

Сравнительная таблица, где у одной системы 40 галочек, а у другой 25, кажется убедительной. Но работать в системе будет администратор, а не таблица. Функция, которую он не освоил, стоит ровно ноль — при этом вы за неё платите и, что хуже, платите сложностью: чем больше в интерфейсе всего, тем дольше человек ищет нужное в пятницу вечером с очередью на стойке. Правильный критерий — освоит ли менеджер то, что вам действительно нужно, за разумное время.

Переезжают в разгар сезона

Логика понятная: «сейчас как раз горит, давайте срочно». Но в высокий сезон у команды нет ни часа на обучение, а любая ошибка происходит на живом госте. Ещё и оценить систему нормально не получится: в аврале всё новое кажется неудобным. Итог — систему объявляют плохой и возвращаются к таблице, заплатив за подписку.

Не переносят историю гостей

Самая дорогая из трёх и самая незаметная. При переезде кажется, что важны только будущие брони, а «архив» подождёт. Потом старый доступ закрывается, файл теряется, и вместе с ним исчезает знание о том, кто у вас уже жил. Гость, приезжавший к вам три сезона подряд, становится холодным трафиком, которого нужно покупать заново. Историю переносят один раз — в момент переезда, другого шанса обычно нет.