Главная задача — сократить непрофильную нагрузку на операторов и увеличить долю коммерческих обращений, которые получают быстрый ответ и проходят до бронирования.
Контекст, задача и моя роль
Отдел бронирования крупной гостиничной сети одновременно обрабатывал новые запросы на подбор и оплату, вопросы гостей по действующим броням, справочные обращения об инфраструктуре, реакции из социальных сетей, вакансии и предложения партнёров.
Задача проекта:
- оптимизировать работу отдела бронирования без ухудшения клиентского сервиса;
- снизить время, которое операторы тратят на повторяющиеся информационные и сервисные вопросы;
- повысить скорость обработки коммерческих запросов;
- создать измеримую цепочку от обращения в чат до брони и дохода.
Также я координировал разработку архитектуры решения: определение этапов автоматизации, распределение типов обращений между чат-ботом и операторами и подготовку требований к интеграции с гостиничной учётной системой и CRM.
Диагностика: что показал анализ переписок
Для диагностики были объединены выгрузки открытых линий за первое полугодие. После удаления дублей в анализ вошло более 16 тысяч уникальных диалогов. Единицей анализа был весь диалог, а не отдельное сообщение: только так можно определить реальное намерение гостя.
| Тип обращения | Доля потока |
|---|---|
| Коммерческие | 40,8% |
| Сервисные | 32,3% |
| Информационные | 23,5% |
| Нецелевые и требующие проверки | 3,4% |
Коммерческий поток оказался крупнейшей категорией. Однако почти 56% обращений составляли сервисные и информационные вопросы. В единой очереди они конкурировали с потенциальными продажами за время операторов.
Каналы и нагрузка
Почти половину потока создавал сайт — канал, находящийся ближе всего к выбору и бронированию. Социальные сети смешивали коммерческие вопросы, реакции на контент и справочные обращения, поэтому единый сценарий обработки не учитывал различия в намерении пользователя.
Скорость ответа
Почти каждый шестой диалог ожидал ответа более трёх часов. Около четверти обращений поступало вне основного рабочего окна. Без классификации нельзя было отделить коммерческие потери от реакций, спама и нецелевого потока.
| Канал коммуникации | Доля |
|---|---|
| Онлайн-чат на сайте | 46,6% |
| Instagram Direct | 25,4% |
| Telegram | 11,9% |
| ВКонтакте | 10,7% |
| 5,5% |
| Показатель скорости ответа | Значение |
|---|---|
| Медиана первого ответа | 10,6 минуты |
| Ответ до 5 минут | 32,8% |
| Ответ до 15 минут | 57,8% |
| Ожидание более 3 часов | 16,4% |
| Без зафиксированного ответа | 19,9% |
Ключевая проблема
Проблема заключалась не только в количестве обращений, а в отсутствии маршрутизации по намерению гостя. Новая продажа, сопровождение действующей брони и справочный вопрос попадали в одну очередь.
Дополнительное ограничение находилось в CRM. Большинство диалогов создавало технический лид, но связь с контактом, сделкой и бронью заполнялась непоследовательно. CRM отмечала информационными более 80% переписок, хотя анализ текста показал около 24%. Поэтому стандартные отчёты не отражали реальную коммерческую роль чатов.
| Связь или классификация | Доля диалогов |
|---|---|
| Связаны с лидом | 87,9% |
| Связаны со сделкой | 3,3% |
| CRM: информационные | 82,7% |
| По содержанию: информационные | 23,5% |
Решение: двухэтапная модель автоматизации
До выбора технологии была проведена классификация обращений, определены частые сценарии и сформированы требования к подрядчикам. Это позволило строить внедрение от простого и безопасного уровня к коммерчески значимой интеграции.
Разгрузить операторов от повторяющихся вопросов
Разделить поток по типам, создать базу знаний из реальных вопросов гостей, подключить бота для первой линии информационных и типовых сервисных обращений и передавать сотруднику нестандартные ситуации.
Подключить коммерческие сценарии
Интегрировать бота с гостиничной учётной системой и CRM, получать актуальные цены и наличие, сохранять параметры обращения и передавать оператору горячий запрос с уже собранными данными.
На первом этапе бот не должен самостоятельно консультировать по динамической цене и наличию. Без интеграции с учётными системами такие ответы быстро устаревают и создают риск ошибки.
| Тип обращения | Первичная обработка | Следующий шаг |
|---|---|---|
| Информационное | База знаний и бот | Ответ или перевод оператору |
| Сервисное типовое | Бот + данные брони | Ответ, действие или эскалация |
| Коммерческое стандартное | Бот + цена и наличие | Ссылка на бронь / сделка в CRM |
| Коммерческое сложное | Сбор параметров ботом | Приоритетная передача оператору |
Что уже получено
Результатом аналитического этапа стала не абстрактная рекомендация «поставить чат-бота», а готовая архитектура оптимизации:
- определена фактическая структура обращений и доля коммерческого потока;
- выявлены темы, создающие повторяемую нагрузку;
- сформирована база для быстрых ответов и знаний чат-бота;
- разработано разделение сценариев между ботом и оператором;
- определены требования к подрядчикам и интеграции с гостиничной системой и CRM;
- задана модель регулярного отчёта «чат → сделка → бронь → доход».
Как измерять эффект после внедрения
| Цель | Основной показатель | Что сравнивать |
|---|---|---|
| Разгрузка отдела | Доля диалогов, закрытых ботом | До и после этапа 1 |
| Ускорение ответа | Медиана и доля ответов до 5/15 минут | По типам обращений |
| Сохранение спроса | Коммерческие диалоги без ответа | По каналам и времени |
| Рост продаж | Конверсия чат → бронь | После настройки связей CRM |
| Финансовый эффект | Доход и маржинальный эффект чатов | Относительно затрат на решение |
Повторяемая методика
Подход применим для гостиничных сетей, управляющих компаний и отдельных объектов с заметным объёмом обращений:
- выгрузить диалоги и удалить дубли;
- классифицировать обращения по намерению и теме;
- оценить каналы, сезонность, SLA и необработанный поток;
- сопоставить содержание переписок с классификацией CRM;
- выделить частые и стандартизируемые сценарии для базы знаний;
- разделить автоматизацию на информационный, сервисный и коммерческий уровни;
- связать чат со сделкой, бронью, оплатой и доходом;
- запускать этапами и измерять эффект на сопоставимых периодах.
Главный вывод
Оптимизация отдела бронирования начинается не с выбора чат-бота. Сначала необходимо понять структуру потока и отделить обращения, где автоматизация безопасна, от запросов, где критичны актуальные коммерческие данные или участие сотрудника.
В этом проекте аналитика показала, что крупнейшая часть потока связана с продажами, но операторы одновременно обслуживают большой объём сервисных и справочных вопросов. Поэтому разумная модель — сначала разгрузить первую линию с помощью базы знаний и бота, затем подключить учётные системы и только после этого автоматизировать коммерческую консультацию.
Нужно понять, где в digital-системе отеля теряются обращения, бронирования и данные?
Обсудить диагностику digital-системы отеля