Единый приём заявок из всех каналов
Сообщения с сайта, из мессенджеров, почты и форм собираются в одну очередь. Клиент пишет туда, куда привык, а операторы перестали переключаться между вкладками и терять контекст переписки.
Кейс · Услуги
Кейс автоматизации бронирования: 92% заявок без оператора
92% заявок на бронирование закрывается без участия оператора. Компания из сферы услуг и развлечений собрала единый приём сообщений из всех каналов: система распознаёт намерение, проверяет доступность слотов, считает стоимость по тарифам и отправляет подтверждение. Оставшиеся 8% — нестандартные случаи, которые сознательно уходят человеку, а не решаются моделью наугад.
92%заявок закрывается без участия оператора
8%передаётся человеку: нестандартные и спорные случаи
2–4недели пилота на одном канале приёма заявок
0запросов во внешние публичные сервисы
Задача: как принимали заявки до автоматизации бронирования
Компания из сферы услуг и развлечений: несколько площадок, плотное расписание, неравномерный поток. Вечера, выходные и праздники дают пики в разы выше будних дней. Клиенты пишут во все каналы сразу — на сайт, в мессенджеры, на почту и в личные сообщения администратора площадки.
Операторы работали в нескольких окнах и сверялись с расписанием руками. В пик время ответа росло, часть заявок доживала до утра без ответа. Клиент, не получивший ответ в течение часа, обычно уже бронировал в другом месте. Это была основная потеря, и она не отражалась ни в одном отчёте: несостоявшаяся бронь нигде не фиксируется.
Типовая заявка при этом состоит из четырёх вопросов: когда, на сколько человек, что входит, сколько стоит. Ответ на каждый определён расписанием и тарифной сеткой. Именно повторяемость сделала сценарий пригодным для автоматизации — правила были описаны заранее, а не додумывались моделью по ходу разговора.
Что построили: контур приёма и подтверждения броней
Система работает поверх существующего расписания и не заменяет его. Задача была снять с людей повторяющийся диалог, а не переносить бронирование в новый интерфейс.
01
02
Классификация сообщений
Каждое входящее относится к типу: новая заявка, уточнение по существующей брони, изменение, жалоба, вопрос не по теме. От типа зависит маршрут и то, разрешено ли системе отвечать самостоятельно.
03
Проверка доступности слотов
Запрос сверяется с расписанием и блокировками в момент диалога. Клиенту не предлагается занятое время, а два параллельных разговора не могут забронировать один слот: он резервируется на время подтверждения.
04
Расчёт стоимости по тарифам
Цена собирается из действующей тарифной сетки: длительность, состав, день недели, дополнительные условия. Арифметику выполняет детерминированный код, модель подбирает подходящие правила и объясняет их клиенту словами.
05
Формирование подтверждений
После согласования формируется подтверждение с деталями брони и ссылкой на оплату, а сама бронь фиксируется в системе расписания. Клиент получает один документ вместо переписки, из которой нужно выуживать детали.
06
Эскалация оператору
На нестандартном случае диалог передаётся человеку вместе с историей, разбором запроса и вариантами решения. Оператор продолжает разговор с того же места, а не начинает его с вопроса о том, что случилось.
Стек и где развёрнута система бронирования
Переписка с клиентами и данные броней содержат персональные данные, поэтому контур закрытый. Внешние публичные сервисы не используются даже для распознавания текста.
| Слой | Чем закрыт | Где работает |
|---|---|---|
| Диалог | Открытые модели Qwen и GLM в локальной установке | Сервер компании |
| Классификация | Отдельная модель типов сообщений с порогом уверенности | Контур компании |
| Правила и цены | Тарифная сетка и детерминированный расчёт стоимости | Контур компании |
| Каналы | Сайт, мессенджеры, почта — единая очередь сообщений | Контур компании |
| Бронирование | Существующая система расписания и броней | Инсталляция компании |
| Контроль | Журнал диалогов, доля эскалаций, ручной разбор выборки | Контур компании |
Какие 8% заявок уходят оператору и почему это правильно
Доля 8% — не остаток недоделанной автоматизации, а зафиксированная граница. Её задали на старте и не двигают вниз ради красивой цифры: в этих категориях ошибка стоит дороже сэкономленной минуты.
- Групповые и корпоративные заявки. Нестандартный состав, длительность и условия оплаты считаются индивидуально, шаблон тарифа здесь не применим.
- Конфликты и наложения в расписании. Если запрос попадает в спорное окно или пересекается с блокировкой, система не выбирает вариант сама, а показывает оператору два-три сценария.
- Жалобы и эмоциональные сообщения. Классификатор отделяет их от заявок и передаёт человеку с полной историей. Отвечать на претензию шаблоном — самый дорогой способ ускорить обработку.
- Непонятный запрос после двух уточнений. Если намерение всё ещё не распознано, диалог передаётся оператору, а не идёт по третьему кругу вопросов.
- Всё, чего нет в правилах. Новый формат услуги, нестандартное время, специальные условия — до внесения правила такие заявки обрабатывает человек.
Ограничения проекта и что не автоматизировали
Границы описаны в регламенте эксплуатации и заданы конфигурацией, а не устной договорённостью. Система физически не может выйти за них сама.
- Изменение и отмена брони с возвратом денег требуют подтверждения оператора. Система считает сумму возврата по правилам тарифа и готовит решение, но подтверждает его человек: это необратимая операция с деньгами клиента.
- Платежи система не проводит. Ссылка на оплату формируется, приём средств остаётся на стороне платёжного провайдера и учётной системы компании.
- Динамическое ценообразование не входило в объём. Цена берётся из действующей сетки; управление спросом через цену — отдельная задача с другой зоной ответственности.
- Голосовой канал подключали отдельно. Пилот шёл на текстовых каналах, телефония выносится в сценарий с распознаванием речи — как в направлении голосового ИИ.
- Правила нужно поддерживать. Новая услуга или сезонный тариф без внесения в правила сразу поднимают долю эскалаций, и это видно в дашборде в тот же день.
- Систему бронирования не заменяли. Слоты, брони и оплаты остались в существующем продукте, ИИ работает поверх него — так же устроены и другие цифровые сотрудники.
Вопросы и ответы
Частые вопросы по кейсу автоматизации бронирования
Как считали долю 92%?
Берём все входящие сообщения за период, кроме спама и явно нецелевых. Заявка считается закрытой без оператора, если диалог дошёл до подтверждённой брони или до обоснованного отказа без единого вмешательства человека. Частичное участие оператора считается участием: если он вступил на любом шаге, случай уходит в оставшиеся 8%. Замер снимается из журнала диалогов и сверяется с системой расписания, чтобы подтверждённые брони совпадали с фактически созданными. Такой способ подсчёта занижает результат, зато его невозможно оспорить на разборе.
Клиент понимает, что общается не с человеком?
Да, это указано в начале диалога, и мы не считаем это недостатком. Попытка выдать систему за сотрудника создаёт проблему в тот момент, когда клиент задаёт нестандартный вопрос: он ждёт человеческой реакции, а получает шаблон, и раздражение приходится гасить оператору. Честная рамка снижает ожидания до реальных: быстрый ответ по расписанию и цене. Переключение на оператора доступно в любой момент по прямой просьбе — это отдельный маршрут, который срабатывает без анализа намерения.
Возможны ли двойные брони на один слот?
Свободность слота проверяется не один раз в начале разговора, а в момент подтверждения. На время согласования слот резервируется, и параллельный диалог его уже не видит. Если резерв истёк, а клиент вернулся позже, система переспрашивает и предлагает ближайшие свободные окна вместо того, чтобы подтверждать занятое время. Запись брони делает существующая система расписания, а не ИИ: он формирует запрос, а конечное состояние хранится там, где хранилось всегда, с обычными блокировками на уровне данных.
Что происходит в пиковые дни и праздники?
Именно ради пиков всё и делалось. Поток заявок в праздники вырастает в разы, и раньше это означало очередь и потерянных клиентов: ответ приходил, когда человек уже забронировал в другом месте. Система обрабатывает диалоги параллельно, поэтому время ответа не зависит от размера очереди. Операторы в пик занимаются только теми 8%, где нужна голова. Отдельно отслеживаем долю эскалаций именно в пиковые дни: её рост означает, что появился новый тип запросов, который стоит описать правилом.
Что нужно, чтобы повторить сценарий в другой компании?
Три условия. Первое — система расписания с доступом на чтение и запись, годится любая, лишь бы у неё был программный интерфейс. Второе — тарифы и правила, описанные однозначно; если в них есть исключения на усмотрение администратора, их придётся либо формализовать, либо честно отнести к эскалациям. Третье — владелец сценария на вашей стороне, который поддерживает правила при появлении новых услуг. Дальше обычный порядок: бесплатная диагностика, пилот 2–4 недели на одном канале, затем расширение на остальные.
Первый шаг
Бесплатный аудит: посчитаем эффект внедрения ИИ на ваших цифрах
30–40 минут разбора: смотрим ваши процессы, отмечаем, что можно передать ИИ, считаем ROI-модель на ваших объёмах и сроках. Вы уходите с расчётом и картой внедрения — даже если работать дальше не будете.
Читайте также
Цифровые сотрудникиРоль, собранная из агентов и координатора: база знаний, формализованный процесс, цифровые KPI и отчётность. 16 сервисов Голосовой ИИРаспознавание и синтез русской речи на открытых моделях: звонки, планёрки, контроль качества, ассистент в цехе.КейсыОбезличенные кейсы внедрения ИИ с метриками до и после: ритейл, производство, образование, маркетинг.