Где ставить порог эскалации на вторую линию техподдержки?

Что дал расчёт

Среднее время решения: было6841мин−40%
Доля эскалаций: было4844%−4 п.п.
Загрузка второй линии: было6179%+18 п.п.

На потоке 44 530 обращений в год это20,0 тыс часовв год

Что за процесс и где он ломался

Техподдержка SaaS-продукта: первая линия из 14 человек, вторая — из 5. Регламент требует держать обращение на первой линии до 40 минут, потом эскалировать.

Порог в 40 минут никто не считал: его записали при запуске поддержки и с тех пор не пересматривали, хотя продукт и состав обращений изменились.

Вопрос, на который отвечали
Где ставить порог эскалации на вторую линию техподдержки?

Признаки, по которым стало понятно: дело не в людях

Половина обращений всё равно уходит на вторую линию — но уже после сорока минут ожидания. Порог задавали интуитивно, и он оказался дороже, чем кажется.

Как процесс превратили в имитационную модель

В модели порог эскалации — параметр: от него зависит и загрузка первой линии, и поток на вторую. Прогнали пять значений от 10 до 60 минут.

Важна не только доля эскалаций, но и то, что первая линия тратит на обращение до передачи. Это время в модели теряется целиком: вторая линия начинает разбор заново.

Какие данные взяли и что честно допустили

Поток обращений: 122 в сутки, профиль по часам — фактический
Доля решаемых первой линией: 52% при текущем пороге
Решение на второй линии: 25 минут при пороге 40 и 35 минут при пороге 25 — часть разбора первая линия не успевает сделать
Не моделировали: обращения по инцидентам — у них отдельный маршрут

Отчёт симуляции: что показал расчёт

Здесь будет живой отчёт симуляции

Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.

Какие сценарии прогнали и чем они отличались

Сценарии, прогнанные в модели
Сценарий	Что меняли
Как есть: порог 40 минут Базовый	Текущий регламент
Порог 15 минут	Ранняя передача на вторую линию
Порог 25 минут	Промежуточное значение
Порог 60 минут	Первая линия держит дольше

Было и стало

Сравнение «было / стало» по каждой метрике. У метрик разные единицы, поэтому каждая пара показана в своём масштабе.

Было
Стало

Среднее время решения , мин
68
41−40%
Доля эскалаций , %
48
44−4 п.п.
Загрузка второй линии , %
61
79+18 п.п.
Обращений в очереди в пике , шт
37
14−62%

Ключевые метрики процесса до и после изменения
Метрика	Было	Стало	Изменение
Среднее время решения , мин	68	41	−40%
Доля эскалаций , %	48	44	−4 п.п.
Загрузка второй линии , %	61	79	+18 п.п.
Обращений в очереди в пике , шт	37	14	−62%

Что показал расчёт

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

Что оказалось не так, как считали

Обучение первой линии сдвинуло бы долю эскалаций на считаные пункты. Время ожидания осталось бы прежним: его задаёт порог передачи на вторую линию, и квалификация здесь ни при чём.
Где ставить порог эскалации на вторую линию техподдержки?

Что решили сделать и что получилось

Порог снизили до 25 минут. Ранний отсев безнадёжных типов обращений заложили приёмом «Усилить ранний отсев», а сам сдвиг долей между линиями считали приёмом «Изменить развилку».

Регламент переписали по посчитанному порогу, а не по ощущению руководителя смены.

Приёмы оптимизации, которые здесь сработали

Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет

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

Равновесие нашлось при загрузке второй линии 79% вместо прежних 61%: среднее время решения упало с 68 минут до 41.

Где этот вывод не работает

Расчёт верен при текущем составе второй линии. Если она сократится, оптимальный порог сместится вверх — модель придётся прогнать заново.

Частые вопросы по этому расчёту

Почему не обучить первую линию решать больше?

Это отдельный сценарий с другой стоимостью. Расчёт показывает, что даже при росте решаемости на 10 п.п. эффект по времени составит 8 минут, тогда как смена порога с 40 минут на 25 минут даёт 27 минут выигрыша — то есть в три раза больше результата без затрат на обучение.

Если установить порог эскалации на 30 минут вместо 25, что произойдёт с очередью?

Очередь вырастет: вторая линия упадёт с 79% на более высокую загрузку, и обращения начнут накапливаться. Расчёт показывает, что 25 минут — точка минимума времени решения. При 30 минутах клиент проводит больше времени на первой линии без результата, не сокращая нагрузку на вторую.

Почему доля эскалаций почти не двигается (−4 п.п.) при смене порога?

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

Может ли вторая линия взять ещё нагрузки, если порог ещё выше поднять?

По расчёту — до 89% загрузки включительно, дальше очередь начинает расти экспоненциально. Запас есть: при 79% загрузке очередь составляет 14 обращений, а простой низкий. Выше 89% система перейдёт в режим деградации, как это было до оптимизации.

Ваш процесс, ваши числа

Покажем на вашем процессе

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

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

Показать на моём процессе Посмотреть другие кейсы

Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.