Как прогнозировать объём обращений в поддержку

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

Прогноз не обязан предсказывать каждый всплеск. Он должен быть полезнее простого среднего и достаточно понятным, чтобы руководитель объяснил изменение смен, резерва или эскалаций.

Определите единицу спроса

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

Так длинные переписки не раздувают количество поступлений. Диалог из десяти сообщений и диалог из двух сообщений могут быть одним поступлением, хотя дальнейшие трудозатраты различаются. Объём и усилия нужно измерять отдельно.

Помечайте диалоги, которые автоматизация завершает без участия сотрудника. В рекомендациях Microsoft по прогнозированию сервиса диалоги, полностью обработанные ИИ, исключаются из прогноза для подбора персонала. Считайте общий клиентский спрос и спрос на человеческую работу отдельно. Тогда внедрение автоматизации не будет выглядеть как исчезновение интереса клиентов.

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

Используйте два горизонта

Недельный или месячный прогноз помогает планировать найм, отпуска, кампании и внешнее покрытие. Дневной или интервальный прогноз нужен для смен, перерывов, живых очередей и дежурств. Одна модель редко одинаково хорошо служит обоим решениям.

Создайте дневной прогноз на несколько недель или месяцев, а затем ближайший прогноз с интервалом, на который команда способна отреагировать, например 30 или 60 минут. Microsoft поддерживает отдельные дневные и 15-минутные прогнозы по похожей причине. Мелкий интервал полезен только при достаточном объёме данных и возможности быстро менять покрытие.

Разделяйте каналы и очереди, если это меняет решение о людях. Общие 300 обращений мало говорят, если 100 из них требуют немедленного ответа, а 200 асинхронны. Однако прогноз по каждому тегу создаст нестабильный шум. Начните с канала, языка, рынка или очереди, где накоплена история и предусмотрена отдельная операционная реакция.

Постройте понятную базу

До сложных инструментов создайте прозрачный ориентир. Для каждого дня недели или рабочего интервала возьмите медиану поступлений за несколько недавних сопоставимых недель. Одиночный сбой или акция искажает медиану меньше, чем среднее.

Используйте полные недели, соответствующие текущей схеме обслуживания. Если новый канал появился недавно, не смешивайте месяцы до запуска с новым режимом. Рядом с прогнозом храните заметку о пробелах данных, изменениях маршрутизации и исключениях.

Сезонность должна быть видимой. Сравнивайте понедельники с понедельниками, праздники с похожими праздниками, а регулярные даты счетов или доставок с их обычным местом в месяце. Microsoft поддерживает календари праздников и прогнозы по каналу или очереди, но предупреждает, что неожиданные тенденции снижают точность.

Простая процедура выглядит так:

1. Посчитайте действительные новые диалоги по дням и каналам.
2. Выберите последние сопоставимые недели.
3. Рассчитайте медиану для каждого дня или интервала.
4. Сохраните исходную базу до ручных корректировок.

Последний шаг показывает, ошиблась история или экспертное предположение.

Учитывайте известные события открыто

Ведите небольшой реестр запусков, кампаний, дат выставления счетов, плановых работ, праздников и закрытия функций. В руководстве Zendesk по прогнозированию нагрузки предусмотрены поправки на маркетинговые кампании и завершение поддержки функций.

Записывайте название события, затронутую очередь, начало, конец, ожидаемое изменение, доказательство, владельца и дату предположения. Добавляйте поправку к базе, не переписывая историю. После события фиксируйте фактический эффект и переносите его только на действительно сопоставимые события.

Если два запуска дали разный рост, подготовьте низкий, основной и высокий сценарии. Честный диапазон полезнее одного числа с ложной точностью.

Проверьте прогноз на прошлом

Представьте, что несколько прошлых недель ещё не наступили. Для каждой постройте прогноз только из информации, доступной до её начала, затем сравните с фактом. Такой последовательный тест обнаруживает методы, которые выглядят точными из-за случайного использования будущих данных.

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

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

Планируйте диапазон и действия

Публикуйте низкий, основной и высокий прогноз вместе с предпосылками. Microsoft показывает нижние и верхние границы вокруг прогноза. Даже ручной расчёт выигрывает от честного отображения неопределённости.

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

Превратите объём в решение о людях

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

Руководство по вместимости сотрудника поддержки объясняет, как измерить безопасную активную нагрузку. Используйте эти данные вместе с диапазоном поступлений вместо универсальной нормы диалогов на человека.

В общем ящике DripTell канал, владелец, статус, теги и контекст клиента остаются рядом с диалогом. Последовательные поля помогают получить чистую историю спроса. Начните с еженедельного обзора, фиксируйте предположения и используйте ошибку для следующего плана.

Часто задаваемые вопросы

Сколько истории нужно для прогноза поддержки

Истории должно хватать для выявления недельной и сезонной структуры, но не нужно возвращаться к устаревшей модели работы. Несколько полных недавних недель подходят для первой базы. Более длинный ряд помогает с праздниками и годовыми пиками, если каналы, маршрутизация и определения данных оставались сопоставимыми.

Нужно ли считать автоматические диалоги

Включайте их в общий спрос клиентов, но отделяйте полностью автоматические решения от обращений, требующих человека. Так видно реальное изменение интереса, а внедрение автоматизации не искажает прогноз персонала.

Как часто обновлять прогноз поддержки

Обновляйте ближайший прогноз не реже раза в неделю и после событий, существенно меняющих спрос или доступность. Дальний прогноз пересматривайте ежемесячно. Перестраивайте базу после устойчивых изменений каналов, маршрутизации, автоматизации, поведения клиентов или качества данных.