Что должна уметь система управления отелем?

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

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

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

Минимум определяется рабочим днем, а не числом модулей

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

Полезно разложить обычный день не по названиям модулей, а по решениям администратора. Можно ли подтвердить бронь, не сверяя три календаря? Видно ли, кто должен приехать сегодня и кто не оплатил остаток? Система сама понимает, какой документ и в какой срок нужен для гражданина России или иностранца? После выезда горничная получает понятную задачу, а номер не возвращается в продажу до уборки? На эти вопросы нужен ответ в одной карточке бронирования или в связанных с ней действиях.

Для объекта от 5 до 30 номеров обязательный контур выглядит так:

• шахматка номеров и мест с фактической доступностью;
• бронь с гостями, тарифом, источником, оплатами и историей изменений;
• регистрационный учет и подготовка уведомлений по данным документов;
• расчет туристического налога по каждой оказанной услуге проживания;
• кассовая и платежная отметка, даже если чек формирует отдельная касса;
• состояние номера, задачи уборки и журнал действий сотрудников.

Слово «модуль» ничего не гарантирует. Два экрана могут называться «Бронирование» и «Гости», но не передавать друг другу даты или паспортные данные. Проверяйте не наличие пункта меню, а сквозной путь данных. Карточка гостя должна заполнять проживание и уведомление, а выезд должен менять состояние номера и попадать в налоговый период без повторного ввода.

Есть и простой предел. Если функцию можно убрать на месяц без риска для продажи, обязательного учета или заселения, это не минимум. CRM для рассылок, программа лояльности и дизайнерский конструктор отчетов могут приносить пользу, но отсутствие любого из них не останавливает вечерний заезд. Их место во второй очереди.

Шахматка обязана предотвращать конфликт до подтверждения

Хорошая шахматка не рисует цветные полосы поверх календаря. Она хранит инвентарь и применяет правила доступности при каждом создании, переносе и отмене брони. Для мини-отеля это главный операционный экран, потому что именно здесь сходятся звонки, сообщения, собственный сайт и внешние площадки.

Сначала определите единицу продажи. В гостинице обычно продают номер целиком. В хостеле продают отдельное место, хотя несколько мест принадлежат одной комнате. В гостевом комплексе могут отдельно сдаваться дом, баня и отдельный домик, а уборка и ограничения у них разные. Если система умеет только «номер», администратор начнет изображать места фиктивными комнатами. После этого отчеты о загрузке, уборка и остатки перестают совпадать с реальностью.

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

Проведите тест, который продавцы программ не любят показывать:

1. Создайте бронь на номер с пятницы по воскресенье и отметьте частичную оплату.
2. Попробуйте продать тот же номер на субботу через другой источник.
3. Перенесите первую бронь на неделю вперед, затем отмените перенос.
4. Закройте номер на ремонт только на ночь с субботы на воскресенье.
5. Проверьте, что доступность, долг гостя и история вернулись в ожидаемое состояние.

Система должна запретить конфликт или запросить явное решение пользователя с достаточными правами. Молчаливое разрешение пересечения броней неприемлемо. Такое поведение иногда защищают словами «администратору виднее», но на практике оно превращает случайный двойной щелчок в переселение гостя за счет объекта.

Отдельно проверьте статусы. «Забронировано», «заехал», «выехал», «не заехал» и «отменено» должны иметь разный смысл для доступности, оплаты и отчетов. Свободный номер после выезда еще может быть грязным. Поэтому статус проживания и состояние уборки нельзя склеивать в одно поле.

Карточка брони должна оставлять проверяемую историю денег

Маленькому объекту не нужен банковский учет внутри PMS, но ему нужен точный ответ на три вопроса: сколько должен гость, сколько уже принято и на каком основании изменилась итоговая цена. Без этого касса, эквайринг и бухгалтерия будут показывать разные суммы.

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

Цена тоже требует истории. Если администратор изменил тариф после подтверждения брони, старая сумма не должна исчезать. Нужны причина или комментарий и видимый пересчет долга. Это защищает владельца и сотрудника: спор решается записью, а не памятью о телефонном разговоре.

Интеграция с онлайн-кассой полезна, но сама по себе не заменяет платежный учет. Касса отвечает за фискальный чек. PMS отвечает за состояние взаиморасчетов по брони. Если чек пробили вне системы, администратор должен привязать его или хотя бы записать номер и сумму операции, иначе в конце смены появятся «лишние» деньги без понятного гостя.

