Пожар в техподдержке: причины возгорания и способы тушения

Внушительное и все нарастающее количество необработанных запросов, хроническое превышение установленных сроков обработки обращений, недовольство клиентов, «праведный гнев» руководства, паника и траур среди сотрудников службы поддержки. Одним словом – завал. Как часто вы наблюдали такую картину в отделе техподдержки?

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

Самое время засучить рукава и взяться за работу. Итак, с чего начать:

1. Уведомить клиентов об увеличении времени обработки запросов: объявление на сайте, автоинформирование на телефонном канале и прочее. Если есть известная проблема, которая затронула большое количество клиентов и о ней «не стыдно» рассказать, то лучше начать текст объявления со слов «Большое (некоторое) количество пользователей столкнулось с проблемой X. Наши инженеры знают об этой проблеме и в настоящий момент заняты поиском ее решения».
2. Если этого еще не сделано, сделать так, чтобы клиент попадал к специалистам поддержки только после ознакомления с FAQ, KB etc. – то есть внедрение своего рода фильтра, способного сократить объем входящих запросов. Да, это так называемая тактика «крысиного лабиринта», которая отдаляет пользователя от формы обратной связи, раздела contact us etc., не самая гуманная, но прямо сейчас требуется сберечь ресурсы, сосредоточив их на важных клиентах и на решении тех проблем, которые мы можем решить.
3. По возможности отказаться от трудоемких каналов поддержки. Какие каналы считать трудоемкими? К примеру, телефон – реакция на входящий запрос требуется достаточно оперативная. Кроме того, быстро обработать однотипные запросы не получится, так как Ctrl+C / Ctrl+V на телефоне не сработает.

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

Всплеск является следствием какого-то разового события:

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

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

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

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

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

Если в продуктовой линейке компании несколько продуктов, начинаем поиски с определения проблемного продукта. Затем приступаем к анализу динамики типов запросов. Если ранее такой статистики не велось, то в наступивших условиях — самое время озаботиться. Лучше поздно, чем никогда, да и в будущем пригодится.

Рассмотрим в качестве примера типы запросов в компании-производителе мобильных устройств.

1. Аппаратная проблема: если всплеск пришелся на этот тип запросов, крайне важно установить географическую распределенность обращений, а также то, на какие устройства в продуктовой пришелся рост жалоб. Скорее всего, речь идет о попадании в продажу бракованной партии.
2. Программная проблема: следствие выхода «сырой» прошивки.
   
3. Запрос на информацию: проблема кроется в недостаточной документированности продукта. Придется поработать над пользовательскими мануалами.
   
4. Обратная связь: вопросы из серии «а будет ли реализован функционал X в продукте Y?». Часто является следствием появления или анонсирования нового функционала как у нашей компании, так и у конкурентов.
   

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

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

Клиента мало интересуют наши внутренние проблемы: новые рынки сбыта или наши кадровые проблемы. Его больше заботит скорость обработки запроса и сам факт решения проблемы.

В том случае, когда для ответа на часть запросов достаточно внутреннего FAQ (если он существует) – можно и нужно «усилиться», чтобы сократить нагрузку на персонал. Кто сможет помочь? Коллеги из смежных департаментов, либо временная рабочая сила. На этот случай всегда нужно держать наготове несколько удаленных рабочих мест, а в идеале с самого начала подбирать такие инструменты, которые поддерживают удаленный доступ. Их помощь понадобится на время устранения или минимизации воздействия причины плюс некоторое количество времени на обработку скопившихся обращений — «осушения болота».

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

Узнать подробнее о курсе Руководитель поддержки пользователей в IT.