Как готовиться к пикам обращений

Маркетинг ставит рассылку на вторник, 10:00. В 10:17 поддержка уже отвечает про промокод, который «не применился», про счёт, который «не пришёл», и про кнопку, которой нет в мобильной версии.

Для клиента это один вопрос. Для поддержки — волна, к которой никто не готовился, хотя дата была в календаре неделю назад.

Пики обращений редко появляются из воздуха. Чаще они идут за событиями бизнеса: запуском акции, дедлайном оплаты, релизом, началом сезона, вебинаром, массовой рассылкой, изменением тарифа. Если поддержка узнаёт об этом вместе с клиентами, она всё время работает в режиме пожара.

Пик начинается не в очереди, а в календаре

Очередь показывает уже случившееся. Календарь показывает то, что почти наверняка случится.

У поддержки должен быть список событий, после которых люди пишут чаще обычного. Не абстрактно «у нас бывает много обращений», а привязка к дате, часу и источнику: рассылка ушла в 10:00, оплата списывается первого числа, запись на курс открывается в понедельник, новый кабинет включают группе клиентов в среду.

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

Цена у такого подхода есть. Придётся ходить на чужие планирования или хотя бы просить короткий список событий на неделю. Придётся задавать неудобные вопросы: что поменяется для клиента, кому уйдёт письмо, что будет написано в теме, куда ведёт кнопка. Это занимает время до пика, зато экономит разборы во время него.

Полезно держать простой реестр ожидаемых волн:

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

Не нужно превращать это в большой регламент. Достаточно таблицы, где видно: в четверг после 12:00 ждём вопросы по доставке, потому что выйдет письмо клиентам из региона, где поменялись сроки.

Повторяющийся рисунок виден по дням и часам

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

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

Если смотреть только среднее число обращений за месяц, рисунок пропадает. Месяц выглядит терпимо, а вторник с 10:00 до 13:00 всё равно срывает первую линию. Поэтому важны разрезы по дням недели и часам, а не только общая сумма.

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

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

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

Здесь легко увлечься деталями и завести тридцать категорий. На пике это только мешает: оператор тратит время на выбор правильного ярлыка. Лучше иметь несколько понятных групп, по которым реально принимаются решения. Мы отдельно разбирали, почему пять рабочих категорий полезнее большого справочника.

Первую линию усиливают до того, как очередь покраснела

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

Перед ожидаемой волной стоит проверить три вещи: ответы, маршруты и дежурства.

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

Маршруты — это правила, куда уходит обращение. Во время пика плохо работает схема «кто увидел, тот взял». Быстрые вопросы зависают рядом со сложными, а опытные операторы тратят время на ручное назначение. Если поток уже заметный, помогают простые правила: очередь, наименее загруженный оператор или специализация. Подробно про это есть отдельный разбор: как распределять обращения без ручного перетаскивания.

Дежурства — это люди, которые доступны именно в момент волны. Не «если что, напишите в общий чат», а конкретно: кто отвечает за оплату, кто за техническую ошибку, кто может быстро подтвердить формулировку для клиента.

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

Есть ещё один риск: подготовить материалы и не объяснить команде, когда ими пользоваться. Шаблон сам по себе не помогает, если оператор не знает, в каком случае его вставлять. Статья в базе не спасает, если в ней написано для внутреннего отдела, а не для клиента. Перед пиком лучше пройти один-два сценария вслух: клиент спрашивает это, мы отвечаем так, если возражает — делаем вот это.

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

После волны важно разобрать не героизм, а причины

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

Разбор не должен превращаться в поиск виноватых. Нужны простые вопросы.

Что мы знали заранее, но не подготовили? Например, дата рассылки была известна, а текст поддержки увидела только после отправки.

Какие вопросы повторялись чаще всего? Если двадцать клиентов спросили одно и то же, это не «клиенты невнимательные». Значит, письмо, интерфейс или статья не ответили на очевидный вопрос.

Где очередь начала расти? В конкретном канале, категории, часу, у конкретной группы операторов. Если пик пришёл в чат, а усиление поставили на почту, команда старалась, но не там.

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

Какие обращения переоткрылись? После пика часто закрывают быстрее обычного, и часть клиентов возвращается: ответ был неполным, следующий шаг неясен, срок не назван. Не стоит считать это капризом клиента. Мы уже писали, почему переоткрытие часто показывает дыру в первом ответе.

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

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

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

В DeskAI для такой подготовки можно смотреть объём и динамику обращений, график «поступило vs решено», пиковые часы по дням недели и часам, нагрузку по агентам, каналам и категориям; а все каналы поддержки собирать в одной очереди, чтобы во время волны не искать обращения по разным вкладкам.