Хочу подписаться под каждым словом в этой статье.
Пойду распечатаю и повешу на стену.

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

Сразу поясню, что эти советы/правила больше относятся к саппорту через HelpDesk или e-mails, у телефонной поддержки есть некоторые свои особенности.

1. Быстрая реакция и ответы.

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

К сожалению быстрый саппорт, доступный 24/7, это дорого: нужно больше людей и нужна круглосуточно доступная инфраструктура. Чаще всего это просто невыгодно, особенно если вы не крупная корпорация, а маленький стартапчик.

В этом случае нам поможет одна интересная штука.

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

Эта штука позволяет сильно повысить удолетворенность от саппорта, не увеличивая штат и количество работающих саппортеров.

К примеру, клиент А известил нас о проблеме. Инженер Ц приступил к её решению, через 20 часов проблема была решена. Инженер известил клиента об этом. То есть время от репорта проблемы до её решения — 20 часов.

Вторая ситуация: клиент Б известил нас о проблеме. Ему тут же приходит нотификация, что его запрос получен и примерное время реакции — N часов.
Инженер Ц приступил к решению проблемы и написал, что, скорее всего, проблема вызвана вот этим вот и ближайшие результаты будут через два-три часа. Через три часа инженер пишет, что нашел точную причину, но решение займет время и будет готово завтра. Завтра, через 20 часов от исходного репорта, проблема решена.

И в первом и во втором случаях проблема была решена одинаково быстро — за 20 часов. Но во втором случае у клиента останется впечатление, что мы отреагировали и решили проблему быстро.

Информированный клиент, — радостен и щастлив с большой буквы ща.Это вообще отдельная тема, затронутая ниже. Неинформированный — злится, пишет гневные письма и топает ногами. И его можно понять — у него проблема, а он не знает, чего ожидать от будущего.

2. Ясное объяснение.

На мой взгляд, ответ/отчет саппортера о решенной проблеме должен отвечать на следующие вопросы:

• чем вызвана проблема?
• что было сделано для решения проблемы? что еще надо сделать?
• решена ли проблема полностью сейчас или нет?
• может ли возникнуть проблема в будущем? если да, как этого избежать? [опционально]

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

Пример.
Клиент пишет: "Мой сайт не работает, ПОМОГИТЕ!"
Инженер отвечает: "Мы решили данную проблему, проверьте пожалуйста ваш сайт."

Это плохой, негодный ответ, несмотря на наличие слова «пожалуйста». Хорошо, что сайт работает, но что же все таки было?

Хороший ответ выглядит примерно так:

«Мы проверили ваш сайт. В файле site/file.php была синтаксическая ошибка, из-за которой всё не работало.
Мы отредактировали этот файл и исправили данную ошибку, в настоящий момент все работает правильно, проверьте пожалуйста: [ example.com ]
Мы не знаем, кем был изменен файл. Дата изменения — ДДММ. Я проверил последние ваши последние запросы, никто из наших инженеров не работал с вашим магазином. Я сохранил файл до моего изменения. Оригинальный и измененный файлы присоединены к моему сообщению. Пожалуйста свяжитесь с Вашим хостингом и проверьте FTP логи, чтобы выяснить, кем было сделано некорректное изменение.»

Этот ответ даёт информацию, тем он и хорош. Используя этот ответ, клиент может найти виноватого в проблеме или, например, решить подобную проблему в дальнейшем самостоятельно.

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

3. Никогда не спорьте с клиентом.

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

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

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

Пример из жизни:
Клиент захотел переместиться из одного хостинга в другой. В процессе перемещения сайта, клиент без предупреждения слишком рано изменил DNS сервера своего домена. Как результат — сайт недоступен. Он пишет: "Ах, вы, олухи, у вас отвратительный сервис, у меня всё не работает. Вы все сломали! А-а-а, панике!!".

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

Нет, это не нужно. Поэтому пишем такое: «Дорогой клиент, тысяча извинений за эту проблему. Это наша ошибка, мы виноваты. Мы должны были предупретить вас, что менять DNS сервера еще рано. Мы вас не предупредили и это вызвало ошибку. Еще раз извините и попробуйте изменить их еще раз. Все будет работать как надо»
Клиент может побурчать, но чуть-чуть, и на самом деле он будет доволен, что не он накосячил, а мы, и мы это признаем. И он нас полюбит.
Мы забыли о своей гордости, взяли отвественность на себя, а взамен получили довольного клиента, который хочет дать нам денег.

4. Давайте решение.

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

Например, сайт не работает из-за ограничений хостинга. Какие могут быть решения?

• можно изменить сайт, приспособив его под ограничения хостинга
• можно сменить хостинг
• можно обратиться к хостингу и попросить убрать ограничения

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

5. Клиент не дурак.

Не считайте клиента идиотом. Одна из проблем IT-индустрии и саппорта в том, что клиента считают существом низшего сорта, потому что он не знает, что такое Perl и PHP, считает, что компьютер это такой телевизор на столе, и зависает на одноклассниках.ру. Да, клиент не разбирается в технических штуках.
Да, он «блондинка», ничего не умеет и бывает, всё ломает. Так радуйтесь же этому!

Именно поэтому клиент приходит к нам, в саппорт, к IT-спецам. Если бы клиент разбирался бы в этих штуках, то в нас не было бы нужды.
Он зато, наверное, разбирается в других вещах, в продажах, ведении бизнеса, и так далее.

А если считать клиента идиотом, то это всё прекрасно чувствуется. А кому хочется общаться с людьми, которые считают тебя идиотом?

Вы скажете: а как же вредные, странные, неадекватные клиенты, как общаться с ними? Ребята, таких клиентов не бывает. И чем раньше вы в это поверите, тем быстрее ваш саппорт будет клёвым и офигительным.

Cчитайте их просто такими взрослыми детьми. Дети могут не понимать каких-то вещей, капризничать, топать ногами, обижаться. Вы же не обижаетесь всерьёз на детей, ведь так? Так и тут, пожалейте их, успокойте, объясните простыми словами, что желаете им добра. Это действует.
Когда клиент не понимает, что мы хотим сказать, объясняйте как себе, как своей собственной маленькой сестре, которая этого технического языка не понимает, объясняйте образами.

Ну и самое главное: клиентов нужно любить. Они это чувствуют и отвечают тем же: -)

[ ➜ ]