Привет, Хабр! Меня зовут Екатерина, я руководитель департамента технической поддержки в МТС Линк.

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

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

Место и значение поддержки в МТС Линк

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

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

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

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

Сотруднику технической поддержки такого продукта нужен обширный набор знаний. Разброс по технологиям, с которыми надо быть хотя бы мельком знакомым, довольно широк. А во многих областях для помощи клиенту поверхностного понимания недостаточно. Допустим, надо знать не только в общих чертах, как устроен интернет, но и что такое SIP, как вообще работает телефония и наш мессенджер, какие у них есть технические нюансы. При этом надо быть в целом лояльным к клиентам, соблюдать так называемый tone of voice компании и т. п. Иными словами, наш саппорт — это не просто оператор, который в любой непонятной ситуации предлагает перезагрузиться. Задача специалистов — более глубоко погружаться в используемые в продукте технологии, чтобы с меньшим количеством касаний помогать клиентам с проблемами, особенно комплексными.

В среднем на человека — до 1 000 заявок, но все зависит от линии и канала приема обращений (входящая телефонная линия, личный кабинет, почта, вызов сотрудника из мероприятия, выделенный канал для внутренней поддержки сотрудников).

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

Мы набираем специалистов техподдержки уже с прицелом на дальнейшее обучение. Для этого стараемся побольше пообщаться на старте: поговорить 40–50 минут, чтобы собрать информацию об основных навыках и слабых зонах потенциального сотрудника, о его стремлении развиваться. По итогам общения те, кто выходят к нам на работу, как правило, уже имеют представления о наших ожиданиях и знают, какие навыки надо развивать в первые 1–2 квартала.

Путь специалиста техподдержки МТС Линк

Мы выделяем три этапа обучения и развития:

• Онбординг. Новый сотрудник только подписал документы и еще не погружен в работу. На этом этапе мы стараемся максимально быстро показать, как помогать клиентам эффективно.

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

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

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

Зачем и чему учиться?

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

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

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

Список курсов постоянно пополняется с ростом функциональности продукта и запросов со стороны сотрудников по расширению матрицы компетенций. К примеру, недавно мы добавили курсы по работе SIP-протокола, а также по ряду других протоколов, задействованных в работе SSO (Single sign-jn).

Занимаясь обучением, мы тесно контактируем с продуктом и его менеджерами, чтобы вовремя добавлять технологии и протоколы, появляющиеся в МТС Линк. Коллеги показывают новые функции и советуют, что еще надо изучить.

Когда учиться?

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

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

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

Как мы контролируем обучение

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

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

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

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

Что дальше?

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

Самая часто встречающаяся «дорожка» — в QA. Специалисты техподдержки хорошо знают пользовательские кейсы, представляют, какие из них стоит добавить, как воспроизвести, какие сценарии обязательно нужно проверять после релиза той или иной фичи. Это очень ценные знания.

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

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

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

Как процесс выглядит с точки зрения бизнеса

Здесь простая математика. Каждое касание с клиентом стоит денег. Если новичок будет обрабатывать обращение за 20 касаний, а обученный специалист — за 10, все вложения в эти процессы уже окупятся, потому что стоимость обработки будет на порядок ниже, что напрямую влияет на метрики всего бизнеса.

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

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

Вместо итогов

Лучшее доказательство того, что мы движемся в правильном направлении — то, что коллеги остаются с нами надолго. Средняя продолжительность работы в отделе у наших сотрудников, как правило, несколько лет (до 3-х), но есть примеры, когда сотрудники работают дольше 5 и более лет. Далее они чаще всего переходят на другие позиции в компании или растут в новые профессии на рынке.

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

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