Методики построения лучшего клиентского сервиса от мирового лидера

Недавно прочитала очень крутую книгу компании Intercom про их принципы тех.поддержки и лайфхаки построения лучшего клиентского сервиса (а они действительно им славятся на всю индустрию!).

Всего 120+ страниц, и там есть всё — от принципов найма сотрудников, планирования нагрузки и введения базовых метрик до принципов организации Help Center, взаимодействия с клиентами и разбора сложных вопросов, наподобие “стоит ли предоставлять поддержку по trial-версиям ПО?”.

Ниже будет короткая выжимка того, что импонирует лично мне (то есть это не классический конспект всей методички), очень рекомендую скачать здесь полную версию книги Intercom и ознакомиться, это действительно клад: https://www.intercom.com/books/customer-support

Примечание: в их секции “Books” доступно для скачивания ещё много отличных методичек про product management , sales, работу с клиентами и так далее. Так что можно не ограничиваться только саппортом :)

Эволюция стартапа (и поддержки!)

• Даже если ваш продукт вообще не имеет багов и у него супер-понятый интерфейс, то со временем количество обращений от клиентов всё равно будет расти, потому что люди обожают задавать вопросы (best practices, какие фичи планируется ввести в следующем релизе, какие у вас достоинства по сравнению с конкурентами и пр.). Здесь яростно плюсую, потому что множество клиентов действительно спрашивают, как лучше использовать фичи или что там новенького планируют выпустить программисты. И если на эти вопросы отвечает только основатель компании, то поначалу это ещё нормально, а потом, с ростом числа клиентов, это труба, поэтому даже на ранних стадиях становления стартапа имеет смысл нанимать человека в поддержку, который будет отвечать на весь входящий поток вопросов.
• Далее, в идеальном сценарии, компания эволюционирует дальше, и важно вовремя ввести первые метрики того, насколько “завален” текущий сотрудник, и не пропустить момент найма следующего сотрудника поддержки (или нескольких). Здесь лучше привести ёмкую цитату из книги: “Put simply you need to think about hiring in advance of demand. As Henry Ford famously said, “If you need a machine and don’t buy it, then you will ultimately find that you have paid for it and don’t have it.” The same is true for support. If you need another support rep and don’t hire them you’ll pay the full cost of hiring them but still won’t have them.”
• Интересный график того, как меняется качество поддержки в компании с эволюцей стартапа и ростом команды:

Ключевые навыки для сотрудников поддержки

Список выводился по скиллам топ-1300 самых лучших агентов тех.поддержки (ссылка на книгу-источник), по важности идёт сверху вниз, то есть 1 — must have, 2 — следующий за ним, и так далее:

1. CONTROL QUOTIENT: умение работать со стрессом, умение нести ответственность, адекватная реакция на критику, в т.ч. от руководства, умение концентрироваться.
2. EMOTIONAL INTELLIGENCE (EQ): эмпатия, умение работать с разными клиентами (например, разных темпераментов), умение защищать интересы клиента, убедительность.
3. BASIC SKILLS AND BEHAVIORS: знание продукта, технологическая экспертиза, умение эффективно коммуницировать, умение задавать правильные вопросы, мультизадачность.
4. ADVANCED PROBLEM SOLVING (IQ): любопытсво, креативность, критическое мышление, склонность к экспериментам

Виды тех.поддержки

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

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

Эффективность таких форм саппорта и размер команды в разных случаях:

Написание хорошего контента для Help Center

Ещё одна большая глава про то, как написать действительно хороший контент и как его потом не забывать обновлять :) По моему опыту, отличные работающие советы, сама не раз применяла некоторые из описанных методик.

