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

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

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

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

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

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

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

Вот анализ итогов опроса пользователей в начале 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 инженера техподдержки.

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

Слева находится переписка с клиентом, справа — карта с вопросами. Опционально администратор группируют вопросы по секциям: те, что в основной секции, сильнее влияют на KPI

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

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

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

• звонки,

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

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

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

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

Как выглядит форма, где можно добавить вопрос для оценки качества тикета

Пример вопроса с вариантами ответов и полем для комментария

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

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

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

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

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

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

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

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

Фрагмент письма для инженера техподдержки. По кнопке «Перейти к оценкам» сотрудник увидит все оценки и KPI

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

Как выглядит таблица с KPI

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

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

Результат

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

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

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

Помогли:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

© Habrahabr.ru