Попросите выгрузку за одну смену. В ней должны читаться начальный долг, начисления, оплаты, возвраты и конечный долг по каждой брони. Формат не обязан быть бухгалтерским произведением искусства. Достаточно таблицы, которую владелец может сопоставить с кассовым отчетом и выпиской эквайринга без ручного восстановления событий.

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

Реестр объекта и учет гостей нельзя смешивать

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

Постановление Правительства России № 1951 задает типы средств размещения и требования к ним. Постановление № 1952 описывает правила классификации и ведения реестра. Из этой пары следует практический вывод: PMS должна хранить точное наименование объекта, уникальный номер реестровой записи, тип и другие реквизиты там, откуда они без ручной правки попадают в документы и публикации. Но включение в реестр и самооценка проходят в предусмотренной государственной системе, а не внутри гостиничной программы.

Это различие часто стирают обещанием «есть классификация». Спросите поставщика, что именно делает функция. Если она показывает памятку и хранит номер, это полезно, но это не подача заявления. Если готовит набор данных, уточните, куда и кем он отправляется, какой результат возвращается и где сохраняется подтверждение. Название кнопки не заменяет юридически значимое действие.

В карточке гостя нужны сведения ровно из документа, а не свободный комментарий: фамилия, имя, отчество при наличии, дата рождения, гражданство, вид документа, серия и номер, кем и когда выдан. Для иностранца набор расширяется сведениями, которые требует миграционный учет. Программа должна проверять обязательные поля по гражданству и типу документа до заселения, а не сообщать об ошибке вечером после выезда.

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

Хранение данных в России, резервное копирование и выгрузка важны, но задавайте точные вопросы. Где физически находятся рабочая и резервная копии? Как часто создается резерв? Что попадет в выгрузку при уходе: гости, брони, оплаты, документы, история изменений? Ответ «данные можно скачать» без образца файла мало что значит.

Срок уведомления должен считаться по гражданству и календарю

Регистрационный контур обязан рассчитывать срок по данным гостя, а не ставить одинаковое напоминание всем. Для граждан России гостиница передает сведения в течение 24 часов после прибытия. Для иностранцев действует срок в один рабочий день, следующий за днем прибытия. Выходные и праздники поэтому меняют результат, и обычное прибавление 24 часов дает неверную дату хотя бы для одной группы.

Правила регистрации граждан России закреплены постановлением Правительства № 713. Миграционный учет иностранцев регулируют Федеральный закон № 109-ФЗ и постановление Правительства № 9. Я не советую прятать эти основания в справке, которую никто не открывает. На рабочем экране должны быть гражданство, расчетный срок, состояние отправки и подтверждение приема.

Рабочий процесс должен различать пять состояний: данные не заполнены, готовы к отправке, отправлены, приняты, отклонены. Статус «отправлено» не равен «принято». Если государственная система отклонила уведомление из-за ошибки в документе, задача остается открытой до исправления и получения подтверждения. Уведомление без результата создает ложное спокойствие.

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

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

Москва и Московская область требуют отдельного внимания из-за эксперимента по дополнительному учету выбытия. Если объект работает там, спросите поставщика прямо о поддержке уведомления о выезде и действующих сроков. Универсальная фраза «миграционный учет есть» ничего не говорит о региональном сценарии.

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

Туристический налог считается по услуге, а не на глаз

Для туристического налога системе нужны муниципальная ставка, налоговая база без самого налога и НДС, число суток, момент полного расчета и сведения о льготе. Процент от суммы брони в калькуляторе не годится, потому что закон требует сравнить расчетную сумму с минимальным налогом.

ФНС формулирует правило прямо: сумма равна процентной доле налоговой базы, но если результат меньше 100 рублей, умноженных на число суток проживания, применяется минимум. На 2026 год предельная ставка составляет 2 процента, однако конкретную ставку и дополнительные льготы устанавливает муниципалитет. Значит, справочник должен зависеть от места объекта и периода, а администратор должен видеть, какое правило применено.

Разберем бронь на две ночи стоимостью 6 000 рублей без НДС при муниципальной ставке 2 процента. Расчет по ставке дает 120 рублей. Минимум дает 100 × 2 = 200 рублей. К уплате идет 200 рублей. Если программа показывает только 120, она не выполняет обязательный минимум, как бы аккуратно ни выглядел отчет.

Для проверки попросите открыть расчет до итоговой суммы. Нормальная запись содержит:

• объект и муниципальное правило с периодом действия;
• стоимость услуги проживания без налога и НДС;
• ставку и расчетную сумму;
• число суток и минимальную сумму;
• выбранный итог и основание льготы, если она есть.

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

