Сделано на совесть: Как правильно организовать поддержку продукта (на опыте Parallels)

Личный опыт

Руководитель отдела поддержки клиентов Parallels Евгений Стрельников и руководитель направления аутсорсинга Данил Гоношилин в колонке для «Нетологии» рассказывают, как правильно организовать поддержку продукта на основе опыта своей компании.

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

Мы начинали в 1990-е как небольшая компания с решениями для хостинга и группой техподдержки в несколько человек, а сегодня у нас миллионная аудитория по всему миру: только у одного Parallels Desktop для Mac более 5 млн пользователей. В процессе развития нам нужно было искать пути оптимизации затрат без потери качества, а заодно, как и всем, приходилось сталкиваться с разнообразными проблемами.

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

Затратная эффективность — девиз поддержки

Не секрет, что бюджет всегда ограничен, а потребности безграничны, приходится искать золотую середину. Вот что помогло нам сократить затраты (по некоторым направлениям — до 30%).

Аутсорсинг — потому что дешевле

По мере развития компании и увеличения клиентской базы мы столкнулись с проблемой того, что штат техподдержки разросся, и при этом мы просто не могли найти достаточное количество людей с техническими навыками и должным уровнем знания английского языка локально. Большинство наших клиентов находятся в США и Европе, поэтому поддержка осуществляется на английском языке. Плюс к этому необходимое количество сотрудников (headcount) сильно не попадало в бюджет. И тогда отдали на аутсорсинг все то, что может быть решено извне.

В настоящее время 95% заявок решаются агентами первой линии — аутсорсерами, которые находятся не в России. У нас есть прекрасный партнер в Индии, с которым мы сотрудничаем чуть более двух лет. Должны признать, что найти его было сложно — это была череда проб и ошибок длиной в пять лет, так как снижение показателей, постоянное утекание мало-мальски толковых инженеров были неминуемым итогом работы с тем или иным вендором. Мы успели посотрудничать с четырьмя компаниями, но в итоге нашли то, что искали.

Почему Индия? Ответ прост — достаточные знания и владение английским за вменяемые деньги. Можно, конечно, работать с Филиппинами, Восточной Европой или даже Штатами, но это будут совсем другие деньги, да и, как показал наш опыт, не все лучше, что дороже.

Универсальный солдат

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

Вроде бы все хорошо, но, анализируя эффективность команды как целого, мы поняли, что КПД далек от своего максимума. И тогда мы начали тренировать людей на работу со всем сразу: и с техническими проблемами, и со всем тем, что связано с лицензиями и аккаунтами. В результате необходимое количество сотрудников снизилось на 35%.

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

Self-service — наше все

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

На чем же мы сфокусировались?

Анализ всего объема входящих заявок с последующей категоризацией и выявлением ряда вопросов, которые можно решить силами self-service, и создание FAQ и статей, которые дают ответы на такие вопросы. Следует сказать, что задача это не единоразовая, анализ и обновление статей — постоянный процесс.

Сделано на совесть: Как правильно организовать поддержку продукта (на опыте Parallels)

Error reporting (регистрация ошибок) — ряд ошибок в продукте имеет вполне определенное решение, и если это решение может быть применено самим пользователем, то такие ошибки «связываются» с соответствующими статьями в базе знаний. В итоге клиент видит не только ошибку, но и ссылку на решение.

Intelligent search (умный поиск) — мы добавили поиск решения, когда клиент заводит заявку. Как это работает? Клиент заводит заявку и описывает проблему, при попытке отправить заявку наш поиск вычленяет из контекста проблему по ключевым словам и подбирает по ним подходящие статьи. Если они находятся — форма выдает их клиенту. Это помогло нам «срезать» 12% заявок.

Сделано на совесть: Как правильно организовать поддержку продукта (на опыте Parallels)

«База знаний» (БЗ). Если вы знаете, как ее готовить и поддерживать в актуальном состоянии, то это страшная сила.

Сделано на совесть: Как правильно организовать поддержку продукта (на опыте Parallels)

Исторически БЗ писалась и обогащалась тренерами по запросу. Запросы были хаотичны и не систематичны, поэтому много проблем и решений были просто ей не покрыты. В какой-то момент пришло осознание того, что мы делаем что-то не так и нужно что-то менять.

Сделано на совесть: Как правильно организовать поддержку продукта (на опыте Parallels)

Решением был Knowledge Centered Support (KCS) — методология и набор инструментов и процессов, которая расценивает знания как основное достояние любой организации по оказанию техподдержки.

