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

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

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

Накопившиеся обращения не образуют одну очередь

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

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

Сначала отнесите каждый диалог к одному состоянию восстановления:

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

Не создавайте расплывчатый статус «проверено». Статус должен показывать, кто действует дальше.

Сначала стабилизируйте новые обращения

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

Это не значит, что каждое новое сообщение нужно обработать раньше любого старого. Задача в том, чтобы не создать вторую очередь. Считайте новые поступления и выполненные действия отдельно. Если пришло 80 диалогов, а команда завершила 60 действий, backlog продолжает расти, каким бы активным ни выглядел отчёт.

Назначьте одного координатора восстановления на день. Он следит за оперативным потоком, перераспределяет специалистов и не позволяет сотрудникам выбирать только простые старые обращения.

Сортируйте по ущербу сроку и возрасту

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

Применяйте последовательные правила, а не один непрозрачный балл:

1. В первую очередь обрабатывайте достоверный риск вреда, нарушение требований, угрозу безопасности и остановку важной услуги.
2. Внутри этой группы смотрите на ближайший реальный срок.
3. Затем учитывайте, сколько ждёт клиент.
4. При равенстве выбирайте самое раннее обещанное обновление.

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

Создайте карточку восстановления для каждого обращения

Представим магазин с 420 открытыми диалогами после сбоя в выполнении заказов. Не поручайте сотрудникам просто «разобрать очередь». Для каждого проверенного диалога заполните пять полей:

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

«Склад проверяет» не является следующим действием. Формулировка «Мария подтвердит сканирование замены до 15:00 и сообщит клиенту» уже подходит.

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

Свяжитесь с клиентом до закрытия старого диалога

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

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

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

Считайте повторные открытия доказательством

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

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

Главный показатель восстановления не «сколько тикетов закрыто», а сколько старой работы перешло в честное состояние без новой волны повторных обращений.

Завершите работу более надёжной базовой системой

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

В общем inbox DripTell диалоги можно фильтровать по владельцу, статусу, команде, каналу и признаку прочтения, сохраняя заметки и контекст клиента рядом с перепиской. Это поддерживает карточку восстановления, но операционные решения всё равно принимает команда. Если backlog разбросан по разным каналам, разберите процесс восстановления вместе с нами, прежде чем автоматизировать правила закрытия.

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

Можно ли массово закрыть старые обращения

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

Какие обращения нужно брать первыми

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

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

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