4 фатальные ошибки руководителя поддержки

Моя нервная система до сих пор шоке от развенчания главных мифов про клиентский сервис (писала про большое исследование здесь), а тут подоспел очень интересный вебинар про фатальные ошибки руководителя поддержки 🙈 От каждого пункта хочется плакать, потому что мне близка каждая из этих ошибок, прямо каждая.

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

1. Пытаться сделать суперклиентоориентированный, супербыстрый и суперзаботливый человеческий саппорт
2. Ввести побольше каналов связи, чтобы клиенты могли обращаться в поддержку как хотят
3. Не собирать обратную связь про поддержку по принципу “всё равно клиенты плохо пишут про продукт, а не про нас”
4. Вообще не использовать шаблоны во имя супер-индивидуального подхода к клиенту

Ну а теперь подробнее про каждую ошибку — как надо и как не надо 👇

Ошибка 1:
Пытаться сделать суперклиентоориентированный, супербыстрый и суперзаботливый человеческий саппорт

Все мы там были, да 😅 Минусы и подводные камни такого подхода:

• Сразу всплывают проблемы найма: где найти таких суперзаботливых и эмпатичных (особенно если надо нанять не 10 человек, а 100).
  А ещё эмпатии невозможно научить, она либо есть, либо её нет.
• Поддержка — операционный отдел, работающий строго по бизнес-процессам, а не по наитию. Как мы свяжем суперзаботу о клиентах с эффективностью отдела?
• Если в продукте проблемы, их нельзя решать с помощью милой и лояльной поддержки, надо менять продукт.

Вывод:

• Сама по себе цель неплохая, но надо, чтобы она соответствовала целям бизнеса.

Как надо делать:
Строить саппорт, который соответствует бизнес-целям компании

• Наладить совместные процессы с продуктовой командой.
• Отслеживать метрики
  📊 операционные: SLA, FCR, FRT, CSI
  📊 продуктовые: какая часть клиентов обращается в поддержку, стоимость контакта клиента в поддержку для компании, число обращений клиентов по конкретным фичам/проблемам продукта.
  Важно: все метрики надо считать по сегментам клиентов!

Оставлю ссылки на три подробные статьи на эту тему:

• Польза ABCDX-сегментации клиентов для всех отделов компании
• Как выстроить работу отделов R&D и Customer Support, чтобы они друг друга не переубивали
• Bug Manager из техподдержки как адвокат клиентских проблем для разработчиков

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

Минусы и подводные камни:

• Это плохо для клиента: выбор канала — это проблема.
  А ещё в разных каналах могут долго отвечать или не отвечать вообще, в результате клиент начинает слать дубликаты своего запроса во все имеющиеся каналы.
• Это плохо для вас:
  ➖ сложно операционно поддерживать много каналов
  ➖ нагрузка из-за повторных обращений в разных каналах
  ➖ сложно считать статистику
  ➖ дополнительно надо будет вычищать все эти дубликаты обращений в разные каналы (например, чтобы оно не лезло в статистику и можно было грамотно спланировать нагрузку на команду)

Вывод:

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

Как надо делать:
Создавать каналы с настроенным процессом поддержки

• Не нужно гнаться за модой и конкурентами.
• При решении добавить новый канал всегда задавайте себе вопрос “чтобы что?” (например, у нас появляется новый тип VIP-клиентов).
• Стройте многоканальную систему с интеграцией CRM.
  Ваша задача — при обращении понять, что это за клиент, и быстро ему ответить (условно: при обращении клиента вы сразу видите в CRM вы сразу видите, что у клиента один заказ в статусе “задерживается” и оплата по нему прошла давным-давно).
  Больше данных из CRM на входе — быстрее обработка обращений.
• Структурированные данные на входе всегда проще работать, плюс это простор для разных автоматизаций.

Дополнительно:

• Хорошо бы уметь сравнивать эффективность каналов между собой, чтобы понимать где клиенты получают самую эффективную поддержку 🔥

Ошибка 3:
Не собирать обратную связь про поддержку по принципу “всё равно клиенты плохо пишут про продукт, а не про нас”

Минусы и подводные камни:

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

Вывод:

• CSI — лицо отдела и компании, метрика действительно говорит о том, какими вас видят клиенты.

Как надо делать:
Включить CSI и автоматизировать работу с ним

• Задавайте правильные вопросы, кастомизируйте форму CSI, чтобы клиенты оценивали именно работу поддержки, а не, например, доставки (статья в помощь: Опросники для оценки качества технической поддержки).
• Реагируйте на плохие оценки немедленно с помощью автоматизации (например, можно отправлять копию руководителю поддержки, сразу переоткрывать тикет и т.п.)
• Плохие оценки клиентов по продукту надо отдавать продактам, что ещё раз возвращает нас к важности налаживания связей между отделами R&D и поддержки.

Ошибка 4:
Вообще не использовать шаблоны во имя супер-индивидуального подхода к клиенту

Минусы и подводные камни:

• Сочинение персонализированных ответов может быть сильно в ущерб скорости ответа.
• Отсутствие шаблонов может влиять на чистоту соблюдения бизнес-процессов. Любая ситуация всегда укладывается в определенные сценарии, помогающие решить проблему. Если у вас нет шаблонов, то возможно, у вас нет понимания сценариев обслуживания в той или иной ситуации 🤔

Вывод:

• Шаблоны — это не только “Добрый день, <customer_name>!”, а ещё много полезных инструментов.
• Шаблоны и скрипты структурируют понимание сценариев обслуживания и ускоряют решение проблем.

Как надо делать:

• Сделайте шаблоны не раздражающими.
• Если используете ботов — так и скажите, не надо выдавать их за сотрудников поддержки.
• Если вы знаете потенциальные проблемы или вопросы, которые могут возникнуть у клиента после вашего ответа — сразу зашейте это в шаблон, тем самым повышая FCR.
• Зашейте подсказки в последовательность работы оператора поддержки (“попроси ссылку”, “попроси прислать скриншот”, и т.п.)

Уфффф, вот и добрались до конца статьи. Сколько ошибок руководителя поддержки вы насчитали у себя? Я — все 🤪 Так что будет мне задачка к размышлению на выходные!

Бонусные статьи в тему 🔥

• Как повысить лояльность клиентов (часть 1: метрики)
• Как повысить лояльность клиентов (часть 2: причины плохого сервиса)
• ChatGPT в работе клиентской поддержки
• Использование GPT-бота в чатах с клиентами (практический кейс)

Ссылка на видео:
Внимательный человек заметит, что в моей выжимке упомянуты 4 ошибки, а в видео их 5, последняя относится скорее к ТЗ и требованиями при выборе тикет-системы для поддержки клиентов, поэтому я её подробно не описываю; при желании можно посмотреть здесь с 44-й минуты.