Пилот голосового ИИ прошёл. Что дальше: три сценария масштабирования в контакт-центре

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

Просто передать роботу больше звонков недостаточно. До расширения необходимо определить бизнес-KPI, настроить аналитику причин переводов и повторных обращений, закрепить владельца процесса и установить правила остановки проблемных сценариев. Иначе вместе с результатами пилота компания масштабирует его незамеченные ограничения.

Сценарий	Что масштабируется	Когда подходит
По объёму	Доля потока и количество одновременных обращений	Сценарий стабилен, но охватывает небольшую часть нагрузки
По функциям	Количество автоматизированных задач	В текущем клиентском пути остаются смежные ручные операции
По управлению	KPI, аналитика, регламенты и контроль качества	Голосовой ИИ становится постоянной частью контакт-центра

Почему успешный пилот ещё не означает готовность к промышленной эксплуатации

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

Например, во время пилота робот может:

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

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

Промышленная эксплуатация предъявляет другие требования. Голосовой ИИ должен сохранять качество при увеличении нагрузки, изменениях в продуктах, появлении новых клиентских вопросов и сбоях во внешних системах.

До масштабирования компании необходимо ответить на дополнительные вопросы:

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

Если таких правил нет, голосовой робот остаётся отдельным ИТ-проектом, а не становится управляемой частью контакт-центра.

Исследование YouGov, проведённое в Германии по заказу sipgate в апреле 2026 года, показывает этот разрыв. Из 524 опрошенных руководителей 44% сообщили, что их компании используют, тестируют, планируют или обсуждают Voice AI. При этом только 22% компаний из этой группы сформулировали чёткие цели и показатели.

Полномасштабно Voice AI использовали 8% опрошенных компаний, ещё 18% применяли технологию в отдельных процессах, а 12% находились на этапе тестирования. Эти данные нельзя автоматически переносить на российский рынок, но они показывают общую управленческую проблему: интерес к технологии растёт быстрее, чем зрелость процессов вокруг неё.

Сценарий 1. Масштабирование по объёму

Масштабирование по объёму означает, что робот получает большую долю существующего потока. Компания не меняет основную задачу, но расширяет количество звонков, периоды работы или число одновременных линий.

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

Обычно проект развивается последовательно:

1. Робот обрабатывает ограниченную выборку.
2. Поток увеличивается в обычные часы.
3. Подключаются периоды пиковой нагрузки.
4. Сценарий распространяется на дополнительные подразделения или регионы.
5. Робот принимает основную долю обращений выбранной категории.

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

Поэтому недостаточно измерять только число принятых звонков. Необходимо контролировать:

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

Результат масштабирования по объёму — не максимальное количество звонков у робота. Цель состоит в том, чтобы контакт-центр обработал больший поток без роста очереди, повторных обращений и перегрузки операторов.

Что проверить перед увеличением потока

Масштабировать объём можно, если:

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

Если при небольшом потоке уже растёт число повторных звонков или ручных исправлений, сначала нужно доработать сценарий.

Сценарий 2. Масштабирование по функциям

При масштабировании по функциям робот начинает решать дополнительные задачи в рамках клиентского пути.

Например, сначала голосовой ассистент отвечает на типовые вопросы, а затем получает возможность:

• проверять статус заявки;
• подтверждать или переносить запись;
• отправлять сообщение со ссылкой;
• фиксировать результат в CRM;
• собирать данные до перевода;
• передавать оператору краткий контекст;
• обрабатывать повторные обращения;
• запускать связанные исходящие напоминания.

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

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

Новые функции нужно выбирать по их влиянию на процесс.

Перед расширением следует проверить:

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

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

При таком развитии голосовой ИИ перестаёт быть отдельным каналом и становится частью сквозного бизнес-процесса.

Как добавлять новые сценарии

Для каждой новой функции необходимо отдельно определить:

1. Бизнес-задачу.
2. Целевую группу клиентов.
3. Источник данных.
4. Допустимые действия робота.
5. Условия перевода оператору.
6. Показатели качества.
7. Критерии остановки сценария.
8. Ответственного за обновление.

Расширять функции лучше последовательно. Сначала новый сценарий проверяется на ограниченном потоке, затем сравнивается с исходным процессом и только после этого масштабируется. Как это работает в промышленном проекте, можно посмотреть на примере LLM-робота на входящей линии финтех-компании

