Один из крупнейших телеком-операторов

Задача

2-я линия поддержки крупного телеком-оператора — это сотни тысяч обращений в месяц. Тарифы, баланс, подписки, непонятные списания, подключение и отключение услуг. Оператор получает тикет, читает переписку с 1-й линией, лезет в несколько внутренних систем за контекстом (биллинг, CRM, управление услугами, история транзакций), собирает ответ. На одно обращение уходит 15–25 минут.

Отдельный запрос несложный, проблема в масштабе. 80% обращений типовые, но каждое требует ручного сбора контекста из 3–5 систем и соблюдения сценария ответа — для каждой темы и подтемы свой скрипт. Оператор тратит большую часть времени не на решение проблемы клиента, а на сбор контекста: открыть одну систему, посмотреть баланс, открыть другую, проверить историю списаний, открыть третью, найти подходящий скрипт. Это ручной труд, замаскированный под интеллектуальный. И масштабируется он только линейно — больше обращений означает больше людей.

Почему это сложнее, чем кажется

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

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

AI должен говорить голосом бренда. «Ваш баланс составляет 342 рубля» и «На счету 342 рубля» — технически одно и то же, но для бренда разница принципиальная. Название компании пишется строчными без кавычек, рубли — полностью без сокращений, эмоциональные фразы вроде «понимаю вашу боль» запрещены. Корпоративный тон оказался настолько трудной задачей, что формулировки шлифовали больше 60 раз на реальных диалогах.

Одного умного агента на все случаи жизни не хватает. Ранний прототип — один агент на все темы — справлялся с типовыми запросами, но путался в нестандартных, нарушал порядок действий и иногда отвечал на вопросы, на которые отвечать не должен. Архитектуру пришлось пересобирать трижды, пока не нашли баланс между гибкостью AI и жёсткостью корпоративных скриптов.

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

Что попробовали и выкинули

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

Как устроено

Финальная архитектура — результат трёх пересборок. Ключевое решение: разделить «понять, что спросили» и «что с этим делать» на разные агенты с разной степенью свободы.

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

Для каждой пары тема + подтема в базе лежит конкретный план действий: какие данные запросить, из каких систем, в каком порядке, что ответить. Этот план становится приоритетной инструкцией для основного агента — он обязан следовать ему, а не импровизировать.

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

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

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

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

Результат

После запуска на боевом трафике клиент заказал расширение системы на новые категории обращений. Не доработку, не исправление — масштабирование работающей архитектуры.

Оператор больше не собирает контекст из внутренних систем вручную — это делает агент. Работа оператора сводится к проверке и отправке готового ответа. То, на что раньше уходило 15–25 минут, собирается за секунды. Матрица сценариев и корпоративный тон продолжают шлифоваться на реальных диалогах — это непрерывный процесс, который не заканчивается с релизом.