Кейс: сначала единый процесс, потом ИИ

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

В опубликованном European Digital Innovation Hub кейсе речь идёт о компании размером 10–49 сотрудников с оборотом около €1,1 млн за 2024 год. До проекта её цифровая зрелость оценивалась в 24%. Это важный контекст: решение создавали не для технологической корпорации с собственной командой данных, а для малого бизнеса с ограниченным временем сотрудников на внедрение.

Главный вывод кейса — автоматизация началась не с выбора большой языковой модели. Сначала команда описала сквозной сценарий обращения и бронирования: какие данные обязательны, что можно проверить автоматически, где нужен повтор, а где диалог должен перейти человеку. Уже поверх этой схемы появились чат-бот, оркестратор процессов, RPA и элементы AI-логики.

Как устроена архитектура

Опубликованное описание позволяет разделить решение на пять слоёв.

1. **Каналы входа.** Чат-бот работает в WhatsApp, Facebook Messenger и электронной почте. Телефон остаётся человеческим каналом, но цифровые обращения больше не распределены по разным необозримым очередям.
2. **Структурированный диалог.** Система запрашивает даты проживания, число гостей, специальные требования и контакты. Форматы проверяются до передачи заявки дальше, поэтому сотруднику реже приходится выяснять базовые сведения повторно.
3. **Центральная оркестрация.** Каждое обращение получает состояние в едином потоке. Оркестратор хранит трассу, управляет очередью и повторами, а руководитель видит, на каком шаге находится заявка.
4. **Детерминированные действия.** RPA проверяет доступность, рассчитывает цену и создаёт бронь в существующих системах. Эти операции не стоит поручать генеративной модели: наличие номера и тариф должны определяться правилами и актуальными данными.
5. **Передача человеку.** Сложные, чувствительные и платёжные вопросы уходят сотруднику вместе с контекстом разговора. Гость не начинает объяснение заново, а автоматизация не принимает решение за пределами разрешённого сценария.

В кейсе названы облачные коммуникационные сервисы Twilio и AI-enabled логика для проверки и маршрутизации. При этом не раскрыты конкретная модель, способ её размещения и доля запросов, обрабатываемых генеративным ИИ. Поэтому корректнее считать это кейсом процессной автоматизации с элементами ИИ, а не доказательством превосходства определённой LLM.

Что подтверждено, а чего в отчёте нет

EDIH фиксирует переход от разрозненной ручной обработки к единому отслеживаемому потоку. Начальные этапы обращения — сбор данных, проверка полей, запрос доступности и расчёт цены — стали выполняться быстрее и с меньшим ручным участием. Появились очередь, повторные попытки и журнал прохождения заявки. Сотрудники сохранили контроль над исключениями.

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

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

Где здесь нужен локальный ИИ

Локальная модель уместна не на каждом шаге. Форму с датами и числом гостей можно обработать обычными правилами. Доступность, цена, скидка и создание брони должны идти через API или детерминированный исполнитель с проверками.

Локальная LLM может быть полезна в трёх местах:

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

Размещение внутри контролируемого контура имеет смысл, если в сообщениях есть персональные данные, корпоративная политика ограничивает внешние API или объём запросов делает локальный инференс экономически предсказуемым. Но локальная модель не отменяет интеграции с PMS, CRM, 1С или другой учётной системой. Без актуального источника наличия и цены она лишь красиво формулирует предположение.

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

Риски, которые надо закрыть до запуска

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

Второй риск — prompt injection. Гостевое сообщение является недоверенным вводом. OWASP рекомендует ограничивать роль модели, проверять формат результата детерминированным кодом, выдавать минимальные права и требовать человеческого одобрения для привилегированных операций. Доступ к внутренним системам следует давать не модели напрямую, а узкому шлюзу с разрешёнными командами.

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

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

Как посчитать экономику без фантазий

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

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

Пример ниже — модельный расчёт, а не результат Majestic Jupiter. Допустим, бизнес получает 100 цифровых обращений в день, система экономит четыре минуты на 60% из них, работает 250 дней в год, а полная стоимость часа сотрудника равна 700 ₽. Тогда высвобождается 1 000 часов, или 700 000 ₽ в год. Из этой суммы надо вычесть лицензии, сообщения, интеграцию, поддержку и время контроля. Рост продаж добавляйте только после сравнения с контрольным периодом, а не как обещание поставщика.

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

Пилот на четыре недели

**Неделя 1. Описать процесс.** Выберите один сценарий — например, запрос доступности. Соберите 100–300 обезличенных обращений, перечислите обязательные поля, исключения и причины передачи человеку. Зафиксируйте базовые показатели.

**Неделя 2. Собрать теневой контур.** Подключите один канал к очереди, но не отправляйте ответы автоматически. Пусть правила или модель извлекают данные, а сотрудник сравнивает результат с реальным решением. Доступность и цена читаются только из тестового интерфейса учётной системы.

**Неделя 3. Разрешить безопасные ответы.** Автоматизируйте подтверждение получения, запрос недостающих полей и ответы на утверждённые вопросы. Создание брони оставьте за сотрудником либо за детерминированной командой с предварительным просмотром.

**Неделя 4. Проверить сбои и экономику.** Имитируйте потерю связи, дубли, неверные даты, конфликт тарифов и необычные пожелания. Посчитайте стоимость обращения и время сотрудника. Масштабируйте только если качество не хуже базового, очередь восстанавливается, а эффект превышает регулярные расходы.

Что взять руководителю

Полезная часть кейса — не чат-бот как витрина, а единый управляемый конвейер за ним. Малому бизнесу стоит начинать с одного процесса, детерминированных правил и видимой очереди. ИИ добавляется туда, где нужно понять свободный текст или подготовить формулировку; деньги, наличие и обязательства остаются под контролем систем и людей.

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