ТелекомСтоит ли автоматизировать
Что дешевле: нанять двенадцать операторов или убрать причину обращений?
Сорок процентов обращений — «где мой заказ». Такие обращения не обрабатывают, их не создают.
Что дал расчёт
- Обращений в неделю
- было
4 2002 770шт−34% - Операторов
- было
3827чел−29% - Выполнение SLA 5 минут
- было
7893%+15 п.п.
На потоке 218 400 обращений в год это1,3 млн ₽в год
Что за процесс и где он ломался
Поддержка оператора связи: 38 операторов, около 4 200 обращений в неделю, SLA — ответ за 5 минут. Поток растёт быстрее абонентской базы.
Половина обращений приходит по одной теме: статус заявки на подключение или ремонт.
Вопрос, на который отвечали
Что дешевле: нанять двенадцать операторов или убрать причину обращений?
Признаки, по которым стало понятно: дело не в людях
Планировали найм двенадцати операторов на год вперёд. Никто не проверял обратный ход: можно ли уменьшить сам поток, а не мощность под него. В планировании поток считался внешним и неуправляемым.
Как процесс превратили в имитационную модель
Смоделировали поток по темам обращений, работу операторов и — отдельно — повторные обращения: абонент, не получивший ответа, возвращается и создаёт ещё одно.
Долю тем, устранимых уведомлением о статусе, задали параметром сценария. Это и позволило сравнить два принципиально разных решения: добавить мощность или убрать спрос на неё.
Какие данные взяли и что честно допустили
- Поток
- 4 200 обращений в неделю, профиль по часам — фактический
- Темы
- статус 40%, тарифы 18%, неисправность 27%, прочее 15%
- Повторное обращение при ожидании больше 10 минут
- 43%
- Не моделировали
- обращения при массовых авариях — для них отдельный режим
Отчёт симуляции: что показал расчёт
Здесь будет живой отчёт симуляции
Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть Базовый | 38 операторов, уведомлений о статусе нет |
| Плюс двенадцать операторов | Наращивание мощности |
| Уведомления о статусе заявки | Абонент узнаёт статус без обращения |
| Уведомления и автоответы по тарифам | Снятие двух самых массовых тем |
Было и стало
- Было
- Стало
Обращений в неделю , шт
Операторов , чел
Выполнение SLA 5 минут , %
Повторных обращений , %
Стоимость обращения , ₽
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Обращений в неделю , шт | 4 200 | 2 770 | −34% |
| Операторов , чел | 38 | 27 | −29% |
| Выполнение SLA 5 минут , % | 78 | 93 | +15 п.п. |
| Повторных обращений , % | 43 | 9 | −34 п.п. |
| Стоимость обращения , ₽ | 94 | 88 | −6% |
Что показал расчёт
Уведомление о статусе снимает 34% потока — это эквивалент одиннадцати операторов
Причём операторов, которых не нужно нанимать, обучать и удерживать.
Повторные обращения — 18% потока, и они исчезают вместе с ожиданием
Перегрузка сама себе добавляет работы: чем дольше ждёт абонент, тем больше обращений он создаёт. Это петля, а не линейная зависимость.
Автоответы по тарифам дают втрое меньше, чем уведомления о статусе
Автоматизировать имеет смысл не то, что проще автоматизируется, а то, что создаёт поток.
Что оказалось не так, как считали
Что дешевле: нанять двенадцать операторов или убрать причину обращений?Одиннадцать ставок закрыло одно уведомление. Абонент получает его раньше, чем успевает решить написать в поддержку.
Что решили сделать и что получилось
Запустили уведомления о статусе заявки и отложили найм. Снижение самого потока считали приёмом «Снизить поток», эффект автоответов — приёмом «Автоматизировать задачу».
План найма на двенадцать человек заменили одной доработкой личного кабинета. Штат сократился на одиннадцать человек, а SLA вырос на 15 пунктов.
Приёмы оптимизации, которые здесь сработали
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Входной поток обычно считают внешним обстоятельством — тем, под что подстраивают мощность. В модели поток такой же параметр, как число операторов, и его можно двигать. Более того, только прогон показывает петлю «долго ждёт — пишет ещё раз»: в статистике обращений повторы неотличимы от новых.
Повторы — 43% потока, и в отчётах они неотличимы от новых обращений; после расшивки ожидания их остаётся 9%.
Где этот вывод не работает
Расчёт не покрывает массовые аварии: там поток создаётся событием, а не процессом, и уведомления его не снимают — нужен отдельный режим.
Частые вопросы по этому расчёту
question
question
question
question
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.