RFP · таблица соответствий · создание/изменение/отмена · оплата · аналитика

Модуль бронирования: сравнивайте не функции, а полный цикл

Владимир Селиванов · создатель HotGrade

Практический опыт создания и управления гостиничными объектами полного цикла — от концепции и проектного сопровождения до запуска и управления
Управляет собственным капиталом и капиталом 100+ частных инвесторов

Автор публично: t.me · tenchat.ru · youtube.com

Один и тот же список обещаний можно показать на демо. Различия становятся видны на вашем номерном фонде: последний номер, изменение дат, отказ оплаты, повтор сообщения, отмена и сверка.

Собрать RFP →Сценарии приёмки

Короткий ответ: сначала архитектура, затем демонстрация

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

Источники сверены 12 августа 2026 года

Один источник остатка

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

Таблица соответствий и правило конфликта фиксируются до интеграции.

Один полный цикл

Создание → изменение → отмена, успех → отказ → повтор, сумма → возврат → сверка.

Презентация возможности не закрывает фактический тест.

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

01Остаток и тарифОдин источник доступности и правила продаж
02МодульПоиск, данные гостя, сумма и подтверждение
03ОплатаУспех, отказ, возврат и повтор без дубля
04PMSСоздание, изменение, отмена и возврат квоты
05АналитикаИсточник, заказ, сумма, валюта и окно сверки

STOP: если неизвестно, кто управляет доступностью, или создание/изменение/отмену нельзя проследить по идентификаторам, запуск создаёт риск двойного остатка и несверяемых статусов.

Технический путь есть не у всего рынка — и сам по себе ничего не гарантирует

Собственный корпус HotGrade отделяет найденный путь бронирования от его конверсии и работоспособности.

Публичные агрегаты · сайты на 30.07.2026

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

37 670публичных записей в исследовательском корпусе

18 442собственных сайтов подтверждены и успешно просканированы

12 871объектов с найденной формой, виджетом или модулем

9 359сайтов с распознанным специализированным модулем бронирования

12 871 — это 69,8% только от 18 442 успешно просканированных собственных сайтов. Это не доля прямых броней, выручки или конверсии. Найденный модуль не доказывает, что он работает сейчас, корректно синхронизирует остаток или подходит вашему объекту. Методика и региональные базы расчёта — в исследовании прямого бронирования.

RFP и протокол приёмки

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

Локально · CSV + Markdown

Один RFP и один протокол приёмки для всех финалистов

Выберите только профиль объекта и статусы тестов. Названия поставщиков, гостей, сотрудников и бронирований не нужны.

Только в этой вкладке

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

1. Зафиксируйте профиль решения

Неизвестное не исключает требование и не превращается в «не нужно»: сначала определите архитектуру и владельца данных.

Размер номерного фондаНужен для сценария нагрузки, а не для оценки класса объекта.Собственный сайтТочная площадка установки и домен перехода должны быть известны до интеграции.PMS — источник фондаМодуль не должен создавать второй несверяемый остаток номеров.Онлайн-оплатаОт этого зависит полный сценарий успеха, отказа, возврата и сверки.Корпоративные тарифыЗакрытые условия не должны случайно попасть в публичную выдачу.Дополнительные услугиТрансфер, питание и пакеты требуют отдельного жизненного цикла заказа.Несколько объектовНужны изоляция данных, роли и явный контекст выбранного объекта.Несколько языковПроверяются не только переводы, но и тарифы, письма и формат сумм.

Активных проверок13

Пройдено на тесте0

Материал без теста0

Расхождений0

Текущий рубежПрофиль решения ещё не определён

Не определено полей профиля: 8. Открыто критических проверок: 7. Не сравнивайте цену до одинакового прохода ключевых сценариев.

2. Проведите приёмку по одинаковым сценариям

Состав меняется только по профилю. «Не проверено» и «материал получен» остаются открытыми.

01
Архитектура · критическая проверкаНазначить единственный источник доступности
Где живут номера, тарифы, ограничения и остатки — и какая система имеет право их менять?
Доказательство: Схема систем, владелец каждого поля и подписанное правило конфликта.
Статус
02
Архитектура · критическая проверкаСверить карту номеров, тарифов и ограничений
Совпадают ли категории, вместимость, питание, условия, квоты и stop-sale на всех сторонах?
Доказательство: Версионированная mapping-таблица и тест по каждой активной категории.
Статус
03
Путь гостяПройти поиск доступности
Показывает ли модуль только доступный фонд с понятной полной суммой и условиями до ввода данных?
Доказательство: Запись прохода на смартфоне и компьютере для трёх наборов дат.
Статус
04
Путь гостяПроверить тарифные правила
Как ведут себя минимальный срок, закрытие заезда, промокод, питание и разные условия отмены?
Доказательство: Матрица тариф × дата × ожидаемая сумма × ожидаемое условие.
Статус
05
Путь гостя · критическая проверкаПроверить последний номер и параллельный запрос
Не подтверждаются ли две брони на один остаток при одновременном завершении?
Доказательство: Два параллельных теста, журнал событий и итоговый остаток.
Статус
06
Жизненный цикл · критическая проверкаСверить новое бронирование и подтверждение
Совпадают ли код, даты, состав, сумма и статус в модуле, письме и системе учёта?
Доказательство: Одна тестовая бронь и трёхсторонняя сверка.
Статус
07
Жизненный цикл · критическая проверкаПройти изменение и отмену
Доходят ли смена дат, состава и отмена ровно один раз и в правильном статусе?
Доказательство: Цикл new → change → cancel с временными метками.
Статус
08
Жизненный цикл · критическая проверкаСмоделировать обрыв и повтор
Что увидит гость, если подтверждение задержалось, интеграция недоступна или страница обновлена?
Доказательство: Протокол ошибки, retry без дубля и ручной маршрут сверки.
Статус
09
ИзмерениеЗафиксировать этапы воронки
Различимы ли поиск, выбор, старт оформления, подтверждение, сумма и валюта заказа?
Доказательство: Тестовый заказ в отчёте электронной коммерции или эквивалентном журнале.
Статус
10
ИзмерениеСохранить источник до подтверждения
Не теряются ли UTM и источник при iframe, редиректе, поддомене или переходе на оплату?
Доказательство: Один тест на каждый переход домена и совпадение источника в подтверждённой брони.
Статус
11
КачествоПроверить mobile, клавиатуру и ошибки полей
Можно ли завершить сценарий на узком экране и без мыши, понять ошибку и вернуться к нужному полю?
Доказательство: Чек-лист 390 px, клавиатурный проход и читаемые сообщения.
Статус
12
ДанныеУтвердить состав и срок хранения данных
Какие поля нужны модулю, PMS, оплате и аналитике; кто экспортирует и удаляет данные при выходе?
Доказательство: Карта полей и ролей, правила экспорта, удаления и прекращения договора.
Статус
13
Запуск · критическая проверкаЗафиксировать запуск, мониторинг и откат
Кто смотрит ошибки и остатки в первые дни, какой порог включает остановку и как вернуть прошлый путь?
Доказательство: Runbook запуска, контакты ролей без публичной выгрузки и проверенный rollback.
Статус

