Часто наблюдаю одну и ту же сцену: конечный пользователь приходит прямо к разработчику или инженеру. Иногда ещё хуже — появляется «посредник», который лишь краем уха слышал про проблему и пытается сам выяснить, в чём задача, вместо того чтобы оформить нормальное обращение.
Во всех этих случаях на поверхности одна и та же проблема — отсутствие базового навыка: внятно изложить суть вопроса.
Отправлять человека «крутить гайку», если он не знает, что в руке у него именно гаечный ключ, а не «какая‑то железка», — странная идея. Ровно так же странно сажать человека за рабочий компьютер, если он не способен в письменном виде описать, что именно у него не работает и при каких условиях.
Страх быть обсмеянным можно оставить за скобками. Специалиста отсутствие базовых коммуникативных навыков не украшает, а сотрудника с сомнительной квалификацией скорее компрометирует.
После внедрения сервис-деск поддержки мы часто начинаем беречь пользователей слишком сильно. Вместо того чтобы научить их формулировать заявки, мы делаем всё за них: разговариваем устно, сами заносим обращение в систему, подбираем категории. Надежда, что такая «доброта» окупится лояльностью, выглядит наивно.
У этого подхода есть как минимум два побочных эффекта.
Во‑первых, мы лишаем себя возможности стандартизировать входящие запросы. Там, где мог бы быть один формализованный канал с понятными полями, у нас получаются десятки неформальных разговоров.
Во‑вторых, мы теряем данные. Точка входа запроса должна быть единой и минимально инерционной – тогда её можно измерять, улучшать и автоматизировать. Когда же половина обращений решается через личные визиты и чат «между делом», сервис-деск превращается в неполную картину реальности.
Поэтому людей и случаи обхода стандартного диалога через сервис-деск имеет смысл считать отдельной метрикой. Ничего сложного: фиксировать, кто приходил лично, с каким вопросом и сколько времени занял разговор «вслух с подсказками».
Практика показывает, что значительная часть таких обращений (порядка 60–70%) могла бы быть решена на этапе подготовки письма или заявки — если бы пользователь был вынужден чётко ответить на несколько простых вопросов. Остальные случаи как раз полезны: они помогают улучшать коммуникацию, обновлять базу знаний и выстраивать эскалацию через руководителей, которые лучше понимают контекст задачи.
Самое важное — беречь не только пользователей, но и специалистов. Разработчики, инженеры и эксперты — дорогостоящий ресурс. Чем больше их день состоит из разорванных, плохо сформулированных обращений, тем выше риск выгорания и тем меньше времени остаётся на сложные, по‑настоящему ценные задачи.
Хорошо работающий сервис-деск — это не «формальность ради отчётности», а фильтр и каркас коммуникаций, который защищает и пользователей, и специалистов.
0 комментариев