# Кейс автоматизации бронирования: 92% заявок без оператора

> Кейс автоматизации бронирования в сфере услуг: приём заявок из всех каналов, проверка слотов, расчёт стоимости, эскалация. 92% заявок без оператора.

- Источник: https://lokai.ru/keysy/uslugi-avtomatizaciya-bronirovaniya/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-08-07
- Раздел: Главная → Кейсы → Автоматизация бронирования

---

92% заявок на бронирование закрывается без участия оператора. Компания из сферы услуг и развлечений собрала единый приём сообщений из всех каналов: система распознаёт намерение, проверяет доступность слотов, считает стоимость по тарифам и отправляет подтверждение. Оставшиеся 8% — нестандартные случаи, которые сознательно уходят человеку, а не решаются моделью наугад.

- **92%** — заявок закрывается без участия оператора
- **8%** — передаётся человеку: нестандартные и спорные случаи
- **2–4** — недели пилота на одном канале приёма заявок
- **0** — запросов во внешние публичные сервисы

## Задача: как принимали заявки до автоматизации бронирования

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

Операторы работали в нескольких окнах и сверялись с расписанием руками. В пик время ответа росло, часть заявок доживала до утра без ответа. Клиент, не получивший ответ в течение часа, обычно уже бронировал в другом месте. Это была основная потеря, и она не отражалась ни в одном отчёте: несостоявшаяся бронь нигде не фиксируется.

Типовая заявка при этом состоит из четырёх вопросов: когда, на сколько человек, что входит, сколько стоит. Ответ на каждый определён расписанием и тарифной сеткой. Именно повторяемость сделала сценарий пригодным для автоматизации — правила были описаны заранее, а не додумывались моделью по ходу разговора.

## Что построили: контур приёма и подтверждения броней

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

### Единый приём заявок из всех каналов

Сообщения с сайта, из мессенджеров, почты и форм собираются в одну очередь. Клиент пишет туда, куда привык, а операторы перестали переключаться между вкладками и терять контекст переписки.

### Классификация сообщений

Каждое входящее относится к типу: новая заявка, уточнение по существующей брони, изменение, жалоба, вопрос не по теме. От типа зависит маршрут и то, разрешено ли системе отвечать самостоятельно.

### Проверка доступности слотов

Запрос сверяется с расписанием и блокировками в момент диалога. Клиенту не предлагается занятое время, а два параллельных разговора не могут забронировать один слот: он резервируется на время подтверждения.

### Расчёт стоимости по тарифам

Цена собирается из действующей тарифной сетки: длительность, состав, день недели, дополнительные условия. Арифметику выполняет детерминированный код, модель подбирает подходящие правила и объясняет их клиенту словами.

### Формирование подтверждений

После согласования формируется подтверждение с деталями брони и ссылкой на оплату, а сама бронь фиксируется в системе расписания. Клиент получает один документ вместо переписки, из которой нужно выуживать детали.

### Эскалация оператору

На нестандартном случае диалог передаётся человеку вместе с историей, разбором запроса и вариантами решения. Оператор продолжает разговор с того же места, а не начинает его с вопроса о том, что случилось.

## Стек и где развёрнута система бронирования

Переписка с клиентами и данные броней содержат персональные данные, поэтому контур закрытый. Внешние публичные сервисы не используются даже для распознавания текста.

*Состав контура в кейсе автоматизации бронирования в сфере услуг*

| Слой | Чем закрыт | Где работает |
|---|---|---|
| Диалог | Открытые модели Qwen и GLM в локальной установке | Сервер компании |
| Классификация | Отдельная модель типов сообщений с порогом уверенности | Контур компании |
| Правила и цены | Тарифная сетка и детерминированный расчёт стоимости | Контур компании |
| Каналы | Сайт, мессенджеры, почта — единая очередь сообщений | Контур компании |
| Бронирование | Существующая система расписания и броней | Инсталляция компании |
| Контроль | Журнал диалогов, доля эскалаций, ручной разбор выборки | Контур компании |

## Какие 8% заявок уходят оператору и почему это правильно

Доля 8% — не остаток недоделанной автоматизации, а зафиксированная граница. Её задали на старте и не двигают вниз ради красивой цифры: в этих категориях ошибка стоит дороже сэкономленной минуты.

