CRM-аналитика
Как перестроить цепочку CRM после изменения бронирования
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Путешественник перенёс поездку на неделю, но продолжает получать советы «Что взять с собой завтра». У него есть ещё одна бронь на декабрь, поэтому общий признак «поездка отменена» в профиле тоже не решает задачу: он остановит полезные сообщения о другом путешествии. В туризме коммуникация должна сопровождать конкретное бронирование и его актуальное состояние.
Бронирование — отдельный объект с составом услуг, участниками, датами и условиями. Профиль человека связывает его с этим объектом, но не заменяет его. Один клиент может одновременно быть заказчиком одной поездки и участником другой; получатели платёжных документов и инструкций на месте могут различаться.
Сохраните идентификатор брони и её версию
Для управления цепочкой нужны номер брони, версия состояния, статус, даты, часовые пояса, услуги и роль получателя. Версия — признак того, что данные брони обновились; она помогает отличить новую информацию от уже обработанной. Если источник не отдаёт последовательный номер, интеграция должна иметь согласованный способ проверки актуальности.
API — интерфейс программного обмена данными между системами. В Booking.com Reservations API отдельно описаны получение новых бронирований и обработка изменений или отмен. Подтверждение получения сообщения зависит от используемого интерфейса. Это пример того, почему интеграция не может ограничиться событием «бронь создана». Конкретный порядок подтверждений, повторов и восстановления нужно проверить у своего поставщика.
Сохраняйте время изменения в источнике и время получения CRM. Последнее полученное событие не всегда является самым новым по смыслу. Задержавшаяся запись о первоначальной дате не должна возвращать её после подтверждённого переноса.
Стройте расписание относительно актуальной поездки
Каждое сообщение связывайте с бронью, этапом и версией данных. Например, инструкция по заселению может иметь ключ «бронь 582, подготовка к заезду, версия 4». Повторная доставка того же события не должна создавать второе одинаковое сообщение.
При изменении даты пересчитайте будущие действия. Для сообщений, уже стоящих в очереди, нужен механизм отмены или проверки перед отправкой. Если платформа не умеет удалять задание из очереди, условие актуальности должно блокировать его на последнем доступном этапе.
| Изменение | Что пересчитать | Что сохранить |
|---|---|---|
| Перенос даты | Напоминания и предложения относительно поездки | Историю прежних обещаний и причины изменений |
| Смена места проживания | Адрес, маршрут, инструкции на месте | Остальные услуги, если они не изменились |
| Отмена одной услуги | Только связанные с ней сообщения | Действующие части брони |
| Полная отмена | Всю цепочку поездки, кроме необходимых действий по завершению | Расчёты, обращения и подтверждения |
| Изменение участника | Получателей сообщений для этого участника | Роли остальных участников |
Разделите изменение брони и финансовый результат
Отмена путешествия не означает, что возврат денег уже выполнен. Перенос может требовать доплаты, а подтверждённая новая дата — ожидать оплаты до установленного срока. Поэтому в CRM должны быть отдельные состояния бронирования, платежа и возврата.
Сообщение «Возврат оформлен» должно соответствовать тому действию, которое действительно произошло. Если создана только заявка, так и пишите: «Заявка принята; следующий статус сообщим после обработки». Не обещайте срок зачисления, который не подтверждён финансовым процессом.
Для нескольких путешественников не пересылайте всем всю финансовую и персональную информацию. Организатору может требоваться счёт, участнику — адрес встречи. Смена роли или контакта требует проверки, особенно если сообщение открывает доступ к документам или управлению бронью.
Проверьте цепочку на одном сложном примере
Условный пример. Анна бронирует отель с 10 по 15 ноября и отдельный трансфер на 10 ноября. Затем отель переносится на 17–22 ноября, но трансфер пока не изменён. Правильная система останавливает старую гостиничную инструкцию, создаёт новую и фиксирует несоответствие трансфера. Она не объявляет всю поездку успешно перенесённой.
В тот же день приходит запоздавшее событие о первоначальной брони. Проверка версии не позволяет вернуть старые даты. Позже трансфер отменяют: останавливаются его напоминания, однако гостиничная цепочка остаётся активной. Возврат за трансфер идёт отдельным маршрутом.
Здесь полезны минимум шесть тестов: перенос на более раннюю дату, частичная отмена, два путешествия одновременно, повтор события, запоздавшее событие и смена часового пояса. В тесте с приближающейся датой проверьте, не отправляет ли система сразу все пропущенные шаги новой цепочки.
Измеряйте точность и полезность уведомлений
Основные операционные показатели — доля сообщений с неактуальными условиями, время от подтверждённого изменения до обновления цепочки и число неразрешённых противоречий между услугами. Считайте их на бронирования и изменения, а не на общий объём отправленных писем.
Дополнительно оценивайте обращения из-за непонятных инструкций, неиспользованные оплаченные услуги и успешное выполнение следующего действия. Продажу дополнительной услуги измеряйте отдельно: хорошая информированность клиента и коммерческий эффект не обязаны изменяться одновременно.
Практическая схема CRM Lab проста по смыслу: каждое сообщение должно отвечать на вопрос о конкретной действующей поездке. Перед отправкой система подтверждает, что эта поездка всё ещё существует в том виде, который описан в тексте. Если подтвердить это нельзя, нужна проверка состояния, а не уверенное устаревшее обещание.
Источники
Booking.com. Understanding the Reservations API. Connectivity APIs Documentation. Проверено 23.09.2026.