Как прогнозировать нагрузку на контакт-центр при внедрении голосового ИИ

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

Проблема обычно связана с расчётом. До запуска весь поток считали как прямые обращения к оператору. После внедрения он делится: часть звонков робот закрывает сам, часть переводит, часть клиентов перезванивает. Значит, старую модель нужно пересобрать. Ниже — рабочая последовательность расчёта.

Почему классическое прогнозирование не учитывает голосового робота

Классические модели исходят из относительно однородного потока: звонок поступает в очередь, оператор принимает его и тратит среднее время на обработку. Голосовой ИИ меняет эту схему. Один звонок заканчивается у робота, другой переводится через минуту, третий возвращается повторным обращением.

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

Как работает прогнозирование нагрузки с голосовым ИИ: общая логика

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

Шаг 1. Сегментация текущего потока обращений

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

Чем точнее сегментация, тем точнее прогноз. Если объединить в одной категории простой вопрос и многошаговую проблему, средние показатели будут бесполезны. Речевая аналитика Fromtech SpeechRadar помогает классифицировать обращения по записям и увидеть фактическую структуру потока:

SpeechRadar Fromtech

Шаг 2. Расчёт среднее время обработки обращения отдельно для робота и оператора

Для робота считают время до закрытия вопроса или перевода (АНТ). Для оператора после перевода на операторов нужен отдельный AHT: в идеальной схеме робот уже собрал тему, идентификаторы и краткое описание, поэтому сотрудник начинает не с нуля.

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

Шаг 3. Определение коэффициента удержания

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

Для предварительной модели можно заложить несколько сценариев, например 30%, 45% и 60%. Но финальное значение берут из пилота. При удержании 50% нагрузка на операторов не падает ровно вдвое: остаются прямые обращения, переводы на операторов, повторные звонки и адаптационный период.

Шаг 4. Планирование переводов на операторов и адаптационного периода

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

Для стартовой модели разумно добавить 10–15% к базовому среднему времени обработки обращения перевода на оператора. Это не отраслевой норматив, а страховой запас на период настройки. После пилота его заменяют фактическим значением. Одновременно стоит учитывать задержку: если робот переводит звонок через 60–90 секунд, пик операторской нагрузки сместится относительно общего входящего потока.

Шаг 5. Применение модели Эрланга с поправкой на ИИ

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

Важно использовать интервалы по 15 или 30 минут, а не среднее за день. Робот действительно принимает первый удар, но переводы на операторов образуют собственный пик с небольшим запаздыванием. Дневное среднее этот эффект скрывает.

Пример упрощённого расчёта

Допустим, за 30 минут поступает 1 000 звонков. По сегментации 600 из них подходят для робота. Пилот показывает удержание 50%, значит 300 звонков закрываются автоматически, а 300 переводятся. Ещё 400 обращений идут оператору напрямую. Итоговая операторская очередь за интервал — 700 звонков, но у неё два разных средних время обработки обращения.

Если прямой звонок занимает 240 секунд, а перевод на операторовс готовым контекстом 180 секунд, нагрузка составит 400 × 240 + 300 × 180 секунд. К этому добавляют запас на перерывы, неравномерность и целевой SLA. Уже после этого применяется Эрланг. Такой расчёт точнее простой формулы «робот забрал половину звонков, значит можно сократить половину смены».

Как пилот помогает уточнить модель

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

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

Рабочий чек-лист перед масштабированием

Перед расширением трафика проверьте четыре вещи: сегментация отражает реальные темы звонков; среднее время перевода на оператора измеряется отдельно; коэффициент удержания подтверждён пилотом; пики рассчитаны по коротким интервалам. Затем сравните прогноз с фактом минимум за две недели и пересчитайте графики операторов.

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

Какие данные собрать до расчёта

Минимальный набор включает входящий поток по 15- или 30-минутным интервалам, тематики звонков, среднее время обработки обращения, долю повторных обращений, процент переводов между группами и фактический SLA. Желательно взять не один спокойный месяц, а период с обычными и пиковыми днями.

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

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

Как проверить точность прогноза после запуска

Сравнивайте план и факт еженедельно в первые два месяца. Смотрите не только общий объём, но и отклонения по интервалам, темам и типам переводов на операторов .Если модель ошибается в одном и том же месте, исправляйте исходное предположение: коэффициент удержания, среднее время обработки обращения или распределение потока.

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