• Для FAQ: сотрудники поддержки тэгируют или помечают слишком часто звучащие вопросы, потом раз в N дней ты садишься и пишешь контент по этим вопросам. Если клиенты часто спрашивают, почему в продукте нет такой-то фичи, имеет смысл описать в FAQ почему и обязательно привести альтернативные способы решения.
• Признаком того, что ты написал действительно хороший best practices guide является то, что люди начинают чаще использовать продукт.
• Хороший контент Help Center, помимо своей основной функции, работает ещё и на продажи: потенциальные клиенты видят фичи и нужные им применения продукта, уже описанные в статьях.
• Заголовки статей должны фокусироваться на задачах клиента, не на названии фичи (например, “как сократить время на обработку проекта” вместо “как работает такая-то галочка в настройках”). Аналогично с мануалами — проблема большинства из них в том, что они строятся вокруг описания конкретной функции, а не того, как и в каких случаях клиенту её надо использовать.
• И ещё про мануалы — иронично, что для новых клиентов компании как правило вкладываются в логичные и понятные landing pages с хорошей структурной подачей информации, а для имеющихся клиентов как правило есть тонна не самой структурированной документации 10-м кеглем (нумерованные списки, картинки в нужных местах и грамотное разделение на параграфы рулят!).
• Самый простой и быстрый способ написать troubleshooting guide — адаптировать внутренние саппортовские документы для клиентов.
• Удалять надо не только устаревший/неактуальный контент, но и lowtraffic articles — статьи, которые клиенты больше не смотрят. Причина: они “замусоривают” Help Center, так что клиенты тратят больше времени на поиск действительно нужной информации

Сокращение расходов и объемов поддержки

Если смотреть цинично, то каждый тикет от клиента либо irritating, либо valuable как для клиента, так и для компании, и надо уметь их разделять:

А потом с ними надо что-то делать, например:

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

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

Информация к размышлению про поддержку триальных пользователей, которые не платят за продукт:

В самой книге этому посвящена большая глава c делением таких “неплатящих” пользователей на типы и советами по каждому типу. Моя команда, в своё время, принципиально оказывала полную поддержку и триальным пользователям в том числе (этот подход не без минусов, но тогда овчинка стоила выделки). Ниже некоторые интересные тезисы.

• Изначально это вопрос грамотного баланса: если не соблюсти баланс фич, которые выдаются бесплатно всем пользователям, то компания очень легко попадает в ловушку того, что некоторые люди в принципе потом ничего не купят и продолжат пользоваться продуктом как есть.
• Человек, не платящий за продукт ни цента, но задающий вопрос, занявший 30 минут времени сотрудника поддержки, стоит компании как 30 минут времени сотрудника, плюс фиксированные косты (хостинг, инфраструктура, пр.)
• Если на поддержке 10 пользователей и 4 из них триальщики, то уровень сервиса, который будет оказываться 6 платящим клиентам, закономерно снизится (по сути они получат худший сервис за свои деньги).
• Есть варианты понизить приоритеты тикетам от триальщиков, есть варианты переключить их на sef-service support.
• Очень интересное замечание про разницу в фичах, запрашиваемую триальщиками и платящими пользователями (не раз такое замечала): “Free users always want more, paying customers always want
  better. More isn’t better. Better is better. <…> Free users ask for bew features, paying users ask for improved features.”

Вместо заключения:

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

Я с ними согласна — тех.поддержка не должна быть “командой в вакууме”, когда проблемы и жалобы клиентов, благодарности за фичи продукта, интересные кейсы и гэги остаются исключительно внутри команды, или (ещё хуже) когда вся команда поддержки состоит из людей, вечно извиняющихся за косяки программистов и/или руководства. Процитирую Intercom:

“Similarly, an isolated support team evolve into apologists. With no direct connection to the product team they adapt their workflow accordingly. Instead of becoming excellent at communication, customer education, and case analysis, they come up with 20 different ways to say “We know, we’re sorry”. <…>

Remember: support is everyone’s business. This shouldn’t be a one-way street with support figuring out ways to help other functions in the business. It’s essential everyone in your business appreciates the importance of support and is exposed to the kind of issues that customers regularly face.”

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