Заявка висит в статусе «В работе» уже месяц. Ее точно кто-то выполняет?
Заявка может месяцами числиться в системе со статусом «В работе», хотя фактически ей никто не занимается. Разбираемся, почему обращения застревают между исполнителями и согласованиями, как вовремя заметить проблему и вернуть контроль над процессом.
Клиент пишет в третий раз: «Есть новости по моему обращению?» Вы открываете систему: заявка на месте. Номер есть, статус «В работе», исполнитель назначен, срок не нарушен. Формально всё в порядке. Фактически по заявке уже две недели никто ничего не делает — и вы об этом не знаете.
Парадокс: потерянная заявка почти никогда не «пропадает». Она живёт в системе, выглядит нормально и портит репутацию молча. Разберём, где именно заявки застревают — и почему это происходит даже там, где сервис-деск внедрён и люди стараются.
Заявка есть, владельца нет
Обращение зарегистрировано, статус присвоен, исполнитель указан. Только вот работать над ним некому:
- Исполнитель в отпуске или на больничном. Автоматика продолжает направлять заявки на него. Формально ответственный есть, фактически — никого.
- Исполнитель ушёл или сменил роль. Человек перешёл в другой отдел или уволился, а правила маршрутизации остались прежними.
- Общая очередь. Классика «эффекта стороннего наблюдателя»: каждый считает, что заявку возьмёт кто-то другой. В итоге не берёт никто.
Самое неприятное: такие ситуации незаметны. Если бы заявка потерялась технически, проблему быстро бы нашли. А «живая» запись с назначенным исполнителем выглядит как работающий процесс.
Согласование — чёрная дыра
Заявка идёт быстро, пока не упирается в согласование: руководитель подразделения, служба безопасности, бухгалтерия, внешний подрядчик. Дальше начинается ожидание — и вот в чём дело: для согласующего ваша заявка — не основная работа. У него свои проекты, встречи и задачи. Заявка ждёт не часы, а дни и недели. Все о ней помнят, но работа фактически остановлена.
Автоматизация привносит ошибки, а не устраняет
Ошибки маршрутизации — отдельный класс потерь. Компания изменила структуру: новые отделы, новые роли, кто-то ушёл. А правила распределения заявок работают по инерции — и обращения поступают сотрудникам, которые ими больше не занимаются. Или пользователь выбрал не ту категорию — и система отправила заявку в неподходящую очередь: специалисты не могут её решить и пересылают дальше, по кругу. Или уведомление не дошло до исполнителя — в системе всё выглядит запущенным, а человек даже не знает о заявке.
Чем это обходится
Потерянная заявка — это не «техническая мелочь». Для клиентской поддержки это клиенты, которые перестают пользоваться услугами после нерешённого вопроса: они не пишут гневных писем, они просто уходят. Для внутренних заявок — простой сотрудников, задержки в работе и двойная обработка: люди создают дубликаты, потому что думают, что первое обращение не дошло. Нагрузка растёт, удовлетворённость падает, а отчёты по SLA показывают «всё в порядке» — потому что формально сроки не нарушены.
Пять сигналов, что заявки уже теряются
Никто не приходит к руководителю со словами «у нас за месяц потерялось 17 обращений». Проблема проявляется косвенно:
- Пользователи регулярно напоминают о заявках. «Есть новости?», «Напоминаю», «Кто занимается вопросом?» Если это стало нормой, люди не верят, что по их обращению идет работа.
- Сотрудники обходят систему. Пишут знакомому специалисту в мессенджер, звонят напрямую. Не из вредности — потому что так быстрее. Это значит, доверие к официальному процессу падает.
- Завалы статусов «В работе». Десятки заявок неделями висят в одном состоянии, без комментариев и изменений. Именно среди них чаще всего находятся «потерянные».
- Никто не может быстро сказать, где заявка. Возьмите случайное обращение и спросите: кто отвечает за результат и что происходит сейчас? Если ответ требует расследования по коллегам — прозрачности нет, а риск потери высок.
- Появляются дубликаты. Пользователь не уверен, что его первое обращение дойдёт, — и создаёт второе, а потом и третье. Дубликаты не только раздувают статистику: они дробият ответственность, и в итоге по одной проблеме работают два человека, а то и не работает никто.
Что делать
- Контролируйте заявки без движения. Принцип простой: заявка жива, пока по ней есть действия — комментарий, смена статуса, запрос информации. Если активности нет несколько дней — заявка фактически выпала из процесса, даже если сроки горят. Порог обычно 3–5 дней, зависит от типа обращений.
- Смотрите не только SLA, но и путь заявки. SLA отвечает на вопрос «успели или нет», но не на вопрос «где застряло». Классика: первая линия — 30 минут, передача в ИТ — 2 дня ожидания, работа — час, согласование — 3 дня. Формально SLA может соблюдаться, а основное время заявка проводит в очередях между этапами.
- Ревизуйте согласования. Каждое согласование — потенциальная точка потери. Можно ли объединить два в одно? Назначить одного ответственного за итог? Заменить последовательные согласования параллельными? Практика: после такой ревизии число этапов сокращается на 20–40%.
- Проверяйте маршрутизацию после любых оргизменений. Структура меняется постоянно — правила распределения должны меняться вместе с ней. Сверяйте маршруты с реальными путями заявок, а не с настройками.
- Возвращайте «теневые» обращения в систему. Часть заявок всегда уходит в обход — это естественно. Но если теневой поток значимый, руководитель видит неполную картину нагрузки. Фиксируйте такие обращения в системе и переводите коммуникации туда же.
- Аудитируйте процесс регулярно. Минимум раз в квартал, а после каждой перестройки структуры — сразу: соответствуют ли маршруты текущим ролям, не накапливаются ли очереди на конкретных этапах, какие статусы «живут» дольше нормы. Процесс обработки заявок — не «настроил и забыл», а живой механизм, который требует осмотра.
Главный принцип
Единый владелец результата. Даже если над заявкой работают три отдела, один человек должен отвечать за итог, а не за «свой участок». Без этого обращения распадаются на этапы, между которыми никто не отвечает. На практике это выглядит так: маршрут «поддержка → ИТ → бухгалтерия» может сколько угодно перекидывать заявку, но владелец один — и именно он отвечает клиенту, что происходит, и поднимает эскалацию, если заявка встала.
В Админ24 контроль заявок без активности встроен: система сама показывает обращения, по которым давно не было действий, и напоминает ответственным. Но инструмент — половина дела: процесс нужно пересматривать минимум раз в квартал, а после каждой перестройки структуры — сразу. Иначе заявки снова начнут «теряться» — с идеальным SLA в отчётах.
А у вас бывало: открываете систему, а там заявка в «Работе» с прошлого квартала? Расскажите в комментариях, как это обнаруживали и что меняли.