1 подписчик

Техподдержка твоей мечты

26 августа 202126 авг 2021

10 мин

Оглавление

Чем отличается хороший саппорт от плохого?
Причина
Теперь, когда мы знаем, как выглядит ад...

Чем отличается хороший саппорт от плохого?

Директора компаний обычно хотят видеть техподдержку дружелюбной, компетентной, стрессоустойчивой, терпеливой, умеющей сделать клиента счаcтливым...

Но это все только отвлекает от самого важного:

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

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

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

При этом сотрудники могут быть крайне вежливы, стрессоустойчивы и терпеливы:

Причина

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

Вроде бы нет ничего проще его работы:

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

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

Теперь, когда мы знаем, как выглядит ад...

... легко можем увидеть, чем же вымощена дорога в рай

Обучение и респект

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

Понадобится четкая и последовательная программа обучения, посмотри, как это устроено у крутых: PADI или в Яндекс.Практикум.

Система покоится на трех слонах:

Теория в виде устной лекции или видео или структурированного текста
Блок тестовых задач на основе прочитанной лекции укажет на понимание материала
Практическое задание для закрепления и погружения в детали

И одной черепахе:

База знаний, к которой можно обратиться в любой момент для повторения материала (Confluence, wiki, google docs, trello - все годится)

Инструменты

Контролируй все, за что отвечаешь. В Авантеле мы возвели этот принцип в абсолют:

у техподдержки было несколько систем мониторинга Zabbix, Cacti и Nagios. На каждый чих в сети, мы получали все необходимые данные для диагностики
мы бесплатно выдавали и настраивали клиентам роутеры keenetic, чтобы получить контроль за оборудованием с обоих концов кабеля
мы выбирали оборудование, которое давало максимальные возможности для диагностики
благодаря развитию интернета вещей, мы получили возможность отказаться от установки любого оборудования, которое не управлялось по IP
и самое главное — мы собрали всю информацию о сети и клиентах в единую базу в CRM: никаких ползаний по excel-таблицам d поисках информации

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

Взаимодействие со специалистами

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

Идеальное решение

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

Добейся от руководства компании, чтобы над входом в офис висело:

Заявки техподдержки имеют высший приоритет

Обычное решение

Убеди сотрудников, что они не должны отставать от инженеров, пока те не выдадут решение или приемлемые сроки решения. Инженеров убеди, что самый простой способ от вас отделаться - решить заявку. Тщательно расследуй все случаи, когда это не работает.

Частые причины:

Специалист убежден, что заявку может и должна решать техподдержка. Предоставь на выбор: выполнять заявку самому или организовать обучение
Твой отдел конкурирует с другим за время специалиста. Если репутация компании под угрозой из-за горящих сроков по внедрению - это ничем не отличается от репутационных потерь из-за плохого качества сервиса. Договорись с конкурентами и помоги им. Убедись, что они понимают, что твои заявки в приоритете, и что повторения инцидента не будет. Убедись, что специалист понимает, что твои заявки в приоритете. Убедись, что он сам сообщит тебе о следующем подобном конфликте.
Личная неприязнь . Втроем обсудите разногласия в неформальной обстановке: за обедом, в баре или на корпоративе.

Эта работа никогда не закончится, но чем методичнее действуешь, тем меньше внимания требуется тут уделять.

Взаимодействие сотрудник - руководитель

Тут все просто:

Ты такой же специалист, только по вопросам координации, взаимодействие с тобой происходит по тем же правилам

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

Улучшения

Итак у тебя:

Прокачанные сотрудники
Мощные инструменты диагностики
Первобытный страх всех отделов перед саппортом

можно начать улучшения, как велит нам ITSM.

Метрики

Сейчас все любят metrics driven approach, ибо для того, чтобы что-то улучшать, надо научиться это измерять. Однако:

Измерения часто приводят к искажениям, что делает хорошие метрики бессмысленными

Распространенный фейл – привязка метрик к зарплате.