Сценарий 3. Масштабирование системы управления

Третий сценарий предполагает, что компания масштабирует не только звонки и функции, но и систему управления голосовым ИИ.

Он становится необходим, когда робот регулярно влияет на:

• доступность контакт-центра;
• SLA;
• клиентский опыт;
• нагрузку операторов;
• стоимость обслуживания;
• продажи или удержание;
• качество данных в CRM.

На этом этапе необходимо определить:

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

Такой подход соответствует направлению, закреплённому в COPC CX Standard Release 8.0. Обновлённый стандарт предлагает единый подход к управлению операторами и автоматизированными системами, включает требования к AI governance, планированию CX-технологий, проверке производительности и аудиту баз знаний.

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

Кто должен владеть результатом

ИТ-команда не может быть единственным владельцем проекта. Она отвечает за инфраструктуру и интеграции, но не всегда управляет клиентским процессом или бизнес-KPI.

В промышленном проекте роли можно распределить следующим образом:

Роль	Зона ответственности
Владелец бизнес-процесса	Цель проекта и итоговые KPI
Контакт-центр	Поток обращений, операционная обратная связь
ИТ-команда	Инфраструктура, интеграции и доступность систем
Аналитики	Отчётность, причины переводов, отклонения
Поставщик технологии	Логика, настройка и техническая поддержка
Контроль качества	Аудит диалогов и проверка изменений

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

Что должно быть готово до масштабирования

Перед расширением проекта необходимо проверить не только работу робота, но и весь операционный контур.

Элемент	Что должно быть определено
Бизнес-цель	Какой процесс и показатель должны измениться
KPI	Какие технические, операционные и финансовые метрики контролируются
Интеграции	Какие данные робот получает и куда передаёт результат
Аналитика	Как фиксируются переводы, ошибки и повторные обращения
Регламент изменений	Кто инициирует, согласует, тестирует и выпускает правки
Правила остановки	При каких отклонениях сценарий отключается
Эскалация	Когда робот переводит клиента и какой контекст получает оператор
Инфраструктура	Как система работает под планируемой нагрузкой
Ответственные	Кто владеет результатом и каждым участком процесса

В проектах Fromtech эти параметры следует фиксировать до расширения потока. Пилот даёт данные для решения о масштабировании, но сам по себе не заменяет регламент промышленной эксплуатации.

Какие KPI нужны после пилота

Для промышленного запуска показатели целесообразно разделить на четыре группы.

Нагрузка

• количество звонков, принятых роботом;
• доля потока, переданная автоматизации;
• число одновременных диалогов;
• изменение очереди;
• нагрузка на операторов в часы пик.

Качество

• доля обращений, завершённых без оператора;
• доля и причины переводов;
• повторные обращения;
• сбросы на отдельных ветках;
• ошибки распознавания и классификации;
• корректность передачи контекста.

Экономика

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

Управление

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

Один процент автоматизации не показывает полноценный результат. Высокая автоматизация может сопровождаться повторными звонками и некачественными переводами. Более низкая доля автоматизации может быть оправдана, если робот стабильно закрывает безопасные массовые обращения, а сложные вопросы быстро направляет специалисту.

Когда проект пока не готов к масштабированию

Расширять проект рано, если:

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

В такой ситуации правильнее сохранить ограниченный объём, устранить слабые места и повторно проверить показатели. Масштабирование нестабильного процесса увеличивает не только его результат, но и количество ошибок.

Как выбрать сценарий масштабирования

Три сценария не исключают друг друга, но их необязательно запускать одновременно.

Масштабирование по объёму подходит, если текущий сценарий стабилен и нужно увеличить охват.

Масштабирование по функциям необходимо, если основная потеря времени возникает в смежных ручных операциях.

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

На практике развитие часто выглядит так:

1. Компания подтверждает эффективность одного сценария.
2. Увеличивает долю потока.
3. Подключает соседние задачи.
4. Формирует постоянный контур управления.
5. Регулярно пересматривает KPI и клиентский путь.

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

Вывод

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

Устойчивый результат появляется не тогда, когда робот совершил первый успешный звонок, а когда вокруг него выстроены KPI, интеграции, аналитика, регламент изменений, правила эскалации и контроль качества.

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

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