- **Групповые и корпоративные заявки.** Нестандартный состав, длительность и условия оплаты считаются индивидуально, шаблон тарифа здесь не применим.
- **Конфликты и наложения в расписании.** Если запрос попадает в спорное окно или пересекается с блокировкой, система не выбирает вариант сама, а показывает оператору два-три сценария.
- **Жалобы и эмоциональные сообщения.** Классификатор отделяет их от заявок и передаёт человеку с полной историей. Отвечать на претензию шаблоном — самый дорогой способ ускорить обработку.
- **Непонятный запрос после двух уточнений.** Если намерение всё ещё не распознано, диалог передаётся оператору, а не идёт по третьему кругу вопросов.
- **Всё, чего нет в правилах.** Новый формат услуги, нестандартное время, специальные условия — до внесения правила такие заявки обрабатывает человек.

## Ограничения проекта и что не автоматизировали

Границы описаны в регламенте эксплуатации и заданы конфигурацией, а не устной договорённостью. Система физически не может выйти за них сама.

- **Изменение и отмена брони с возвратом денег требуют подтверждения оператора.** Система считает сумму возврата по правилам тарифа и готовит решение, но подтверждает его человек: это необратимая операция с деньгами клиента.
- **Платежи система не проводит.** Ссылка на оплату формируется, приём средств остаётся на стороне платёжного провайдера и учётной системы компании.
- **Динамическое ценообразование не входило в объём.** Цена берётся из действующей сетки; управление спросом через цену — отдельная задача с другой зоной ответственности.
- **Голосовой канал подключали отдельно.** Пилот шёл на текстовых каналах, телефония выносится в сценарий с распознаванием речи — как в направлении [голосового ИИ](https://lokai.ru/golosovoy-ii/).
- **Правила нужно поддерживать.** Новая услуга или сезонный тариф без внесения в правила сразу поднимают долю эскалаций, и это видно в дашборде в тот же день.
- **Систему бронирования не заменяли.** Слоты, брони и оплаты остались в существующем продукте, ИИ работает поверх него — так же устроены и другие [цифровые сотрудники](https://lokai.ru/tsifrovye-sotrudniki/).

## Частые вопросы по кейсу автоматизации бронирования

**Как считали долю 92%?**

Берём все входящие сообщения за период, кроме спама и явно нецелевых. Заявка считается закрытой без оператора, если диалог дошёл до подтверждённой брони или до обоснованного отказа без единого вмешательства человека. Частичное участие оператора считается участием: если он вступил на любом шаге, случай уходит в оставшиеся 8%. Замер снимается из журнала диалогов и сверяется с системой расписания, чтобы подтверждённые брони совпадали с фактически созданными. Такой способ подсчёта занижает результат, зато его невозможно оспорить на разборе.

**Клиент понимает, что общается не с человеком?**

Да, это указано в начале диалога, и мы не считаем это недостатком. Попытка выдать систему за сотрудника создаёт проблему в тот момент, когда клиент задаёт нестандартный вопрос: он ждёт человеческой реакции, а получает шаблон, и раздражение приходится гасить оператору. Честная рамка снижает ожидания до реальных: быстрый ответ по расписанию и цене. Переключение на оператора доступно в любой момент по прямой просьбе — это отдельный маршрут, который срабатывает без анализа намерения.

**Возможны ли двойные брони на один слот?**

Свободность слота проверяется не один раз в начале разговора, а в момент подтверждения. На время согласования слот резервируется, и параллельный диалог его уже не видит. Если резерв истёк, а клиент вернулся позже, система переспрашивает и предлагает ближайшие свободные окна вместо того, чтобы подтверждать занятое время. Запись брони делает существующая система расписания, а не ИИ: он формирует запрос, а конечное состояние хранится там, где хранилось всегда, с обычными блокировками на уровне данных.

**Что происходит в пиковые дни и праздники?**

Именно ради пиков всё и делалось. Поток заявок в праздники вырастает в разы, и раньше это означало очередь и потерянных клиентов: ответ приходил, когда человек уже забронировал в другом месте. Система обрабатывает диалоги параллельно, поэтому время ответа не зависит от размера очереди. Операторы в пик занимаются только теми 8%, где нужна голова. Отдельно отслеживаем долю эскалаций именно в пиковые дни: её рост означает, что появился новый тип запросов, который стоит описать правилом.

**Что нужно, чтобы повторить сценарий в другой компании?**

Три условия. Первое — система расписания с доступом на чтение и запись, годится любая, лишь бы у неё был программный интерфейс. Второе — тарифы и правила, описанные однозначно; если в них есть исключения на усмотрение администратора, их придётся либо формализовать, либо честно отнести к эскалациям. Третье — владелец сценария на вашей стороне, который поддерживает правила при появлении новых услуг. Дальше обычный порядок: бесплатная диагностика, пилот 2–4 недели на одном канале, затем расширение на остальные.

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК