Человеку нужен человек. Как выстроить работу технической поддержки в IT
Техническая поддержка… Как много любви, боли и взаимовыручки кроется в этих словах. За этими словами стоят люди со своим характером, проблемами и настроением. Они — те самые супергерои, которые способны сдержаться и не выругаться в ночи в ответ на очередное «А почему @#$ у меня не работает @#$%^». Но почему, несмотря на все усилия, звонок в техподдержку — это почти всегда повод для тяжёлого вздоха для пользователя и еще один шаг на пути к выгоранию сотрудника?
Попытались ответить на извечные вопросы о том, как минимизировать негатив от клиентов и научить сотрудников стоять за себя, с Григорием Мурашовым, главным специалистом 2-й линии технической поддержки Voximplant.
Кто есть кто
Вопросы, которые мы решили поднять, достаточно избиты в мире технической поддержки — они обсуждались еще 40 лет назад. Тогда старые добрые «британские ученые» начали выяснять, как эффективно организовать и проконтролировать работу технической поддержки в IT сфере. По итогу ребята выпустили 30 томов с рекомендациями. К счастью, со временем они были сокращены до 5 и получили название «методология ITIL». Суть этой методологии заключается в закреплении узких зон ответственности за каждым специалистом. Так, в компании должно быть разделение как минимум на 1-ю, 2-ю и 3-ю линию поддержки — такая узкая специализация значительно повышает эффективность сотрудников и упрощает коммуникацию с пользователем, ну и, конечно же, между собой. Чтобы этот конвейер входящих вопросов работал, нужно связующее звено — ServiceDesk. Оно и помогает контролировать весь процесс и эффективность его участников.
В работе технического специалиста важно, что именно положили на этот конвейер, от этого зависит дальнейший сценарий взаимодействия. Так, в Voximplant пользователи подразделяются на три главные группы: самоходы, партнеры и клиенты-проекты. Но обо всем по порядку.
Самоходы
Самоходы — это чаще всего разработчики, частные лица, которые (сюрприз-сюрприз) самостоятельно пришли к нам на сайт и увидели технологии, документацию или статью, которые показались им интересными, взяли этот функционал и использовали его в своей разработке. Работать с самоходами одновременно легко и сложно. Дело в том, что эта категория не всегда состоит из квалифицированных кадров, впрочем, как и техническая поддержка — сотрудники не обязаны быть экспертами в языках программирования или в кейсах, отличающихся от базовых. Базовый кейс — это в 90% случаев телеком, то есть проблемы со связью. В этом случае перед сотрудниками поддержки стоит задача деликатно доказать самоходу, что ему необходимо либо подтянуть матчасть, либо внимательнее прочитать документацию.
Особенность общения технической поддержки с каждым обратившимся в первую очередь состоит в том, чтобы погрузить клиента в процесс и за руку провести его из пункта А — идентификация проблемы — в пункт Б — ее решение. Чем лучше пользователи разбираются в матчасти, тем больше возникших проблем он может решить самостоятельно. Поэтому часто техподдержка выполняет некоторую функцию наставничества. Мы стараемся не столько решать проблему за клиента, сколько помочь ему самостоятельно дойти до решения проблемы.
Партнеры
Партнеры — это те, кто собрал свой продукт, используя инструменты Voximplant, и предлагают его своим клиентам. Типичный пример — onlinePBX — виртуальная АТС для бизнеса. Мы предоставляем компании телефонные номера в аренду, взяв всю операторскую часть на себя, это дает onlinePBX возможность не заморачиваться с лицензиями, регуляторами и другими скучными вопросами. Несложно догадаться, что в этом случае в техподдержку приходят вопросы по тем самым классическим кейсам, про которые мы говорили выше, — проблемы со связью.
С партнерами в этом плане работать проще, так как у них есть минимальная компетенция в технических вопросах. Конечно, клиенты партнеров могут обратиться к нам на базовый флоу поддержки, однако они предпочитают сначала написать партнерам. Поэтому, при проявлении негатива, его скорее всего устранят (негатив, не клиента) на этапе партнера.
Клиенты-проекты
Это наши конечные клиенты-компании. С ними у нас есть несколько схем взаимодействия. Например, техническую поддержку могут подключить на первоначальной стадии разработки проекта или уже после запуска. В этом случае мы сталкиваемся с проблемой приоритизации — клиентов много, а мы одни. Также работа поддержки в большинстве своем переходит в чаты и мессенджеры, из-за чего понять проблему сходу бывает сложно — нужно вникнуть в вопрос клиента, уточнить его статус, понять, о каком вообще проекте говорит клиент, если их несколько и т.д.
В этом случае мы не ждем от клиента никакого понимания и компетенций, ведь мы по сути продали им черный ящик, который автоматизирует какие-то процессы внутри компании. Да, ящик он видит, но как именно он работает — не знает. Поэтому в этом случае важно найти точки соприкосновения, а не твердолобо доказывать, что клиент не прав, используя весь набор технических терминов.
Скорость VS Качество
Мы бы могли долго и муторно рассуждать на тему того, как происходит приоритезация задач внутри команды — смотрим на объем трафика, уточняем, прописан ли отдельно в контракте пункт о технической помощи и т.д. Но в техподдержке есть негласное правило, как у врачей при авариях, — помочь тем, кто нуждается прежде всего. Поэтому, если у компании, пусть даже самой маленькой, полностью встал сервис или не работают номера телефонов, мы берем его проблему в работу первой.
Именно поэтому сотрудники технической поддержки должны иметь аналитический склад ума и техническая базу, именно базу. Поскольку у нас сложный составной продукт с множеством разрозненных подсистем, — телеком часть, взаимодействие с API и т.д. — требуется постоянная тренировка. Даже будучи опытным специалистом, не всегда понимаешь с первого взгляда, куда бежать и что делать. А даже если ты и знаешь, в каком направлении бежать, у тебя может просто не быть опыта решения именно этой проблемы, что совершенно нормально. Да, здорово быть эмпатичным сотрудником, излучать добро и любить всех и вся, но первоначально нужно быть сильным технарем и любить копаться там, где другие бы давно махнули рукой.
А как же суперсила техподдержки — скорость? Отвечает Александр Друзь. Для клиента первоначально стоит качество решения проблемы, а не скорость — шок. Результат может быть как через пять минут, так и через день, но исход должен быть один — проблема должна быть решена. И да, это правда может занять целый день, ведь решение каждой проблемы индивидуально и не происходит по чек-листу.
Во-первых, надо понять, что именно сломалось, а это самый важный и тяжелый пункт. Из-за отсутствия технического опыта клиенты могут некорректно описать проблему, а значит сотруднику техподдержки нужно задать правильные вопросы, постепенно выводя клиента из темного леса. Это также дает возможность клиенту дойти до решения проблемы или проверить какую-то самостоятельно — помните тот самый пункт про обучение клиентов матчасти. Если трюк не сработал, тогда техподдержка анализирует проблему на более глубоком уровне и приступает к ее решению.
Срываем шаблоны
Но это как-то все вилами по воде писано, да? Ликуйте, перфекционисты, приступаем к метрикам. Метрики, надо сказать, очень тонкий и сложный вопрос. Мы не будем сейчас описывать всем известные количественные метрики, — среднее время первого ответа, решения проблемы или доля решенных заявок — потому что мы, в Voximplant, не решились их применять в явном виде. Дело в том, что слепое следование метрикам приводит к автоматизации и роботизированности, которой в качественной поддержке быть не должно.
Мы редко используем шаблонные ответы, ведь шаблонизация дает мозгу сигнал, что есть просто путь, выбрав который можно долго не думать и якобы быстро решить проблему. Поэтому каждый раз сталкиваясь с новым тикетом нужно не только анализировать каждое действие, но и периодически давать себе вопрос «Правильно ли я сейчас поступаю?».
Рано или поздно перед руководителями встает задача унифицировать работу сотрудников, чтобы предоставить какие-то результаты или самому оценить эффективность работы. Эта участь не обошла и нас стороной. Однако было не совсем понятно, как именно это сделать, ведь разные задачи как минимум имеют разную сложность. Есть, к примеру, типовые — телеком кейсы, а есть те, с которыми впервые сталкивается даже тимлид. Поэтому, если вводить какие-то метрики по скорости и количеству ответов, у сотрудника появится стимул работать на количество, а не качество.
Когда тебе надо набрать 30 ответов в день, чаще всего ты берешься за самые легкие тикеты, чтобы набрать заветные баллы, оставляя сложные, но не менее важные, вопросы пользователей на потом. Поэтому мы стараемся стимулировать работать головой, анализируя каждый свой шаг. Да, возможно так они потратят больше времени, чем закладывалось, но, если сотрудник разберется с незнакомой проблемой сейчас, то будут оказывать более высокий сервис в будущем. Стоит также понимать, что обучение и торможение процесса — разные вещи. Если сотрудник полдня копался в документации, не попросил помощи и в итоге не решил проблему — есть повод задуматься. Однако право на ошибку есть у всех, но не на систематические провалы.
Так, сейчас цифровой оценки работы сотрудников просто нет, поэтому так важно быть вовлеченным в проблемы подчиненных, наблюдать за их ответами и давать элементарную обратную связь в виду «Лучше ответить так или так». Например, если видно, что сотрудник делает все технически верно, но форма коммуникации хромает, можно мягко объяснить, каким клиентам нужно больше технических деталей, а кому лучше сразу ответить развернуто, чтобы избежать дополнительных вопросов. Это не только налаживает здоровую атмосферу в коллективе, но и подталкивает к личностному и профессиональному росту.
Как выстроить защиту, если чеснок не помог?
Давайте будем честны — все мы люди. Уязвимые, смертные люди, чувствительные к потоку негатива, поэтому особенно важно учить сотрудников техподдержки защищаться от плохого настроение и негодования других.
Во-первых, нужно начинать с себя, точнее пользователей, поэтому мы всегда предупреждаем клиентов о возможном бане, если они выходят за рамки приличия — переходят на оскорбления или такой привычный @#$. Во-вторых, как бы сложно ни было, нужно проявить эмпатию и дать понять пользователю, что его проблема важна и уже решается.
Не так
А так
Дайте также сотрудникам возможность абстрагировать на время от негатива с помощью бонусов, которые они самостоятельно могут презентовать пользователям. Пока последние пытаются понять, насколько это подняло их лояльность, техподдержка перезарядится и возможно уже решит проблему к этому времени. При любых обстоятельствах давайте понять, что на том конце сидят такие же живые люди. Поэтому если проблема не решается за «сейчас», опишите пользователю действия, которые вы уже предприняли для скорейшего разрешения вопроса и для того, чтобы это не повторилось.
Ну и главное правило при работе в негативом — старайтесь оперировать фактами в ответ. Негатив — это обратная стороны факта, эмоция, которую не стоит гасить, иначе она превращается в настоящий пожар. Поэтому при ответе на вопрос «Какого черта ничего не работает?» нужно не забыть, во-первых, использовать больше вежливых слов (да-да, обман зрения работает), а, во-вторых, разложить все по полочкам, чтобы пользователь просто не смог устоять перед стеной рациональности.
Профилактика выгораний
Ежедневно в Service Desk приходит сотни обращений от пользователей с различными проблемами, на каждую из которых важно посмотреть с разных ракурсов: проанализировать и задаться вопросом «Что будет, если я решу задачу так или иначе?». Поэтому неудивительно, что любая деятельность, завязанная на повторяющихся задачах, рано или поздно превращается в рутину. Так что же делать, если в дверь все же постучало выгорание?
В рамках работы с командой есть «профилактические» встречи, как общие, так и тет-а-тет, на которых мы стараемся выяснять, насколько сотрудник близок к точке кипения. Ведь, когда ты не видишь проблем, с которыми не сталкивался ранее, и ты настолько грамотен в работе и эмоционально спокоен, что начинаешь невольно задумываться — может там, за горизонтом, что-то есть интереснее.
В процессе работы не забывайте оторваться от себя и понаблюдать за сотрудниками, за их стремлениями и способностями. Так, получится вовремя сгенерировать дополнительные задачи, выходящие за рамки простой поддержки, для тех, кто на грани. Например, какие-то проектные интеграции, либо помощь другим командам — любая смена деятельности.
У нас также есть прозрачная система грейдов, а значит, и понимание, какие навыки надо подтянуть, чтобы перейти на новый уровень. Это, естественно, влияет и на зарплату, и на статус. Более того, никто не отменял смежного перехода между отделами. Возможности для развития как в техподдержке, так и вне отдела есть у всех. Вопрос в том, хочет ли человек их использовать, готов ли взяться за чуть более сложную задачу или принять участие в нестандартном проекте? Ведь только так, выйдя из зоны комфорта, можно получить новый опыт и развить навыки.
И главное, помните — минимум рамок и шаблонов. Благодаря этому принципу в голове не перестает трудиться серое вещество.
