ТелекомСтоит ли автоматизировать
Что дешевле: нанять двенадцать операторов или убрать причину обращений?
Сорок процентов обращений — «где мой заказ». Такие обращения не обрабатывают, их не создают.
Что дал расчёт
- Время от обращения до решения
- было
18,79,8мин - −48%
- Работа операторов над одной проблемой
- было
8,75,9мин - −33%
- Решение в пределах 8 минут (SLA)
- было
4074% - +33,9 п.п.
- Загрузка операторов
- было
9086% - −4,3 п.п.
На потоке 218 400 обращений в год это2,4 млн ₽в год
Что за процесс и где он ломался
Поддержка оператора связи: 38 операторов, около 4 200 обращений в неделю, SLA — ответ за 5 минут. Поток растёт быстрее абонентской базы.
Половина обращений приходит по одной теме: статус заявки на подключение или ремонт.
Вопрос, на который отвечали
Что дешевле: нанять двенадцать операторов или убрать причину обращений?
Признаки, по которым стало понятно: дело не в людях
Планировали найм двенадцати операторов на год вперёд. Никто не проверял обратный ход: можно ли уменьшить сам поток, а не мощность под него. В планировании поток считался внешним и неуправляемым.
Как процесс превратили в имитационную модель
Моделировали поток обращений в поддержку оператора связи с учётом повторных обращений. Абонент возвращается в очередь с вероятностью 43%, если ожидание превышает 10 минут. Это создаёт петлю обратной связи: перегрузка порождает новые обращения, которые усиливают перегрузку.
Сравнивали четыре сценария: текущее состояние, найм 12 операторов, внедрение уведомлений о статусе заявки (снижение повторных обращений до 15%) и комбинированный вариант с автоответами по тарифам. Ключевой метрикой было выполнение SLA (решение за 8 минут) и стоимость обработки одного обращения.
Какие данные взяли и что честно допустили
- Поток
- экспоненциальное распределение, среднее время между обращениями 0,265 мин, пик 12:00–14:00 (×1,3)
- Ресурсы
- 38 операторов (базовый сценарий), стоимость часа 250 ₽, график 09:00–18:00, 5/2
- Этапы
- идентификация (1,5 мин) и решение (3,5 мин), нормальное распределение длительностей
- Повторные обращения
- 43% при ожидании > 10 мин (базовый сценарий), 15% при уведомлениях
- Не моделировали
- массовые аварии и сезонные всплески за пределами рабочего дня
Отчёт симуляции: что показал расчёт
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть БазовыйОтчёт | 38 операторов, нагрузка 90%. SLA выполняется лишь в 40% случаев, среднее время решения — 18,7 мин. |
| Плюс двенадцать операторов Отчёт | 50 операторов, нагрузка падает до 71%. SLA растёт до 59%, но стоимость обращения увеличивается на 29%. |
| Уведомления о статусе заявки РешениеОтчёт | 27 операторов, нагрузка 86%. SLA достигает 74%, время решения сокращается до 9,8 мин. |
| Уведомления и автоответы по тарифам Отчёт | 25 операторов, нагрузка 77%. SLA — 84%, но общая пропускная способность системы снижается. |
Было и стало
- Было
- Стало
Время от обращения до решения , мин
Работа операторов над одной проблемой , мин
Решение в пределах 8 минут (SLA) , %
Загрузка операторов , %
Стоимость обращения , ₽
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Время от обращения до решения , мин | 18,7 | 9,8 | −48% |
| Работа операторов над одной проблемой , мин | 8,7 | 5,9 | −33% |
| Решение в пределах 8 минут (SLA) , % | 40 | 74 | +33,9 п.п. |
| Загрузка операторов , % | 90 | 86 | −4,3 п.п. |
| Стоимость обращения , ₽ | 40 | 29 | −29% |
Что показал расчёт
Уведомления о статусе снижают нагрузку эффективнее найма
Внедрение уведомлений позволило сократить штат с 38 до 27 операторов, сохранив загрузку на уровне 86%. При этом SLA вырос с 40% до 74%, тогда как найм 12 операторов дал лишь 59% SLA при росте стоимости обращения на 29%.
Повторные обращения — главный драйвер перегрузки
В базовом сценарии 43% обращений — повторные. Сокращение этой доли до 15% за счёт уведомлений снизило среднее время решения с 18,7 до 9,8 минут. Операторы тратят на 33% меньше времени на обработку одного кейса.
Автоответы по тарифам дают меньший эффект
Комбинированный сценарий (уведомления + автоответы) снизил нагрузку до 77% и поднял SLA до 84%, но потребовал сокращения штата до 25 человек. Однако общая пропускная способность системы упала, что делает этот вариант менее устойчивым к росту потока.
Что оказалось не так, как считали
Что дешевле: нанять двенадцать операторов или убрать причину обращений?Найм операторов не решает проблему SLA. Добавление 12 операторов снизило загрузку с 90% до 71%, но SLA выросло лишь с 40% до 59%. В то же время сокращение штата до 27 человек при внедрении уведомлений подняло SLA до 74%. Причина — устранение повторных обращений, которые создают искусственный спрос на мощность.
Что решили сделать и что получилось
Выбрали сценарий «Уведомления о статусе заявки». Он обеспечивает оптимальный баланс между качеством обслуживания (SLA 74%) и эффективностью ресурсов (27 операторов, загрузка 86%). Найм 12 операторов отложен.
Внедрение уведомлений о статусе заявки снизило среднее время решения с 18,7 до 9,8 минут (−48%). Выполнение SLA выросло с 40% до 74% (+33,9 п.п.). Стоимость одного обращения упала с 40 до 29 ₽ (−29%). Штат сократился с 38 до 27 операторов при сохранении высокой загрузки (86%).
Приёмы оптимизации, которые здесь сработали
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Входной поток обычно считают внешним обстоятельством — тем, под что подстраивают мощность. В модели поток такой же параметр, как число операторов, и его можно двигать. Более того, только прогон показывает петлю «долго ждёт — пишет ещё раз»: в статистике обращений повторы неотличимы от новых.
Повторы — 43% потока, и в отчётах они неотличимы от новых обращений; после расшивки ожидания их остаётся 9%.
Где этот вывод не работает
Расчёт не покрывает массовые аварии: там поток создаётся событием, а не процессом, и уведомления его не снимают — нужен отдельный режим.
Частые вопросы по этому расчёту
Почему уведомление снимает 34% потока, если тема «статус» — это 40% обращений?
Уведомление закрывает типовые запросы о статусе, но не все обращения по этой теме исчезают. Однако главное — уходят повторные обращения. В базовом сценарии 43% обращений — повторные, в сценарии с уведомлениями — 15%. Это снижает общую нагрузку и время ожидания.
Повторные обращения — 43%. Это же просто нетерпеливые абоненты
Это петля обратной связи. Абонент пишет повторно, когда ждёт дольше 10 минут. Его повтор удлиняет очередь следующему. В базовом сценарии среднее время ожидания — 10 минут, в сценарии с уведомлениями — 4 минуты. Поэтому доля повторов падает с 43% до 15%.
Почему автоответы по тарифам дали втрое меньше, хотя автоматизировать их проще?
Тарифы — это 18% тем, статус — 40%. Но главное — повторные обращения. Уведомления о статусе снижают долю повторов с 43% до 15%, автоответы по тарифам — до 12%. Однако комбинированный сценарий требует сокращения штата до 25 человек, что снижает устойчивость системы к росту потока.
Штат сократился на одиннадцать человек. Это увольнения?
Расчёт сравнивает потребность: 27 операторов против 38 при том же обещании по SLA. Чем закрывать разницу — вопрос отдельный, обычно это отказ от найма на открытые вакансии и естественная текучесть. План найма на двенадцать человек заменили одной доработкой личного кабинета.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.