Еще одна частая ошибка появляется при нескольких гостях в одном номере. Минимум относится к услуге проживания и количеству суток, а не автоматически умножается на число фамилий в карточке. Модель данных должна понимать договор или услугу, иначе семейная бронь превращается в несколько налогов.

Декларация по форме КНД 1153008 подается ежеквартально не позднее 25-го числа месяца после квартала, налог платят не позднее 28-го. PMS не обязана заменять бухгалтерскую программу или личный кабинет ФНС. Она обязана выдать расшифровку, из которой бухгалтер воспроизведет сумму декларации без догадок: оказанные услуги по периодам, исключения, база, минимальный налог и итог.

Сверьте пробную выгрузку с опубликованной ФНС логикой строк декларации. Особенно посмотрите, отделяет ли система стоимость услуг, для которых сработал минимум, от остальной базы. Если отчет дает только общую сумму налога, ошибку будет трудно найти после закрытия квартала.

Продажи из разных каналов должны расходовать один остаток

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

Нужно четко различать модуль бронирования на собственном сайте и менеджер каналов. Первый принимает прямую бронь. Второй обменивается доступностью, ценами, ограничениями и бронированиями с внешними площадками. Один не заменяет другой. Продавцы объединяют эти понятия в слове «онлайн-продажи», а владелец обнаруживает разницу после первого овербукинга.

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

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

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

Проверьте также, кто владеет перепиской и контактами. Рабочие сообщения не должны жить только в личном телефоне владельца. История договоренностей о раннем заезде, детской кровати или возврате должна быть доступна смене и привязана к брони, но паспортные данные не следует копировать в общий чат.

Уборка и самостоятельный заезд нужны по факту процесса

Уборка становится обязательной функцией, когда состояние номера влияет на продажу или передачу смены. Даже при пяти комнатах отметка «выехал» не означает «готов». Система должна создать задачу, показать исполнителя, время и результат, а выпуск номера в продажу должен следовать правилам объекта.

Не нужно превращать это в приложение для управления клининговой компанией. Маленькому отелю достаточно списка задач на сегодня, статусов «назначено», «в работе», «готово», комментария о неисправности и возможности приложить подтверждение, если оно действительно используется. Складской учет каждого флакона и расчет нормы минут на полотенце обычно только отнимают время.

Самостоятельный заезд нужен не всем. Он оправдан, если гости регулярно приезжают ночью, администратора нет круглосуточно, а объект может законно и безопасно идентифицировать человека, принять данные и передать доступ. Код от двери без проверки документов не закрывает регистрационные обязанности. Функция должна связать подтвержденного гостя, конкретную бронь, период доступа и факт заселения.

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

Учет смен стоит вводить, если с деньгами и гостями работают несколько человек. Передача смены должна показывать незакрытые долги, ожидаемые приезды, просроченные уведомления, проблемы номеров и кассовое расхождение. Биометрический контроль рабочего времени и сложные графики можно оставить отдельной кадровой системе.

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

Функции большого отеля чаще мешают, чем помогают

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

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

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

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

Не покупайте «единый ERP» только ради будущего роста. Популярность этого совета понятна: никому не хочется менять систему через три года. Но цена ранней универсальности измеряется не лицензией, а обязательными полями, обучением и ошибками. Выбирайте систему, которая экспортирует данные и поддерживает ваш сегодняшний процесс; возможность уйти защищает рост лучше, чем сотни неиспользуемых экранов.

Исключение одно: юридическую обязанность нельзя отложить из-за малого размера. Регистрационный учет, корректный расчет налога, реквизиты объекта в документах и история операций нужны с первой брони, если правило распространяется на ваш объект. Число номеров не превращает просрочку в мелочь.

Выбор системы заканчивается пробной сменой и выгрузкой

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

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

Проверьте пять вещей до переноса рабочих данных:

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

Миграцию лучше считать законченной не после загрузки таблицы, а после сверки контрольных сумм. Посчитайте будущие брони по датам, занятые номера, общий остаток предоплат и число карточек гостей до и после переноса. Затем откройте несколько сложных броней вручную. Одинаковое количество строк еще не означает, что оплаты и гости привязались к правильным проживаниям.

Для объекта из целевой группы Плацкарт закрывает этот контур в одной бесплатной системе: шахматку, брони, реестр гостей, уведомления МВД со сроком по гражданству, туристический налог, каналы, уборку, сообщения и экспорт в Excel. Это один из вариантов, а критерий остается прежним: ваша смена должна пройти без параллельной тетради и без данных, которые потом приходится собирать заново.

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