«Проблема не из-за нашего продукта»: как мотивировать техподдержку помогать больше, чем должны

В статье рассказываем, как за год с помощью изменения системы мотивации, собственного приложения и синей изоленты повысили уровень клиентской удовлетворенности (CSAT, Customer Satisfaction) до 95,5%. Это немного больше, чем планировали.

В 100% довольных клиентов директор клиентского сервиса ispmanager Николай Глазунов не верит: «Всегда будут пользователи, которые задают нашим ребятам вопросы: „Ваша панель — убожество, почему вы не раздает ее всем бесплатно?“, „Я вчера заказал стиральную машинку, почему ее до сих пор не привезли?“, „Можно ли у нас телек купить?“. Все это — реальные примеры тикетов. Иногда даже думаем запартнериться с ритейлером бытовой техники...»

Проблема: просто закрыть тикет 

Часто техподдержка — это конкурентное преимущество продукта. И когда в 2022 году ispmanager стал самостоятельной компанией и начал развивать один основной продукт, мы решили разобраться, как повысить уровень клиентской удовлетворенности.

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

Николай Глазунов

Директор клиентского сервиса ispmanager

Тогда я увидел, что специалисты техподдержки не понимали, зачем они что‑то делают. Казалось, их целью было не помочь клиенту разобраться в проблеме, а снять с себя ответственность: «Видим, что у вас проблема, но это к нашему продукту не имеет отношения».

Вот анализ итогов опроса пользователей в начале 2023 года.

Причины негатива клиентов:

73% — ошибки техподдержки. Могут быть техническими, коммуникационными, или связанными с отсутствием проактивности — искреннего желания разобраться в проблеме пользователя.

14% — «другое». Это когда клиенты спрашивают что‑то вроде: «Можно ли у нас телек купить?» или «Почему ваш продукт — говно».

13% — ошибки в продукте и отсутствие каких‑то фич. Информацию об этих ошибках и запросы на новый фичи передаем в разработку.

Мы поставили такую задачу:

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

Решение: создаем мотивацию решать проблему пользователя

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

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

Прежде всего люди должны понимать:

• какая у нас главная цель,

• что нужно делать,

• где взять информацию,

• куда идти, если что‑то идет не по плану.

За полгода мы создали:

• Понятное описание бизнес‑процессов и схемы действий.

• Программы обучения сотрудников.

• Налаженное взаимодействие с другими отделами — куда идти в срочной ситуации, когда вопрос не к техподдержке. Например — если люди пришли с предложениями по развитию продукта или что‑то хотят уточнить у отдела продаж.

• Удобный инструментарий работы поддержки — тикетница и система коммуникации внутри отдела.

Теперь уже могли повышать зарплаты, выделять премиальную часть и вводить KPI.

Обсудили показатели эффективности техподдержки. Показатели не прибиты гвоздями — мы начали с одних, по ходу дела тестировали, что‑то меняли, подкручивали. Например, сразу было очевидно, что для наших клиентов не самое главное мгновенный ответ — например, в первые 5 минут после обращения. Важнее его качество. Хотя сейчас в 67% тикетов первый ответ мы даем в течение 30 минут. В 87% — в течение часа. 66% тикетов закрываются в течение часа — от первого обращения до итогового ответа.

Изменили систему оплаты. Чтобы мотивировать людей совершать нужные действия, мы сделали 30% от зарплаты инженеров премиальной частью. Премия умножается на KPI и может быть нулевой, а может — 120%.

Ввели прозрачный подсчет KPI. Чтобы решить проблему прозрачного подсчета KPI, мы создали собственный инструмент — QA‑модуль. За рубежом подобных приложений мы знаем около двадцати, но в России они не особенно распространены.

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

Как устроен QA-модуль ispmanager

Как работает. Приложение через API подтягивает тикеты, звонки и чаты из тикетной системы техподдержки ispmanager и передает их на оценку администраторам. Это инженер контроля качества и сотрудники других отделов компании — подключить можно любого, если потребуется. Тикеты оцениваем по списку критериев, а приложение считает KPI.

Роли:

1. Администратор — инженер контроля качества. Ставит задачи на оценку, помогает в работе с приложением и собирает ежемесячную статистику.

