Ритейл и e-commerceВыдержим ли пик
Выдержит ли служба поддержки пик распродажи?
Прогноз обращений на распродажу вырос вчетверо. Что встанет первым и сколько людей нужно на самом деле.
Что дал расчёт
- Отказы в чате
- было
346%−28 п.п. - Ожидание в чате в пике
- было
142мин−86% - Разбор почты после пика
- было
72дней−71%
На потоке 260 000 обращений в год это4,4 млн ₽в год
Что за процесс и где он ломался
Поддержка интернет-магазина: чат, почта и телефон, 26 операторов. В дни распродажи поток обращений вырастает в четыре раза за двое суток.
Терпение клиента у каналов разное: в чате его хватает на минуты, в почте — на часы. Поэтому одинаковая перегрузка ломает каналы по-разному.
Вопрос, на который отвечали
Выдержит ли служба поддержки пик распродажи?
Признаки, по которым стало понятно: дело не в людях
В прошлый раз чат встал на шесть часов, а почта разгребалась неделю. Готовились по среднему прогнозу и не проверяли, что именно сломается первым.
Как процесс превратили в имитационную модель
Смоделировали три канала с разными длительностями и терпением клиентов, профиль пика по часам и работу операторов по сменам с возможностью переключения между каналами.
Уход клиента задан явно: не дождавшись ответа, он бросает обращение и пишет снова — то есть перегрузка сама себе добавляет работы. Без этой петли модель показала бы слишком благополучную картину.
Какие данные взяли и что честно допустили
- Пик
- ×4 к обычному потоку в течение 48 часов
- Длительность
- чат 7 минут, почта 9, телефон 4
- Терпение клиента в чате
- 3 минуты до отказа
- Не моделировали
- обращения по доставке после распродажи — это отдельная волна
Отчёт симуляции: что показал расчёт
Здесь будет живой отчёт симуляции
Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть Базовый | 26 операторов, каналы закреплены |
| Плюс 10 временных операторов | Распределены поровну по каналам |
| Плюс 10 с приоритетом чата | Усиление там, где терпение клиента короче |
| Переключаемые операторы | Свободные помогают перегруженному каналу |
Было и стало
- Было
- Стало
Отказы в чате , %
Ожидание в чате в пике , мин
Разбор почты после пика , дней
Временных операторов , чел
Стоимость обращения , ₽
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Отказы в чате , % | 34 | 6 | −28 п.п. |
| Ожидание в чате в пике , мин | 14 | 2 | −86% |
| Разбор почты после пика , дней | 7 | 2 | −71% |
| Временных операторов , чел | 10 | 6 | −4 |
| Стоимость обращения , ₽ | 96 | 79 | −18% |
Что показал расчёт
Первым ломается чат, а не почта
У клиента в чате три минуты терпения: отказы начинаются раньше, чем очередь становится заметной.
Переключаемые операторы дают больше, чем плюс четыре человека
Гибкость важнее численности, когда пик приходит по одному каналу.
Почта — это хвост пика: её разгребают, когда чат уже успокоился
Её разбор растягивается на неделю, но клиент этого почти не замечает.
Что оказалось не так, как считали
Выдержит ли служба поддержки пик распродажи?Готовились не к тому. Равномерное усиление всех каналов оставляет чат в отказах, хотя формально людей достаточно. Помогло не число, а право переключаться между каналами.
Что решили сделать и что получилось
Ввели переключение операторов между каналами и приоритет чата в пик. Профиль пика брали приёмом «Прогноз спроса», запас — приёмом «Резерв мощности», рассчитанным по каналу с самым коротким терпением клиента.
План найма сократили с десяти временных операторов до шести.
Приёмы оптимизации, которые здесь сработали
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Каналы с разным терпением клиента ломаются в разном порядке. Средняя нагрузка не показывает, какой из них встанет первым — это видно только в прогоне с поканальными очередями.
А порядок здесь и есть решение: он говорит, куда ставить резерв и какой канал закрывать первым, если людей на все не хватит.
Первым встал чат: отказы 34% и ожидание 14 минут в пике, тогда как почту разгребали ещё семь дней после распродажи.
Где этот вывод не работает
Прогноз «×4» взят из прошлой распродажи. Если пик окажется острее, приоритет чата сохранится, а число временных операторов придётся пересчитать.
Частые вопросы по этому расчёту
Почему не нанять с запасом?
Запас из 10 человек равномерно стоит денег и всё равно не спасает, если распределён не в том канале: чат ломается на 3 минутах терпения, почта накапливается часами. При пике ×4 за 48 часов нужно приоритизировать гибкостью из 26 операторов.
Если мы наймём 10 человек равномерно по каналам, почему чат сломается?
Потому что чат первым ломается: клиент в чате терпит 3 минуты, в почте часы. Распределив людей поровну, вы поднимаете ожидание в чате, но отказы упадут только до 14%, когда нужно 6%. Переключаемые операторы дают гибкость, которой не может дать число.
Прогноз был ×4 к обычному потоку, а вышло ×5 — как пересчитать?
При ×5 система переходит в другой режим: очередь перестаёт рассасываться в конце дня и накапливается за 48 часов пика. Это качественный переход за порог устойчивости. Нужно закрыть приём заказов или добавить третью смену.
Почта разгребается целую неделю — это угроза для следующей распродажи?
Нет, потому что это хвост пика, не сам пик. Клиент в почте терпит часы, поэтому она накапливается, но клиента почти не расстраивает — главный риск в чате (−86% ожидания в пике). Если держать чат приоритетным, почта не испортит репутацию.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.