Принцип KCS в том, что каждому обращению должна соответствовать статья из БЗ. Если ее еще нет, она создается агентом в момент обработки заявки. Таким образом, на каждый вопрос есть статья. В итоге покрытие статей стремится к 100%, и у всех участников процесса, будь то инженер или клиент, резко возрастают шансы найти релевантную статью для решения проблемы.

Knowledge Retention (накопление и сохранение знаний) — когда знание хранится в отдельных головах, оно с ними и покидает организацию. Думаю, все из вас сталкивались с подобной проблемой.

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

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

Отзывы — нам не все равно

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

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

Каждый фидбэк прочитан и услышан — мы читаем 100% опросов: и негативные, и позитивные. Позитивные, как правило, не требуют реакции с нашей стороны, каждый же негативный и связанная с ним заявка обрабатываются инженером контроля качества.

Net Promoter Score (NPS) — порекомендовали бы вы нас своим друзьям и близким? 100 процентов наших пользователей получают письмо от президента компании с этим вопросом через 30 дней после начала использования наших продуктов  и с просьбой оценить работу компании по шкале от 1−10.

В среднем 5% пользователей отвечают на это письмо. Все ответы читаются руководством, делаются выводы. Например, принимаются решения об изменении политики лицензирования или же функциональности продукта. В результате 80% тех, кто поставил плохую оценку (1−6) изначально, но получил удовлетворительный ответ от компании, после этого ставили хорошую оценку (7−10). Наш NPS один из самых высоких в индустрии ПО — порядка 33−35%. Средний NPS для продуктов из области программного обеспечения  — меньше 20%. А общеотраслевой показатель NPS — 5−10%.

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

Опции поддержки — сообщите нам о проблеме так, как вам удобно

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

Далее стало понятно, что не все готовы звонить на американский номер (о русскоговорящих клиентах не говорим, конечно же, номер 8 800 у нас есть), тогда мы внедрили Skype и Click-to-Call, которые позволяют совершенно бесплатно звонить на международные номера, используя компьютерное аудио. Удовлетворенность клиентов по пункту ease of contact (простота обращения в поддержку) увеличилась.

Сделано на совесть: Как правильно организовать поддержку продукта (на опыте Parallels)

Еще чуть позже осознали проблему присутствия или, если точнее, нашего отсутствия в социальных сетях и форумах. Решили исправляться. Выделили одного человека, но его не хватало, и в помощь ему была организованна команда из семи сотрудников, которые не только помогают нашим клиентам в Twitter и Facebook 24×7, но также обрабатывают звонки, чаты, email как обычные инженеры.

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

«Выездные» тренинги и коучинг — небольшие затраты, ведущие к существенной выгоде

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

Удаленный онлайн-тренинг с разработчиками перед выходом новой версии — это необходимый минимум, который мы могли обеспечить команде. Совсем других результатов удалось достичь, когда мы перестали жалеть сравнительно небольшие деньги на двух-трехнедельные командировки для инженеров поддержки второй линии, тренеров (тогда они располагались в Новосибирске) в центр разработки в Москве и к вендорам во время релиза. Скорость и качество подготовки увеличились в разы, вендорские показатели перестали падать в момент выпуска новой версии Parallels Desktop для Mac и Parallels Access и в течение двух месяцев после, как это происходило в прошлом.

Я хочу решение проблемы СЕЙЧАС!

Часто неважно, насколько правильное и детальное решение было предоставлено, клиент остается недовольным только потому, что ему потребовалось время, чтобы получить это самое решение. Что было нами сделано?

PUCC — смешно звучащий по-русски, но очень эффективный подход: Pick Up & Call Customer (возьми трубку и позвони). Идея очень проста — звонить клиенту для ускорения решения проблемы всегда, когда это только возможно. В нашем Request Tracker (инструмент для обработки заявок) для каждого клиента прописываются рабочие часы, в течение которых ему можно перезвонить. Мы перезваниваем, чтобы запросить какие-либо недостающие детали либо убедиться в том, что предоставленное решение помогло. Данная инициатива действительно помогла сократить время на решение заявки и позитивно воспринимается большинством клиентов.

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

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

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

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

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

Потом мы занялись налаживанием процесса взаимодействия с разработчиками, QA, менеджерами по продажам и внедрению.

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

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

Оцените статью

Средняя оценка 5 / 5. Всего проголосовало 1