Модуль бронирования на сайте небольшого отеля

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

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

Сначала определите, что сайт обещает гостю

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

Постановление Правительства РФ № 1912, действующее с 1 марта 2026 года для гостиниц и других классифицируемых средств размещения, проводит эту границу довольно ясно. Исполнитель сам устанавливает форму и порядок заявки, но договор считается заключенным, когда заказчик получает уведомление о подтверждении бронирования. В уведомлении должны быть данные исполнителя и заказчика, сведения о заказанном номере, цена, сроки проживания и условия бронирования. Подтверждение здесь не декоративное письмо после формы, а юридически значимый момент.

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

До выбора модуля запишите одно предложение для каждого исхода:

• «Бронь подтверждена» означает, что остаток уменьшен и гостю отправлены все условия.
• «Заявка принята» означает, что место еще не закреплено и указан срок ответа администратора.
• «Оплата не прошла» означает, что временное удержание действует до конкретного времени или уже снято.
• «Бронь отменена» означает, что остаток возвращен в продажу и гостю отправлено уведомление.

Если поставщик не может показать, где именно система меняет эти состояния, перед вами витрина с формой, а не модуль бронирования.

Остаток должен жить в одном месте

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

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

Минимальная формула доступности выглядит так:

доступно = вместимость
          - подтвержденные брони
          - активные временные удержания
          - закрытые владельцем места
          + освобожденные отмены

Вместимость надо считать для каждой ночи, а не только на дату заезда. Бронь с 10 по 13 августа занимает ночи 10, 11 и 12 августа; 13 августа ресурс снова доступен, если время выезда и уборка позволяют следующий заезд. Ошибка на границе дат дает самые неприятные двойные продажи: оба гостя показывают правильное подтверждение.

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

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

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

Модуль обязан считать одну окончательную цену из дат, состава гостей, тарифа и обязательных доплат. Фраза «от 2500 рублей», после которой администратор вручную называет 3900, не помогает прямым продажам. Гость уже сравнил предложение и воспринимает новую сумму как смену условий.

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

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

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

Показывайте раскладку по ночам до отправки заявки. Для брони на три ночи недостаточно строки «Итого 12 600 ₽». Нужны цены каждой ночи, включенные услуги, доплаты и размер предоплаты. При смене сезона внутри проживания гость сразу увидит, почему ночи стоят по-разному.

Туристический налог не стоит смешивать с ценовой скидкой или комиссией канала. Он считается по правилам главы 33.1 НК РФ: по каждой ночи сравнивают сумму по муниципальной ставке от стоимости размещения без НДС и минимальный налог 100 рублей, затем берут большую величину. Ставку задает муниципалитет, возможны льготы. Модуль может посчитать налог после получения нужных данных, но интерфейс должен заранее сказать, включен ли он в показанную сумму и при каких условиях итог уточнится.

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

Удержание спасает от двойной продажи во время оформления

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

Рабочая последовательность выглядит так:

1. Гость выбирает даты, состав и тариф, система заново проверяет доступность.
2. Система создает удержание на конкретные ночи и показывает время, до которого надо завершить оформление.
3. Гость вводит контакты и, если требуется, переходит к оплате.
4. Успех превращает то же удержание в бронь, а отказ или истечение срока освобождает ресурс.
5. Только после записи брони система отправляет подтверждение и обновляет внешние каналы.

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

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

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

Подтверждение должно содержать весь договор

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

Минимальный состав подтверждения для сайта выглядит так:

{
  "booking_id": "D-2026-0814-037",
  "status": "confirmed",
  "property": "Название и данные исполнителя",
  "registry_number": "уникальный номер записи",
  "guest": "Имя заказчика",
  "stay": {"check_in": "2026-08-14", "check_out": "2026-08-17"},
  "room": "Двухместный стандарт",
  "price": {"total": 12600, "paid": 3000, "currency": "RUB"},
  "terms": "Время заезда и выезда, состав услуг, отмена и возврат"
}

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

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

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

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

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

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

Статусы лучше разделить прямо:

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

При интернет-расчетах обязанность по кассовому чеку не исчезает. ФНС напоминает, что пункт 2 статьи 1.2 закона № 54-ФЗ делает выдачу чека обязанностью продавца; даже отсутствие интернета само по себе не освобождает от нее. Поэтому в приемке проследите цепочку от платежа до кассы и доставки электронного чека. Банковская квитанция и кассовый чек решают разные задачи.

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

Способ установки зависит от устройства сайта

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

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

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

До установки подготовьте данные, без которых даже готовый виджет останется пустым:

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

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

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

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

Форма должна просить только нужные данные

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

Форма бронирования обрабатывает персональные данные, поэтому до запуска надо определить оператора, цели, состав данных, сроки хранения и тех, кому сведения передаются. На сайте размещают политику обработки, а для согласия используют отдельное, понятное действие там, где согласие служит основанием обработки. С 1 сентября 2025 года статья 9 закона № 152-ФЗ требует оформлять согласие отдельно от других документов, которые человек подтверждает или подписывает. Галочка под длинным смешанным текстом про бронь, рассылку и передачу всем партнерам не годится.

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

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

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

Общий пул требует правил для всех каналов

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

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

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

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

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

Сбой должен оставлять понятный след

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

Разберите типовую аварию. Гость выбрал последний номер, система создала удержание, банк подтвердил оплату, но ответ сайта оборвался. Гость обновил страницу и повторил кнопку. Без защиты система может создать две брони или два платежа; без журнала администратор увидит лишь сердитый звонок и непонятную сумму.

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

{
  "request_id": "web-4f91c2",
  "result": "already_processed",
  "booking_id": "D-2026-0814-037",
  "inventory_changed": false
}

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

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

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

Приемка начинается с полного пути гостя

Перед запуском надо пройти модуль как гость и как администратор, а затем сверить остаток во всех каналах. Проверка по принципу «форма отправилась» пропускает цену, договор, оплату, возврат места и ошибки синхронизации.

Возьмите отдельный тестовый тариф и выполните пять проходов:

1. Успешная бронь последнего номера без оплаты: проверьте остаток, карточку брони и подтверждение.
2. Успешная бронь с оплатой: сверьте сумму банка, статус, кассовый чек и одну запись брони.
3. Брошенное оформление: дождитесь окончания удержания и убедитесь, что номер вернулся на сайт.
4. Отмена и перенос: проверьте условия возврата, уведомление гостю и освобождение правильных ночей.
5. Сбой канала: временно создайте ситуацию недоставки и найдите предупреждение, повтор и запись в журнале.

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

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

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