Почему заявки теряются, даже если сотрудники стараются

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

На первый взгляд это кажется невозможным, но на практике встречается часто.

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

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

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

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

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

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

В результате возникает ситуация, когда про заявку помнят, но работа по ней фактически остановилась.

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

Но есть один нюанс: автоматизация не устраняет ошибки полностью. Она лишь переносит их из области человеческого фактора в область настроек системы.

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

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

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

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

Если сотрудники поддержки все чаще получают сообщения вроде «Есть новости по моему обращению?», «Напоминаю о заявке» или «Подскажите, кто занимается этим вопросом», это повод насторожиться.

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

В этом случае сотрудники начинают тратить время не на решение проблемы, а на ответы о статусе проблемы. В результате нагрузка растет, а удовлетворенность пользователей – наоборот.

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

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

Если открыть список обращений и обнаружить десятки заявок, которые неделями находятся в статусе «В работе», это серьезный повод разобраться в ситуации.

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

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

Попробуйте провести простой эксперимент. Возьмите случайную заявку и задайте вопрос: кто сейчас отвечает за ее выполнение и на каком этапе находится работа?

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

Речь идет о простом, но очень показательном принципе: заявка считается «живой» только тогда, когда по ней есть действия. Что стоит отслеживать:

• комментарии исполнителя или команды;
• изменения статуса;
• запросы информации у пользователя;
• и т.д.

Если в течение нескольких дней ничего из этого не происходит, заявка формально остается в системе, но фактически выпадает из процесса.

На практике такие обращения чаще всего и воспринимаются пользователями как «потерянные», потому что для них отсутствие движения = отсутствие работы. Поэтому отдельный контроль «заявок без активности» – это не дополнительная нагрузка, а способ заранее увидеть проблему до того, как она превратится в жалобу.

SLA отвечает на вопрос «успели или не успели», но не отвечает на вопрос «где именно возникла задержка». Именно поэтому две компании с одинаковым уровнем соблюдения SLA могут иметь совершенно разное качество сервиса.

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

Например:

• первая линия – 30 минут;
• передача в IT – 2 дня ожидания;
• выполнение задачи – 1 час;
• согласование – 3 дня;
• возврат на доработку – еще 1 день.

Формально SLA может быть соблюден, но фактически основное время заявка проводит не в работе, а в ожидании между этапами. Особенно важно смотреть на «узкие места» где заявки чаще всего задерживаются, на каком этапе растет очередь, где появляется накопление статусов «ожидает».

Каждое согласование в процессе – потенциальная точка потери обращения. И чем их больше, тем выше вероятность, что заявка остановится не из-за ошибки, а просто из-за ожидания.

Чтобы снизить такие риски, важно периодически пересматривать саму архитектуру процесса. Полезно задавать такие вопросы:

• можно ли объединить несколько согласований в одно;
• действительно ли каждый этап обязателен;
• можно ли назначить одного ответственного за итоговое решение;
• можно ли заменить последовательные согласования параллельными.

Во многих компаниях после такой ревизии количество этапов сокращается на 20–40%, и это напрямую снижает число «потерянных» заявок.

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

Так, в Админ24 заявка автоматически отправляется к ответственному, который привязан к форме.

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

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

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

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

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