Статусы обращений клиентов полезны, когда по ним видно, что происходит с вопросом и кто должен сделать следующий шаг. Универсальное «в работе» не отличает подготовку ответа от ожидания клиента, проверки специалиста или исполнения уже принятого решения. Руководитель видит занятую очередь, но не понимает, где требуется помощь.
Хороший словарь статусов короткий и проверяемый. Он не обязан описывать каждое действие сотрудника. Его задача — различать состояния, которые требуют разного управления. Подробности остаются в задаче, комментарии и ближайшем обязательстве.
Отделите состояние от других признаков
Статус отвечает на вопрос «что сейчас происходит с обращением». Ответственный показывает, кто ведёт вопрос. Приоритет — насколько срочно он требует внимания. Тема — о чём обращение. Причина ожидания поясняет препятствие.
Не создавайте статусы «у Анны», «важное», «доставка» и «вторая попытка» в одной последовательности. В такой модели невозможно сравнить работу: признаки относятся к разным измерениям и могут одновременно быть верными.
Для начала достаточно нескольких состояний с понятными условиями входа и выхода. Если команда постоянно спорит, куда отнести вопрос, уточняйте определение, а не добавляйте ещё один похожий статус.
Рабочий словарь из шести состояний
Новое. Вопрос зарегистрирован, но ещё не разобран. Выход: определён предмет, назначен владелец и выбран следующий шаг. Само наличие сообщения не означает, что команда приняла обязательство по решению.
В исполнении. Команда выполняет действие, необходимое для ответа или согласованного результата. У обращения есть ближайшая задача, исполнитель и срок.
Ожидает клиента. Запрошены конкретные данные или решение, без которых нельзя продолжить выбранный шаг. В записи видно, что именно требуется и когда команда проверит ответ.
Ожидает специалиста. Вопрос передан конкретному участнику, который должен вернуть определённый результат. Владелец клиентской коммуникации остаётся назначенным.
Решено, ожидает подтверждения. Результат передан клиенту, но по принятому для этого типа вопроса порядку требуется подтверждение. Этот статус нужен не для каждого процесса.
Закрыто. Выполнен установленный критерий завершения либо зафиксировано обоснованное прекращение работы. Причина закрытия должна отличать решение, отказ клиента и ошибочную запись.
Учебный пример очереди из двадцати четырёх обращений
Все данные условные. В пятницу на 12:00 команда делает срез текущей рабочей группы: три обращения новые, семь в исполнении, пять ожидают клиента, четыре ожидают специалиста, пять закрыты. В состоянии «решено, ожидает подтверждения» на этот момент нет записей.
Баланс: 3 + 7 + 5 + 4 + 5 = 24. Открытых обращений девятнадцать: 24 − 5 = 19. Из них девять находятся в ожидании: 5 + 4 = 9.
Девять ожидающих не означают девять бесконтрольных вопросов. У каждого остаётся владелец и ближайшая дата проверки. Иначе смена статуса становится способом убрать неудобную работу из активного списка.
Закрытые пять включены в этот учебный срез для проверки движения группы. В ежедневной очереди можно показывать только открытые, но границы отчёта должны быть названы.
Опишите условия переходов
Для каждого статуса задайте четыре правила: что подтверждает вход, какое действие выполняется, что разрешает выход и кто отвечает за переход.
Например, переход в «ожидает клиента» разрешён после конкретного запроса данных. Недостаточно написать «пусть клиент думает». В карточке должна быть формулировка вопроса, дата отправки и понятная точка возврата.
Выход из ожидания происходит после получения достаточных данных, а не любого нового сообщения. Если клиент прислал файл, который не открывается, препятствие может сохраняться. Владелец фиксирует это и уточняет следующий шаг.
Из ожидания специалиста обращение может вернуться в исполнение: ответ получен, менеджеру нужно проверить его и сформулировать сообщение. Внутренняя задача специалиста при этом уже завершена, но клиентский вопрос ещё открыт.
Пример одного вопроса о сроке
Клиент спрашивает, можно ли перенести поставку на два дня раньше. Менеджер принимает обращение и передаёт планировщику задачу оценить варианты. Состояние становится «ожидает специалиста», владелец общения остаётся менеджер.
Планировщик возвращает два варианта: прежняя дата всей поставки или более ранняя частичная отгрузка. Менеджер проверяет условия и направляет их клиенту. Теперь обращение ожидает выбора клиента, потому что дальнейший шаг зависит от конкретного решения.
Клиент выбирает частичную отгрузку. Вопрос возвращается в исполнение: нужно согласовать изменение заказа и подтвердить результат. Закрывать обращение сразу после слова «согласны» рано, если внутреннее изменение ещё не принято.
Пример показывает, что ожидание — не тупик. У каждого перехода есть наблюдаемое событие и дальнейшее действие.
Шаблон строки словаря
Для выбранного состояния заполните:
- Название: ожидает специалиста.
- Смысл: клиентский ответ требует результата от назначенного участника.
- Условие входа: конкретная задача передана и принята по рабочему порядку.
- Обязательные сведения: исполнитель, требуемый результат, внутренний срок.
- Владелец общения: менеджер, который ведёт обращение.
- Контроль: момент проверки ответа и правило эскалации.
- Условие выхода: результат получен и достаточен для следующего шага.
- Допустимый переход: в исполнение либо в иное обоснованное состояние.
- Недопустимое использование: скрыть перегрузку или отсутствие назначенного исполнителя.
Такую карточку подготовьте для каждого состояния. Затем проверьте словарь на десяти реальных обращениях, где сотрудники раньше расходились в оценке.
Ожидание не останавливает время автоматически
Правила расчёта сроков задаются отдельно. Некоторые обязательства продолжают действовать даже при ожидании внутренних данных. Если клиенту обещан ответ до 16:00, статус «ожидает специалиста» сам по себе обещание не отменяет.
Ожидание клиента также не всегда означает разрешённую паузу. Сначала нужно определить, действительно ли запрошенные данные необходимы и как учитывается этот период в конкретном показателе.
Подробный порядок описан в материале о сроках клиентского ответа. Не подменяйте его условием «все ожидания вычитаются», иначе показатели можно улучшить простым переключением карточек.
Как закрывать и повторно открывать вопрос
Закрытие должно иметь основание: результат передан, согласованное действие выполнено либо работа прекращена по понятной причине. Для разных типов обращений критерии могут различаться.
Если после закрытия клиент сообщает, что исходный вопрос не решён, рассмотрите повторное открытие с сохранением истории. Если появилась новая независимая потребность, создайте новое обращение со связью с прежним контекстом.
Не используйте автоматическое истечение времени как единственное доказательство решения. Если такой порядок завершения предусмотрен процессом, он должен быть явно описан и не смешиваться с подтверждённым результатом клиента.
Начните со словаря для пяти самых частых тем. Связь обращения с задачей и сделкой проверьте по правилам разделения записей. Для обсуждения ЧатПлюс с ExtentLab принесите словарь и несколько спорных карточек: на них удобно проверить переходы, владельцев и необходимые сведения.