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

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

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

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

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

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

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

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

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

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

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

SpeechRadar Fromtech

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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