Передайте поставщикам один набор требований

CSV — сравнимый RFP; Markdown — протокол решения и приёмки. Оба файла формируются локально и не содержат свободного текста.

Скачать RFP CSV Скачать протокол

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

Восемь сценариев, которые раскрывают скрытые различия

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

Не перечень функций из презентации

Сценарий	Что сломать или изменить	Что должно сойтись	STOP
Последний номер	Два параллельных подтверждения на один остаток	Одна бронь, один остаток, объяснимый отказ второй	Подтверждены обе
Изменение дат	Перенести заезд и число ночей	Сумма, доступность, письмо и PMS	Старая квота не вернулась
Отмена	Отменить бронь с заданным правилом	Статус, остаток, сумма и гостевое уведомление	Системы расходятся
Отказ оплаты	Неуспешный платёж и повтор	Нет ложной оплаты и двойного заказа	Бронь и платёж в разных состояниях
Повтор сообщения	Доставить одно событие дважды	Один бизнес-результат по одному идентификатору	Появился дубль
Потеря связи	Оборвать интеграцию после отправки	Понятный статус, повторная доставка и очередь сверки	«Зависшая» бронь без владельца
Источник визита	Пройти iframe, поддомен и оплату	Подтверждённый заказ связан с исходным источником	Атрибуция теряется
Мобильный путь	390 px, клавиатура, ошибка поля	Фокус, текст ошибки, сумма и завершение	Нельзя исправить или закончить

Не смешивайте четыре разных решения

Слой	Главная задача	Что проверять на стыке	Отдельный материал
Сайт отеля	Предложение, контент и вход в путь	Скорость, мобильный путь, домен и сохранение источника	Маркетинговая воронка
Модуль бронирования	Поиск → подтверждение	Тарифы, статусы, сумма, оплата и аналитика	Этот RFP
PMS	Фонд и операционный учёт	Таблица соответствий и создание/изменение/отмена	PMS и перенос данных
Менеджер каналов	Внешние каналы и квоты	Остатки, ограничения и последний номер	Комиссии и условия OTA

Аналитика должна заканчиваться заказом, а не кликом

Вендоры описывают тарифы, оплату, допуслуги и интеграции; независимая задача владельца — проверить, что результат измерим и сверяем.

Официальная документация Метрики

Электронная коммерция. Метрика принимает события заказа через согласованный dataLayer-контур и предлагает отдельно проверить настройку; это основание для теста, а не доказательство корректной установки.
Целевые события. reachGoal передаёт достижение отдельно созданной цели; разные события должны иметь разные идентификаторы.
Сверка. Заказ в аналитике должен сходиться с подтверждённой бронью по сумме, валюте и окну, но публичный RFP не хранит код брони или гостевые данные.

Частые вопросы

Чем модуль бронирования отличается от PMS?

Модуль ведёт гостя от поиска дат до подтверждения и может передать бронь в PMS. PMS управляет номерным фондом и операционным учётом. Даже если один поставщик продаёт оба продукта, в RFP нужно отдельно назвать источник доступности, владельца тарифов и цикл обмена.

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

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

Как выбрать модуль бронирования для гостиницы?

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

Какие интеграции нужно проверить?

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

Что измерять в Яндекс Метрике?

Разделяйте поиск, выбор, начало оформления и подтверждение; для заказа передавайте сумму и валюту через согласованный контур электронной коммерции или эквивалентный журнал. Отдельно проверьте, что источник и UTM не теряются на iframe, поддомене, редиректе или оплате.

Отправляет ли RFP данные в HotGrade?

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

Источники и границы

Источники сверены 12 августа 2026 года. Страницы TravelLine и Bnovo используются как первичные описания возможностей самих продуктов, а не как независимое доказательство результата или рекомендация бренда. HotGrade не ранжирует поставщиков и не получает вознаграждение за выбор. RFP не заменяет договор, проверку обработки данных, технический проект или приёмку специалистами объекта.

Проверьте свой отель как бизнес — бесплатно

Формулы из гайдов — общие. Ваш объект уже может быть в базе HotGrade (десятки тысяч объектов по РФ): найдите его и откройте расширенный отчёт — бесплатно, после регистрации.

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

Найти свой отель →Проверить объект перед сделкой →

Источник и дата под каждым числом. «Не найдено» ≠ нарушение. Позиции и оценки не продаются.