1. Остановите дальнейшие повторные попытки и убедитесь, что обе записи в системе управления отелем (PMS) относятся к одному и тому же бронированию OTA.
2. Сохраните запись, связанную с действительным ID источника OTA и будущими сообщениями об изменениях или отмене.
3. Обезопасьте доступность номеров, платежи, счета, сообщения гостей и операционные задачи перед удалением лишней записи.
4. Убедитесь, что доступность изменяется ровно один раз, и задокументируйте исправление для службы поддержки и ночного аудита.
Дублирование бронирования OTA после повторной попытки может показаться простым для исправления: найти две похожие записи и удалить одну. Это рискованно. Одна запись может быть связанным бронированием, которое будет получать будущие изменения от OTA, в то время как другая может содержать распределение номеров, платежи, заметки или данные о заезде, уже завершенные на стойке регистрации.
Безопасным решением будет приостановить автоматизацию, доказать, что записи являются дубликатами, выбрать одно основное (каноническое) бронирование, переместить или сохранить операционные данные, а затем удалить лишнюю запись, используя одобренное действие в системе управления отелем. Проверки номерного фонда и платежей должны следовать незамедлительно, поскольку удаление записи может освободить номер или изменить баланс.
Почему повторная попытка OTA может создать дублирующееся бронирование
Повторная попытка обычно должна повторно использовать внешний ID бронирования OTA, чтобы система управления отелем распознала то же самое бронирование. Дубликат может появиться, если первоначальный импорт частично удался, но вернул ошибку, повторная попытка поступает без того же идентификатора, или если была создана ручная временная запись до того, как задержанное автоматическое бронирование попало в систему управления отелем.
Другая распространенная ситуация начинается с вручную импортированного будущего бронирования. Если ручная запись не содержит действительного исходного ID бронирования, последующее изменение от OTA может не совпасть с ней. Система управления отелем может создать новую связанную запись вместо обновления существующей ручной.
Две записи в системе управления отелем могут выглядеть одинаково, но вести себя по-разному. Только одна из них может оставаться связанной с изменениями OTA, отменами, сообщениями гостей, платежными инструкциями или данными виртуальной карты. Вот почему имени гостя и дат проживания недостаточно, чтобы решить, какую запись следует удалить.
Остановите повторные импорты, повторные отправки и ручные изменения доступности, как только будет найден дубликат. Зафиксируйте оба номера бронирования, время создания, исходные ID, текущие статусы и влияние на номерной фонд до того, как другое сообщение изменит данные.
Докажите, что две записи действительно являются дубликатами
Два бронирования на одного и того же гостя и на те же даты — это лишь подозрение на дубликаты. Гость может намеренно забронировать два номера, или два путешественника с одинаковыми фамилиями могут приехать вместе. Разные номера подтверждения OTA обычно означают два отдельных бронирования, пока OTA не докажет обратное.
Сравните обе записи поле за полем:
- Номер подтверждения OTA и ссылка в менеджере каналов (Channel Manager) или CRS
- Номер бронирования в системе управления отелем, время создания, метод импорта и источник
- Объект размещения, категория номера, заезд, выезд, количество гостей и тарифный план
- Общая стоимость, налоги, модель оплаты, депозит и правила отмены
- Последнее изменение, отмена, сообщение и статус синхронизации
- Распределение номеров, счет гостя, заметки, задачи и действия по заезду
Откройте экстранет OTA и подтвердите, сколько активных бронирований существует. Затем проверьте очередь в менеджере каналов или CRS. Если OTA и посредник показывают одно бронирование, а система управления отелем показывает две записи с одной и той же внешней ссылкой, эти записи в PMS являются явными кандидатами на дубликаты.
Если записи имеют разные номера подтверждения OTA, остановитесь. Не объединяйте, не отменяйте и не удаляйте ни одну из них, пока OTA или гость не подтвердят, планировались ли оба бронирования. Затраты на кратковременное удержание номера обычно ниже, чем отмена действительного бронирования.
Связанный рабочий процесс упрощает это сравнение. channel manager для отеля от Smart Order связывает входящую ссылку OTA с доступностью в системе управления отелем, чтобы персонал мог отследить, обновила ли повторная попытка существующее бронирование или создала другую операционную запись.
Отслеживайте бронирования OTA по их исходным ID
Храните входящие бронирования, сопоставленный номерной фонд и внешние ссылки в одном рабочем процессе, чтобы ошибки повторных попыток можно было выявить до того, как они повлияют на гостя или количество свободных номеров.
Выберите основную запись и безопасно устраните дубликат
Основное (каноническое) бронирование — это запись, которую гостиница сохранит в качестве единственного источника информации о проживании. Оно должно быть способно получать будущие изменения от OTA и сохранять операционную и финансовую историю, необходимую до выезда гостя.
Используйте матрицу ниже в качестве вспомогательного инструмента для принятия решений. Поведение поставщиков отличается, поэтому перед объединением, удалением, аннулированием или отменой записи может по-прежнему требоваться одобрение руководителя или службы поддержки.
Во многих инцидентах с повторными попытками автоматическая запись с действительным исходным ID OTA является более безопасной основной записью, поскольку последующие изменения и отмены могут совпасть с ней. Ручная временная запись без этого исходного ID часто является той записью, которую следует удалить, но только после того, как ее полезные данные будут сохранены.
Следуйте этой последовательности:
- Заморозьте дополнительные повторные попытки, редактирования, действия по заезду и попытки оплаты для обеих записей.
- Выберите основную запись на основе действительной ссылки на источник и пути будущих обновлений.
- Сохраните или перенесите распределение номеров, заметки о гостях, задачи, позиции счета, депозиты и ссылки на авторизованные платежи.
- Отметьте лишнюю запись как дубликат, используя одобренное в системе управления отелем действие (статус, объединение, аннулирование, отмена или удаление).
- Добавьте перекрестную ссылку в обе записи, если система сохраняет историю дубликатов.
- Снова откройте OTA, менеджер каналов и систему управления отелем, чтобы убедиться, что осталось только одно активное операционное бронирование.
Не отменяйте бронирование OTA только ради очистки системы управления отелем. Не удаляйте запись, которая содержит проведенный доход, авторизацию платежа, статус заехавшего гостя, доступ к номеру или фискальные документы, без проверки со стороны финансового отдела и руководства. Некоторым системам требуется помощь службы поддержки для безопасного объединения, поскольку видимое бронирование связано со скрытыми записями транзакций и сообщений.
Сверка номерного фонда, платежей и работы стойки регистрации
Удаление дубликата не завершено, пока операционные итоги гостиницы не станут верными. Если обе записи уменьшили доступность, удаление одной может вернуть номер в продажу. Если только одна уменьшила доступность, ручное увеличение номерного фонда может открыть лишний номер для продажи и привести к овербукингу.
Зафиксируйте доступность до исправления, выполните утвержденное действие с дубликатом, а затем сравните количество номеров в системе управления отелем с менеджером каналов и OTA. Итоговое количество должно отражать одно подтвержденное проживание — не ноль и не два.
Отдельно проверьте платежи и действия со счетом. Подтвердите, содержит ли какая-либо из записей депозит, предварительную авторизацию, списание, возврат, баланс, подлежащий взысканию с OTA, инструкции по виртуальной карте, налоговый счет-фактуру или базу для комиссии. Никогда не копируйте полные данные карты или данные безопасности в обычную заметку о бронировании или электронное письмо в службу поддержки.
Также сверьте работу, уже инициированную каждой записью. Проверьте сообщения гостей, автоматизацию перед заездом, распределение номеров, заметки по обслуживанию номеров, трансфер из аэропорта, запросы на питание, коды доступа и формы для заезда. Подавите дублирующийся рабочий процесс, чтобы гость не получил два подтверждения, два запроса на оплату или противоречивые инструкции.
Перед ночным аудитом выполните повторный поиск по имени гостя и всем внешним ссылкам. Подтвердите одно активное проживание, одно распределение номеров, один операционный баланс и правильную атрибуцию канала. Сохраните журнал аудита, показывающий, какая запись была сохранена и почему.
Эскалация инцидента и предотвращение новых дубликатов при повторных попытках
Передавайте инцидент на более высокий уровень (эскалируйте), когда команда не может определить связанную запись, когда обе записи содержат транзакции или когда отмена одной записи неожиданно меняет номерной фонд. Поставщику системы управления отелем или провайдеру связи может потребоваться проверить ID сообщений, подтверждения доставки, журналы импорта и поведение при повторных попытках.
Отправьте в службу поддержки:
- ID объекта размещения и провайдера подключения
- OTA, менеджер каналов и обе ссылки на бронирования в системе управления отелем
- Временные метки первоначального импорта, ошибки, повторной попытки и создания дубликата с указанием часового пояса
- Текущие статусы, сопоставление номеров и тарифов, а также доступность до и после
- Скриншоты сообщений и ошибок со скрытыми конфиденциальными платежными данными
- Уже предпринятые действия, включая платежи, заезд, распределение номеров или отмену
Окончательное решение зависит от причины. Отсутствующий ID внешнего источника требует лучшего сохранения ID. Тайм-аут после успешного импорта требует проверки статуса перед повторной попыткой. Ручная временная запись требует отметки для сверки. Дефект параллелизма или повторяющийся веб-хук требует защиты от дубликатов на стороне поставщика, а не очередного обходного пути для стойки регистрации.
Внедрите правило в процедуру работы с инцидентами в гостинице: никаких повторных попыток до тех пор, пока персонал не подтвердит, создало ли первое сообщение бронирование. Тестируйте новые подключения OTA с помощью нового бронирования, изменения и отмены. Изменение должно обновить ту же запись в системе управления отелем, а отмена должна вернуть номер в продажу ровно один раз.
Очистка дубликатов безопаснее, когда администраторы на стойке регистрации могут видеть источник бронирования, операционный статус и доступность номеров вместе. программа для рецепшн от Smart Order предоставляет персоналу единый календарь для связанного бронирования и его влияния на номерной фонд, снижая вероятность того, что временная запись станет вторым активным проживанием.
Сделайте исключения при повторных попытках видимыми для стойки регистрации
Свяжите ссылки на источники OTA с календарем системы управления отелем, чтобы персонал мог изолировать дубликат, защитить основное бронирование и проверить номерной фонд до ночного аудита.
Часто задаваемые вопросы
Какое дублирующееся бронирование OTA должна сохранить гостиница?
Обычно сохраняют запись с действительным исходным ID OTA и активной ссылкой на изменение или отмену. Прежде чем удалить другую запись, сохраните любые платежи, счета, распределение номеров, заметки, задачи и данные о заезде, которые она содержит.
Может ли стойка регистрации просто удалить более новое бронирование?
Нет. Более новая запись может быть автоматическим, связанным бронированием, созданным в результате восстановленного импорта. Ее удаление может нарушить будущие обновления от OTA, оставив после себя несвязанную ручную запись.
Должна ли гостиница отменить одно бронирование в экстранете OTA?
Нет, если OTA показывает только одно подтвержденное бронирование. Дубликат может существовать только внутри системы управления отелем. Отмена реального бронирования OTA может повлиять на гостя, платежи, комиссию и условия отмены.
Что если обе записи уже содержат списания?
Остановите дальнейшие платежные операции и привлеките руководителя или финансовый отдел. Подтвердите, какие списания были авторизованы, произошло ли двойное списание средств, и требует ли система управления отелем аннулирования, возврата, перевода счета или объединения с помощью поставщика.
Почему повторная попытка создала новую запись в системе управления отелем вместо обновления первой?
К частым причинам относятся отсутствующий или измененный внешний ID бронирования, первоначальный импорт, который завершился успешно, но вернул ошибку, ручная временная запись без ссылки на источник, перекрывающаяся обработка повторных попыток или изменение, которое не смогло совпасть с первой записью.
Как гостиница должна проверить исправление?
Подтвердите наличие одного активного бронирования в системе управления отелем, одного подтвержденного бронирования в OTA, одного связанного ссылочного пути, одного правильного списания номера и одного операционного баланса. Затем проверьте, что будущее изменение будет направлено на сохраненную запись.
Безопасное устранение дубликата сохраняет реальное бронирование гостя до очистки базы данных. Определите связанную запись, защитите деньги и операции, скорректируйте номерной фонд один раз и оставьте журнал аудита, который предотвратит превращение следующей повторной попытки в очередную чрезвычайную ситуацию для стойки регистрации.
