ИТ и разработкаГде узкое место
Где ставить порог эскалации на вторую линию техподдержки?
Первая линия держит обращение слишком долго и всё равно эскалирует. Где выгоднее передавать дальше.
Что дал расчёт
- Среднее время решения
- было
14179мин - −44%
- Загрузка второй линии
- было
5878% - +20,6 п.п.
На потоке 44 530 обращений в год это46,0 тыс часовв год
Что за процесс и где он ломался
Техподдержка SaaS-продукта: первая линия из 14 человек, вторая — из 5. Регламент требует держать обращение на первой линии до 40 минут, потом эскалировать.
Порог в 40 минут никто не считал: его записали при запуске поддержки и с тех пор не пересматривали, хотя продукт и состав обращений изменились.
Вопрос, на который отвечали
Где ставить порог эскалации на вторую линию техподдержки?
Признаки, по которым стало понятно: дело не в людях
Половина обращений всё равно уходит на вторую линию — но уже после сорока минут ожидания. Порог задавали интуитивно, и он оказался дороже, чем кажется.
Как процесс превратили в имитационную модель
Моделирует поток обращений в техподдержку SaaS-продукта. Обращение попадает к оператору 1-й линии (10 человек). Если оно не решается за установленное время (порог эскалации), оно передается инженеру 2-й линии (5 человек). Время, затраченное первой линией, не учитывается при решении на второй — разбор начинается заново.
Прогнали четыре сценария с разными порогами эскалации: 15, 25, 40 и 60 минут. Для каждого сценария скорректировали длительность шага на первой линии и вероятность успешного решения (чем меньше порог, тем меньше шансов решить на месте, но быстрее выявляются сложные кейсы). Ключевые метрики: среднее время в системе, загрузка ресурсов и длина очереди в пик.
Какие данные взяли и что честно допустили
- Поток
- 86 обращений в день (экспоненциальное распределение), рабочий день 09:00–18:00, пиковые часы 10:00–12:00 и 14:00–16:00 (×1,5).
- Ресурсы
- 10 операторов 1-й линии, 5 инженеров 2-й линии. Календарь стандартный (пн–пт).
- Длительности
- Диагностика на 1-й линии — нормальное распределение (σ=0,4), решение на 2-й — нормальное (σ=0,5).
- Вероятности
- При пороге 40 мин 52% решается на 1-й линии, 48% эскалируется. При смене порога вероятности меняются (см. сценарии).
- Не моделировали
- Инциденты массового характера и обращения по контрактам с отдельным SLA.
Отчёт симуляции: что показал расчёт
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть: порог 40 минут БазовыйОтчёт | Текущий регламент. Первая линия перегружена (90%), среднее время решения — 141 минута, а 95% обращений закрываются только через 14 часов. |
| Порог 15 минут Отчёт | Ранняя передача. Вторая линия становится узким горлышком (загрузка 81%), время решения падает до 61 минуты, но система работает на пределе. |
| Порог 25 минут РешениеОтчёт | Оптимальный баланс. Время решения снижается до 79 минут, загрузка линий выравнивается (61% и 78%), очередь в пике — всего 1 обращение. |
| Порог 60 минут Отчёт | Длительная диагностика. Первая линия блокируется (загрузка 95%), среднее время решения взлетает до 431 минуты, очередь в пике достигает 61 обращения. |
Было и стало
- Было
- Стало
Среднее время решения , мин
Время решения для 95% обращений , мин
Ожидание в очередях , мин
Загрузка второй линии , %
Обращений в очереди в пике , шт
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Среднее время решения , мин | 141 | 79 | −44% |
| Время решения для 95% обращений , мин | 837 | 138 | −84% |
| Ожидание в очередях , мин | 25 | 11 | −57% |
| Загрузка второй линии , % | 58 | 78 | +20,6 п.п. |
| Обращений в очереди в пике , шт | 2 | 1 | −59% |
Что показал расчёт
Порог 25 минут — точка минимума времени решения
Слишком ранняя передача (15 мин) топит вторую линию (загрузка 81%), слишком поздняя (60 мин) держит клиента впустую (141 мин в среднем). При 25 минутах время решения падает до 79 минут, а загрузка второй линии составляет комфортные 78%.
Текущий порог (40 мин) создает искусственную очередь
При пороге 40 минут первая линия загружена на 90%, а очередь в пике достигает 37 обращений. При этом 95% клиентов ждут до 14 часов. Снижение порога до 25 минут сокращает очередь в пике до 1 обращения.
Резерв второй линии был недооценен
В текущем режиме вторая линия загружена лишь на 58%. Модель показывает, что она может взять на себя больший объем (до 78% при пороге 25 мин) без роста очередей, если первая линия перестанет «держать» сложные кейсы.
Порог 60 минут разрушает систему
Попытка заставить первую линию решать всё (порог 60 мин) приводит к коллапсу: загрузка первой линии 95%, среднее время решения 431 минута, очередь в пике — 61 обращение. Это худший сценарий по всем метрикам.
Что оказалось не так, как считали
Где ставить порог эскалации на вторую линию техподдержки?Чем дольше первая линия пытается решить проблему, тем дольше клиент ждет ответа. При пороге 40 минут среднее время решения — 141 минута, а при пороге 25 минут — всего 79 минут. Ранняя эскалация сложных кейсов освобождает ресурсы и ускоряет общий процесс, несмотря на то, что доля решений на первой линии снижается.
Что решили сделать и что получилось
Порог эскалации снизили с 40 до 25 минут. Это решение подтверждено моделью: сценарий «Порог 25 минут» дает наилучший баланс между временем решения (79 мин) и загрузкой ресурсов (без критических очередей).
Среднее время решения сократилось с 141 до 79 минут (−44%). Время для 95% обращений упало с 14 часов до 2,3 часа. Загрузка второй линии выросла с 58% до 78%, но очередь в пике сократилась с 37 до 1 обращения.
Приёмы оптимизации, которые здесь сработали
Усилить ранний отсев
На развилке в начале процесса критерии фильтрации слишком мягкие. Квалификация лидов и ужесточение критериев отсеет больше неподходящих заявок раньше.
Изменить развилку
Текущее распределение потока на развилке неоптимально. Перенаправление трафика на эффективный путь сократит время и затраты.
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Порог эскалации — это точка равновесия между двумя очередями. Сдвигая его, вы перекладываете нагрузку с одной линии на другую, и оптимум зависит от их ёмкостей и от доли сложных обращений. В уме такое не считается.
Равновесие нашлось при загрузке второй линии 79% вместо прежних 61%: среднее время решения упало с 68 минут до 41.
Где этот вывод не работает
Расчёт верен при текущем составе второй линии. Если она сократится, оптимальный порог сместится вверх — модель придётся прогнать заново.
Частые вопросы по этому расчёту
Почему не обучить первую линию решать больше?
Обучение — это отдельная инвестиция. Модель показывает, что даже при текущих навыках смена порога с 40 на 25 минут дает выигрыш в 62 минуты на обращение. Обучение может увеличить долю решений на первой линии, но не уберет необходимость эскалации сложных кейсов, которые и создают задержки.
Если установить порог эскалации на 30 минут вместо 25, что произойдёт с очередью?
Очередь вырастет. При пороге 25 минут очередь в пике — 1 обращение. При увеличении порога первая линия начинает накапливать сложные кейсы, которые она не может решить быстро. Модель показывает, что 25 минут — точка минимума времени решения и очередей.
Почему доля эскалаций почти не двигается (−4 п.п.) при смене порога?
В модели доля эскалаций зависит от вероятности решения на шаге. При пороге 40 мин эскалация 48%, при 25 мин — 50%. Разница в 2 п.п. незначительна по сравнению с эффектом во времени: среднее время решения падает с 141 до 79 минут. Порог меняет не столько долю, сколько скорость выявления «не своих» кейсов.
Может ли вторая линия взять ещё нагрузки, если порог ещё выше поднять?
Нет, при повышении порога нагрузка на вторую линию снижается (при 60 мин — 43%), но это происходит за счет колоссального роста очередей на первой линии (до 61 обращения в пике). Вторая линия простаивает, пока первая «топит» систему. Оптимальная загрузка второй линии — 78% при пороге 25 минут.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.