Если техподдержка решает проблемы и не создает новые, как привязать это к зарплате ? Да никак, потому что производительность тут равна количеству заявок умножить на их сложность и нужно формализовать поянятие "сложность".

Поскольку написать книгу об этом мало у кого хватает терпения, пытаются привязать к чем-нибудь другому – средней скорости решения заявки, например. И скорость повышается, а клиенты не становятся довольнее. Заявка просто закрывается при первом подозрении, что она решена. Поэтому требуется писать новую книгу: "что такое качественно решенная заявка"

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

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

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

Правильные метрики

Тут исключительно мое мнение, которого я стараюсь придерживаться — метрики должны:

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

Кроме улучшения метрик

Классифицируй и анализируй заявки: например мы выяснили, что 50% от всех заявок — неисправности в локальной сети клиента и договорились с дружественным IT-аутсорсером об услуге бесплатного первого выезда
Вообще думай о том, какую ценность может еще предложить техподдержка клиенту, на какие вопросы не смогли качественно ответить, какую проблему оставили без должного внимания. Например, мы научились на время основного ремонта восстанавливать связь через WiFi-ретрансляторы и сотовых операторов, а во время крупных аварий — подключать другие отделы отвечать на звонки.
Подумай, как предотвращать проблемы, или решать до того, как клиент потянет руку к телефону. Например, мы начали мониторить процент неудачных звонков по городам и реагировать, когда он превышает пороговое значение
Запрети в разговоре с клиентом использовать фразы "не знаю", "невозможно", "не получится" — они позволяют не думать. Можно: "мне нужно уточнить", "возможно, стоимость такого решения - миллион", "возможно, но займет 1000 часов"
Не бойся залазить в чужие зоны ответственности: 50% всех твоих проблем начинаются в отделе развития: у разработчиков, строителей, продажников. Ты же обеспечиваешь поддержку решений, которые продали/разработали/построили эти отделы и за тобой контроль качества результатов.

Мотивация

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

Для их мотивации достаточно:

понимание, какие действия от них ожидаются, критерии качества работы, устранение непреодолимых препятствий и какая-то культура уважения к тому, что делает компания
зарплаты соответствующие рынку (ЗП выше рынка может даже навредить)
не пытайтесь скрывать зарплаты, все равно все знают, у кого какая. Вам нужна понятная система мотивации: если кто-то получает больше меня, я хочу знать, что сделать, чтобы получать столько же. Я предпочитаю систему грейдов + расширенные зоны ответственности внутри отдела + взятие на себя функций других отделов
понятные функции и регламенты: где чья зона ответственности, отсутствие понимания "кто должен решать эту заявку" приводит к падению счастья и эффективности
рабочее место, соответствующее нормам (предпочитаю опенспейс). Тут, надеюсь, все просто: проветриваемое, просторное помещение, не тормозящий комп, удобное кресло, хорошее освещение, комфортный уровень шума, комфортная температура (кстати, она у всех разная — кто на каком расстоянии сидит от кондиционера — это вам не шутки).
возможности роста. Не бойся тащить в светлое будущее принудительно: сотрудники будут очень вдохновлены, если под твоим началом они будут профессионально расти, особенно если самостоятельно у них на это не хватает энергии или мотивации

В общем, поддерживаю избитую формулу:

счастливые сотрудники делают клиентов счастливыми

Команда

Часто саппорт называют "командой техподдержки". Проследи, чтобы это были не пустые слова, командная культура подразумевает, что индивидуальные показатели имеют приоритет ниже общих. Тебе надо, чтобы техподдержка решала заявки быстрее или чтобы Дима/Таня решали их быстрее остальных ?

отдел должен стремиться к общим целям, а не индивидуальным показателям
в сложных ситуациях объясняй, как использовать командый подход, например — при выборе, кто должен взять на себя заявку нам нужна не равномерность нагрузки, а общая скорость решения заявок

Авторитет руководителя

Я оставил этот момент напоследок, однако без него, пожалуй, можно выбросить все, что я сказал выше, тебе придется испытывать боль на каждом этапе, однако тут все просто:

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