Живя и работая в современном мире IT, мы все — рано или поздно, так или иначе — обращаемся в службу технической поддержки. Как это выглядит для нас, пользователей, все более-менее представляют. Но вот что находится на обратной стороне Луны? Немногие из нас знают, как обычно устроена служба поддержки в той или иной организации… Мало представляли себе и мы, как правильно организовать работу суппорта, когда более 10-ти лет назад перед нами встала такая задача. За это время мы прошли долгий путь, набили себе немало шишек, и теперь хотим поделиться с вами нашим опытом в этой сфере.В этой статье я расскажу вам, какими принципами руководствуется наша служба поддержки и какие приёмы использует в своей работе. Сейчас я хочу дать лишь краткий обзор, что и как у нас делается, а если по какому-то вопросу вам захочется побольше подробностей, могу написать об этом в дальнейшем.
Итак, как работают «Чип и Дейл» в компании DevExpress:
Никто не забыт. Ничто не забыто
(ни один вопрос не должен потеряться)
Одной из самых страшных ошибок в работе службы поддержки считается игнорирование пользователя. Поэтому мы стараемся сделать так, чтобы ни один вопрос, ни одна мольба о помощи не осталась без нашего внимания.
Когда мы поняли, что нам необходимо контролировать весь входящий поток вопросов, мы разработали для суппорта собственную систему учёта сообщений, aka Support Center. В этой системе за каждым вопросом пользователя закреплён сотрудник службы поддержки. Если человек, назначенный ответственным за вопрос, по какой-то причине не реагирует на него в нужное время (заболел, ушёл в отпуск или по иной причине покинул поле боя), у нас есть механизм оповещения об этом — чтобы координатор мог передать такой вопрос другому специалисту из службы поддержки.
У каждой проблемы может быть много внешних и внутренних статусов, зависящих от типа вопроса (например, баг может быть Reproduced, Fixed или By Design). Но при этом мы стараемся следовать правилу, что любое сообщение от пользователя изменяет статус проблемы на активный. Даже если человек просто написал «Спасибо!» — никогда не лишним будет ответить ему «Пожалуйста!»
Мы не спим сутками
(ответ на вопрос в течение 24-х часов)
Мы понимаем, что каждый пользователь хочет решить свою проблему как можно скорее. Поэтому, задавая свой вопрос нам, он точно знает, что получит ответ (самое позднее) в течение 24-х часов, без учёта праздников и выходных.
Конечно, если у нас получается, мы даём ответ значительно быстрее. Например, мы стараемся выделять и отслеживать наиболее лёгкие вопросы и давать на них ответ сразу же, как нашли их.
Но 24 часа на ответ в нашем случае — это необходимый минимум, который обусловлен тем, что наши пользователи распределены по всему миру. Кроме того, наша служба поддержки работает в несколько смен, чтобы обеспечить наилучшее покрытие разных часовых поясов.
Быстрее! Чаще! Полнее!
(количество реактиваций вопроса должно быть минимальным)
Если человек обратился в службу поддержки, значит, ему действительно нужна помощь. Поэтому мы стараемся помогать, а не «обрабатывать поступающие запросы». Для этого мы делаем так, чтобы наши ответы были как можно полнее. Например:
(плохой ответ):
«Как это сделать, написано в этом документе.»
(хороший ответ):
«Для того чтобы решить вашу проблему, вам нужно сделать то-то и то-то. Ещё вам может понадобиться это. Подробнее, вы можете прочитать здесь и здесь, а также посмотреть онлайн видео или скачать рабочий пример с нашего сайта. Если у вас есть ещё вопросы по этой проблеме, сообщите нам об этом, и мы будем рады вам помочь.»
Хождение по граблям
(мы коллекционируем все грабли, на которые кто-то уже наступал)
Мы решили сделать так, чтобы пользователи могли как можно быстрее найти ответ на свой вопрос, даже не обращаясь в службу поддержки. Тут мы исходили из того, что если кто-то хоть раз обращался с какой-то проблемой к нам, то эта информация не должна пропадать даром. Для этого мы делаем так:
- Все входящие вопросы, всё общение с пользователями происходит только на английском языке. В результате мы избегаем такой ситуации, что одна и та же проблема может быть записана и обсуждена на разных языках в нашей базе вопросов.
- Мы сделали публичной базу всех пользовательских проблем (вопросов, багов и реквестов). Конечно, если пользователь пожелает, он всегда может скрыть свой вопрос от людских глаз (например, если он послал нам свой код), но основная масса вопросов всё равно находится в публичном доступе.
- Мы реализовали собственный механизм поиска, максимально адаптированный под наши нужды и выдающий наилучшие результаты по базе наших вопросов. Этот поиск предлагает каждому пользователю поискать готовое решение до того, как он напишет свой запрос в нашу службу поддержки.
Скажи телефону «нет»
(мы не предоставляем телефонный суппорт)
Нам часто задают вопрос, почему у нас нет службы поддержки по телефону, ведь иногда она бывает очень полезна — много проблем возможно решить с помощью живого общения.
В нашем же случае мы считаем, что телефонный суппорт нам не подходит, так как почти для каждой проблемы требуется исследование кода пользователя или передача ему разных текстовых объектов, например, гиперссылок или примеров кода. Поэтому нам гораздо больше подходит поддержка через форумы, e-mail или специализированный веб-интерфейс.
Tell Me Why
(cамое главное, понять, зачем пользователь это хочет)
При рассмотрении вопроса пользователя, сначала мы всегда стараемся обращать особое внимание на выявление истинной проблемы пользователя, а не на то, почему способ, которым он пытается решить эту проблему, не работает.
Зачастую правильное понимание задачи пользователя значительно расширяет диапазон способов её решения, а значит, будет гораздо выше вероятность того, что хоть одно из них его удовлетворит.
…всегда есть два выхода!
(мы стараемся предоставить решение пользователю всегда, если это возможно)
Даже если проблема относится к особенностям функционирования продукта (By Design), мы всегда стараемся предложить клиенту альтернативное решение. А если же такого способа не существует, то мы даём пользователю знать, что мы собираемся делать в этом направлении:
- Если такая функциональность может быть добавлена в продукт, то мы документируем предложение пользователя в каком-то виде и, в идеале, даём ему публичный способ отслеживания статуса его реквеста в нашем Суппорт Центре.
- Если же подобная функциональность не может быть добавлена в продукт ни при каких условиях, то мы честно сообщаем об этом пользователю, чтобы уже он сам принимал дальнейшие решения об использовании нашего продукта.
Мы всегда думаем о вас
(работа над проблемой пользователя идёт, даже если «мяч на его стороне»)
Ещё один важный приём, который использует наш служба поддержки в своей работе: follow-up'ы.
Например, мы уже отправили ответ пользователю, а через какое-то время кому-то из нас пришла в голову светлая мысль, как ещё можно было бы помочь пользователю решить его проблему. В этом случае, мы добавляем дополнительную информацию в нашу переписку с пользователем, не дожидаясь, пока он сам реактивирует свою проблему.
Причём эта информация может оказаться полезной не только для этого конкретного пользователя, но и будет полезна всем остальным, кто прочитает нашу с ним переписку впоследствии (в случае, если проблема записана как публичная), а значит, ценность любого дополнения возрастает многократно.
Банку колы и хот-догфикс, пожалуйста
(проблема устранена только тогда, когда она устранена у пользователя)
Ещё одно важное правило, к которому мы пришли в своей работе: мало просто диагностировать проблему — особенно в том случае, если это баг в продукте — главное, как можно быстрее избавить пользователя от этой проблемы.
Например, пользователь нашёл в продукте баг, из-за которого невозможно продолжать работу. Если мы просто подтвердим, что это баг, и сообщим пользователю: «Ура! Баг исправлен! Ждите следующий апдейт… который будет через полгода», он будет оставаться недовольным всё это время, причём недовольство его будет расти с каждым днём. Чтобы избежать подобных проблем, мы построили работу в DevExpress по обновлению наших продуктов таким образом, чтобы в любой момент любой пользователь мог получить новый билд, содержащий хот фикс к его проблеме.
Программист — друг суппортиста
(разработчки и суппортисты — одна команда. И лучшие друзья пользователя)
Инженер службы поддержки всегда находится между двух огней. С одной стороны, ему нужно решить проблему пользователя, и как можно скорее; с другой — очень часто для того, чтобы найти причину этой проблемы, и уж тем более, чтобы пофиксить баг, ему не обойтись без помощи разработчиков. А разработчики продукта практически всегда заняты своими делами по горло, и поэтому им бывает очень сложно войти в положение суппортиста.
Чтобы исправить эту ситуацию, мы используем следующие приёмы в своей работе:
- Разработчики и суппортисты по одному продукту (или группе продуктов) объединены в одну команду. Они сидят в одной комнате и у них одна цель — сделать продукт успешным, а его пользователей счастливыми. Это позволяет повысить эффективность взаимодействия и взаимопомощи между нашими сотрудниками на человеческом уровне.
- Большинство разработчиков периодически выделяют немного времени, чтобы отслеживать входящий трафик вопросов по их продуктам. Если им есть что сказать по проблеме пользователя, то они пишут свои комментарии для суппортистов. Если же они видят, что какой-то вопрос задаётся слишком часто, то это уже повод дополнить документацию или даже улучшить продукт в этом направлении.
- В исключительных случаях, если у службы поддержки по какой-то форсмажорной причине скопилось чрезмерное количество вопросов, то разработчики продукта или другие люди, участвующие в процессе разработки (например, технические писатели), берут на себя функцию по поддержке пользователей. Опыт живого общения с пользователями собственного продукта в этом случае имеет особую ценность для наших разработчиков и помогает им лучше понимать, чего хотят люди от продукта.