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

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

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

Просите показать маршрут, а не список функций

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

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

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

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

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

Правовой статус данных должен быть записан в договоре

Владелец объекта не перестает отвечать за данные гостей после передачи их облачному сервису. Часть 3 статьи 6 Федерального закона № 152-ФЗ требует, чтобы поручение на обработку определяло перечень персональных данных, действия с ними, цели обработки, конфиденциальность, меры безопасности и порядок сообщения об инциденте. Устного ответа «у нас все по 152-ФЗ» для этого мало.

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

Письменный ответ должен закрывать как минимум такие вопросы:

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

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

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

Экспорт проверяют до импорта

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

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

booking_id;created_at;updated_at;status;arrival;departure;room_id;guest_id;source;gross_amount;paid_amount;refund_amount;tax_amount

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

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

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

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

Лимиты прячутся не только в количестве номеров

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

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

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

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

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

Будущий модуль пока не решает задачу

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

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

Изменения обязательных форм хорошо выявляют зрелость процесса. ФНС России приказом от 19 декабря 2025 года № ЕД-7-3/1228@ изменила декларацию по туристическому налогу КНД 1153008, и новая редакция применяется начиная с отчетности за первый квартал 2026 года. Спросите, кто отслеживает такие изменения, когда обновляет форму, как уведомляет клиента и что происходит с уже закрытым периодом. Ответ должен описывать процесс выпуска и исправления, а не личную уверенность менеджера.

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

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

Интеграция обязана пережить сбой

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

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

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

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

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

Поддержку измеряют временем восстановления

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

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

Юридический срок не переносится из-за очереди поддержки. Уведомление о прибытии гражданина России гостиница подает в течение 24 часов, для иностранца действует срок в один рабочий день. На длинных выходных это разные режимы. Система должна считать нужный срок и показывать незавершенные действия, а поддержка должна понимать, почему ошибка в таком модуле серьезнее косметического дефекта.

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

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

Перенос заканчивается приемкой, а не загрузкой файла

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

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

Приемочный протокол можно уместить на одной странице:

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

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

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

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

Доступ сотрудников должен оставлять след

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

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

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

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

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

Аккаунт должен принадлежать бизнесу, а не сотруднику

Главную учетную запись оформляют на владельца объекта или контролируемый им служебный адрес. Личный телефон администратора и его почта удобны в день запуска, но превращаются в препятствие при увольнении, болезни или споре. До импорта проверьте, кто может восстановить доступ, сменить владельца аккаунта и подтвердить полномочия без участия прежнего сотрудника.

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

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

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

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

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

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

Уход из системы проектируют до входа

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

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

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

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

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