Сайты

Travel-сайт: бронирование, цены и отмены

Динамические цены, доступность, интеграции с системами бронирования, часовые пояса и валюты, правила отмены — что определяет работу travel-сайта.

20 августа 2026

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

Цена и доступность — величины, а не свойства

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

Практические следствия, которые надо учесть в проекте:

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

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

Интеграции с системами бронирования

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

Здесь нужно определиться с моделью:

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

Независимо от модели, есть вещи, которые надо спроектировать явно:

Что происходит при недоступности внешней системы. Бронирование не должно молча пропадать. Либо оно блокируется с честным сообщением, либо принимается как запрос с последующим подтверждением.
Гонка за последним номером. Два человека одновременно бронируют последний свободный. Нужно временное удержание на время оформления и внятное поведение, если удержание не удалось.
Подтверждение. Мгновенное или по запросу. Если бронь подтверждается человеком, клиент должен понимать это до оплаты, а не после.
Изменение брони. Кто может менять даты и состав гостей, до какого момента, что при этом происходит с ценой.

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

Часовые пояса и валюты

Две области, где ошибки выглядят особенно неприятно, потому что бьют по деньгам и по расписанию.

Время

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

Что ещё обычно упускают:

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

Деньги

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

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

Правила отмены

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

Что описывается в правиле:

До какого момента отмена бесплатна — с явным указанием часового пояса.
Что удерживается при отмене позже: фиксированная сумма, стоимость первой ночи, весь платёж.
Что происходит при незаезде — обычно отдельный, более жёсткий случай.
Возможна ли частичная отмена, если бронь на несколько номеров или услуг.
Как считается возврат при изменении, а не отмене.

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

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

Что показать до оплаты

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

На нём должны быть:

Объект, тип размещения и выбранный тариф.
Даты и время заезда и выезда с указанием местного времени.
Количество гостей и состав, если это влияет на цену.
Полный расчёт: базовая стоимость, доплаты, сборы, налоги, итог одной строкой.
Валюта списания и сумма в ней, если она отличается от валюты отображения.
Условия отмены текстом с конкретной датой и временем дедлайна, а не ссылкой на общие правила.
Что оплачивается сейчас и что на месте.
Способ подтверждения — сразу или после проверки — и срок ответа.
Что нужно взять с собой или предъявить при заселении, если есть требования.

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

Чеклист перед запуском

Прежде чем начинать travel-проект, стоит письменно закрыть следующее:

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

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