2. Тренер — оценивает работу инженеров техподдержки. Тренерами могут быть сотрудники разных отделов любой квалификации.

   Например, мы привлекаем:

   ✓ Топ‑менеджеров. Так мы решили множество взаимонепониманий между отделами и смогли настроить работу техподдержки максимально близко к ожиданиями бизнеса.

   ✓ Разработчиков — они видят как люди пользуются панелью, с какими проблемами сталкиваются. Это помогает им понимать, как сделать ispmanager полезней.

   ✓ Менеджеров по продажам‑ они комментируют ответы первой линии и помогают инженерам коммуницировать проактивно.

3. Инженер техподдержки смотрит, как его оценили, радуется или печалится.

4. Арбитр — по запросу решает, справедлива ли оценка. Так бывает, если инженер не согласен с тем, как оценили его действия и подает тимлиду запрос на арбитраж. Назначается арбитр и разбирает спорную ситуацию.

Оценки. Карта оценок — набор заранее сформулированных вопросов. Тренеру приходит сообщение с кнопкой «Начать оценку». Он отвечают на вопросы и из этого складывается KPI инженера техподдержки.

Вот как выглядит тикет на оценку тренера.

Свои карты оценки у 5 разных команд техподдержки— у каждого подразделения свои задачи и нужны разные вопросы для оценки качества:

• первая линия техподдержки,

• вторая линия техподдержки,

• звонки,

• онлайн‑чаты,

• платные услуги администрирования.

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

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

Для каждого вопроса есть варианты ответов:

• «Да» — максимальная оценка.

• «Нет» — минимальная оценка.

• «Не совсем» — среднее значение оценки.

• N/A — исключает вес вопроса из суммарной оценки и пересчитывает баллы.

Система запрашивает у тренера комментарий, если ответ «Нет» или «Не совсем» — и оценивающие обязательно пишут, что именно не так. Хотя модуль можно настроить и по‑другому.

Оценка десяти тикетов в неделю, отнимает примерно 20–30 минут. У тренеров с небольшим опытом даже меньше — они пишут менее объемные комментарии.

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

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

Вопросы в картах оценок прописывает администратор — вопросы и их вес легко менять.

Подробнее о QA‑модуле в его документации →

Результат

Каждому клиенту мы отправляем контакты для обратной связи после закрытого тикета. Обычно обратную связь оставляют до 15% клиентов. Наши пользователи отвечают более чем в 40% случаев. В конце 2023 года мы обнаружили, что за год оценка работы техподдержки выросла с 93% до 95,5%.

Николай Глазунов

Директор клиентского сервиса ispmanager

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

Основной результат принесла быстрая обратная связь в ответ на работу инженеров техподдержки.

Помогли:

• Понятные цели, к которым были привязаны к KPI.

• Инструментарий, который обеспечил прозрачную оценку действий инженеров техподдержки — QA‑модуль.

Так получилось потому, что в ispmanager уже была база для изменений:

• Понятно описанные бизнес‑процессы и схемы действий.

• Программы обучения сотрудников.

• Налаженное взаимодействие с другими отделами — куда идти в срочной ситуации, когда проблема не на стороне техподдержки.

• Удобный инструментарий работы поддержки — тикетница и система коммуникации внутри отдела.

Без этой базы процесс длился бы дольше.

Как помог  QA-модуль

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

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

QA‑модуль обеспечил:

Скорость реакции на смену цели. Например, в какой‑то момент стало ясно, что вопрос из карты оценок «Был ли предоставлен workaround» не отражает приоритетов клиента. Людям было важнее получить подробный ответ. И мы несколько раз повысили оценку за вопрос «Был ли дан объемный первый ответ клиенту».

Николай Глазунов

Директор клиентского сервиса ispmanager

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

С быстрой обратной связью через QA‑модуль новые приоритеты усваиваются сразу — если изменить веса вопросов или сами вопросы.В обычной ситуации людям требуется пара месяцев, чтобы перестроиться.

Прозрачность. Бизнес в курсе, что, как и почему делает техподдержка — до того, как кто‑то из клиентов придет с негативом. Раньше топ‑менеджеры и сотрудники других подразделений не всегда были в курсе, что делает техподдержка. Теперь все могут открыть QA‑модуль и проверить.

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

Эффективность. Благодаря автоматизации у инженера контроля качества освободилось время — и теперь он улучшает программу обучения коллег.

Николай Глазунов

Директор клиентского сервиса ispmanager

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

Здесь новая система KPI и QA‑модуль помогли только косвенно. Если критерий работы — доволен ли клиент, то QA‑модуль помогает видеть, хотел ли инженер техподдержки помочь на самом деле.

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

О том, как устроена внутренняя система обучения и грейдов расскажем во второй части статьи.