Единый пул номеров для всех каналов

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

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

Один пул хранит физический остаток, а не сумму витрин

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

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

Пул обычно ведут на уровне категории: «Стандарт двухместный», «Семейный», «Койко-место в женском номере». Для каждой даты хранится свое число. Бронь с 14 по 17 июля занимает ночи 14, 15 и 16 июля, а 17 июля номер снова можно продать после расчетного времени выезда и уборки. Ошибка в границах проживания даст неверный остаток даже при исправной передаче данных.

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

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

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

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

Разберем небольшой журнал. В гостевом доме четыре одинаковых стандарта. Один уже занят старой бронью с 12 по 15 августа, поэтому исходный остаток на ночи 12, 13 и 14 августа равен трем. Новый гость покупает на площадке проживание с 13 по 15 августа.

• До новой продажи: остатки 3, 3, 3 и 4 на ночи 12, 13, 14 и 15 августа.
• После брони с 13 по 15 августа: остатки 3, 2, 2 и 4.
• После еще двух броней на ночь 14 августа: остатки 3, 2, 0 и 4.

Нулевая доступность 14 августа должна закрыть любой заезд или проживание, которое требует эту ночь. При этом 12, 13 и 15 августа живут своей жизнью. Нельзя закрывать всю неделю только потому, что одна дата заполнена, и нельзя оставлять длинное проживание доступным, если внутри него есть ночь с нулем.

TravelLine в описании TL: Channel Manager формулирует механику прямо: когда бронь приходит из одного канала, доступность снижается на других площадках; бронь с официального сайта делает то же самое. Bnovo пишет, что менеджер каналов отправляет площадкам количество свободных номеров, цены и ограничения, а в ответ получает бронирования. Эти описания полезны ровно до слова «автоматически». Они подтверждают направление обмена, но администратору все равно нужно проверить сопоставление категорий, источник ручных броней и журнал доставки.

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

Категория продается раньше конкретной комнаты

Онлайн-каналы обычно продают категорию, а не дверь с табличкой «№ 5». Гость покупает право разместиться в подходящем стандарте на выбранные даты. Конкретную комнату администратор назначает в шахматке сразу или ближе к заезду. Этот разрыв дает гостинице свободу переселять бронь внутри равнозначной категории, но требует точного учета вместимости.

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

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

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

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

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

Сайт входит в тот же пул на равных

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

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

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

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

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

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

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

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

Раздельные квоты ломаются в момент спроса

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

Типичный сбой проходит без экзотики. В 21:40 гость звонит и просит последний семейный номер. Администратор записывает фамилию на листок, потому что находится не у компьютера. В 21:47 площадка подтверждает бронь того же номера. В 22:05 администратор открывает два экстранета, закрывает продажи в первом, но забывает второй. Утром обе брони выглядят настоящими, у обеих есть подтверждение, а физический номер один.

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

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

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

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

Один пул снижает риск, но не отменяет задержки

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

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

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

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

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

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

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

Сопоставление определяет, какой остаток уйдет наружу

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

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

Рабочая проверка сопоставления помещается на одном листе:

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

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

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

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

Отмена возвращает номер только после проверки условий

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

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

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

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

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

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

Переход начинают с полной инвентаризации

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

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

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

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

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

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