Задача: гость пишет туда, где ему удобно

Небольшой отель Majestic Jupiter в Румынии принимал вопросы и запросы на бронирование по телефону, электронной почте, WhatsApp и Facebook Messenger. По описанию европейского хаба CiTyInnoHub, сообщения обрабатывались преимущественно вручную. Даты, число гостей и особые условия приходили в разном виде; сотрудникам приходилось уточнять детали, переключаться между каналами и заново собирать историю обращения. В сезон это особенно неприятно: время ответа растёт, а часть потенциальных бронирований может потеряться.

Важно не приписывать кейсу того, чего он не показывает. Хаб описывает внедрённый прототип и качественные улучшения процесса, но в разделе измеримых результатов прямо указано, что данных пока нет. Поэтому числа вроде «рост конверсии на 30%» или «окупаемость за месяц» здесь были бы выдумкой. Практическая ценность истории — в том, как небольшой сервисный бизнес ограничил роль ИИ и сохранил контроль над бронированием.

Что сделали в пилоте

Команда сначала описала путь обращения от первого сообщения до подтверждения брони. Диалоговый бот на WhatsApp, Facebook Messenger и email собирает период проживания, число гостей, контакты и специальные пожелания. Обязательные поля и простые проверки уменьшают количество неполных заявок. Затем единый слой управления процессом отслеживает статус обращения, повторные попытки и передачу задачи следующему участнику. Роботизация процессов запрашивает доступность, рассчитывает цену и создаёт запись в существующих системах отеля. Логика с элементами ИИ помогает проверять и маршрутизировать данные. Сложные запросы, вопросы оплаты и исключения передаются сотруднику вместе с контекстом.

Это не описание автономного агента, которому разрешено самостоятельно обещать гостю любую цену. Подтверждённая архитектура ближе к «диалог + проверяемые правила + интеграции + очередь исключений». Источник называет облачный коммуникационный сервис Twilio, но не раскрывает модель ИИ, точный набор RPA-инструментов и стоимость проекта. Для российского отеля или другой сервисной компании эти компоненты нужно выбирать заново с учётом доступности каналов, требований к данным и собственных систем.

Где здесь действительно нужен ИИ

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

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

Данные и интеграции до красивого интерфейса

Первый объект учёта — не сообщение, а заявка с уникальным идентификатором. В ней нужны канал и время входа, контакт с согласованным доступом, запрошенные даты, состав гостей, пожелания, статус проверки, источник цены, ответственный сотрудник и история изменений. Повторное сообщение или повторная доставка webhook не должны создавать вторую бронь: перед операцией записи нужен ключ идемпотентности и проверка существующего заказа. Документация Twilio отдельно описывает входящие webhooks, статусы доставки и механизмы различения повторов.

На схеме интеграций коммуникационный шлюз стоит отдельно от системы управления заявками и PMS/системы бронирования. Это помогает менять канал без переписывания бизнес-правил. Доступ к тарифам и наличию номеров следует выдавать по принципу минимально необходимых прав; создание или изменение брони — отдельное действие с журналом и ограничениями. Если PMS не имеет API, временный RPA-сценарий возможен, но ошибки интерфейса, смена полей и тайм-ауты потребуют мониторинга. Самый дорогой «бот» — тот, который пообещал номер, которого уже нет.

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

Что измерять, чтобы не принять пилот за окупаемость

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

Экономика тоже считается по принятому результату, а не по числу сообщений, которые бот «обработал». Модельный пример: при 300 обращениях в месяц экономия трёх минут на каждом даёт 15 часов труда; при полной стоимости часа 600 рублей это 9000 рублей в месяц до расходов на каналы, разработку, интеграцию, проверку ответов и поддержку. Это не результат Majestic Jupiter и не обещание окупаемости. Если из-за неверной цены потеряны даже несколько броней, экономия времени может исчезнуть. Конверсию в бронирование учитывайте отдельно и только по подтверждённым данным.

Ограничения и первый шаг

Соберите 50–100 обезличенных реальных обращений из двух каналов. Разметьте обязательные поля, причины уточнений и типы исключений; определите, какие действия разрешены без сотрудника. Затем соберите узкий пилот: единая карточка заявки, извлечение полей, проверка наличия из первичной системы и черновик ответа. В первые недели отправку цены и создание брони оставьте на подтверждении человека. Для каждого сбоя сохраните причину: не хватило данных, неверно распознана дата, не ответила интеграция, не нашлось правило или возник спорный случай.

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