Сколько статусов нужно заявке

Кратко

Пять: принято, в работе, ждём клиента, решено, закрыто. Больше заводить не стоит — через месяц половина не используется, а операторы ставят «в работе» всему подряд, и статус перестаёт нести смысл.

Пять состояний

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

Почему пятнадцать не работает

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

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

Что обычно пытаются сделать статусом, а не надо

• Тему или категорию. «Оплата», «Доступ» — это отдельное поле, не статус.
• Приоритет. «Срочно» — тоже отдельное поле. Слитые вместе, они запрещают повысить приоритет, не меняя состояния.
• Кто виноват в задержке. «Ждём разработку», «Ждём поставщика» — это либо назначенный исполнитель, либо пометка, но не состояние обращения для клиента.
• Причину закрытия. «Решено», «Дубликат», «Не воспроизводится» — причина закрытия, отдельное поле при переходе в «Закрыто».

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

Единственный статус, которому можно верить

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

Как проверить, что лишних нет

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

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

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

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

Когда шестой статус всё-таки нужен

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

Два случая, где шестой статус обычно заслужен:

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

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

• Назовите событие, которое его порождает, и событие, которое из него выводит.

• Решите, идёт ли в нём срок. Статус, останавливающий срок, — самый удобный инструмент подкрутки, за ним нужен встречный замер.

• Решите, видит ли его клиент и как он называется снаружи. Внутренние состояния клиенту показывать не обязательно, но то, что он видит, должно быть понятно без объяснений.

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

Что показывать клиенту

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

Правило простое: наружу выходит то, что меняет ожидания человека. Смена исполнителя внутри службы ожиданий не меняет; переход в «ждём клиента» меняет и потому обязан быть виден — вместе с прямым указанием, чего именно от него ждут.

Связанные статьи

• Статусы заявок
• Как оказывать техническую поддержку: путь обращения, сроки и регламент
• Как настроить приоритеты заявок, чтобы ими пользовались