Кугаевский блог

Саппорт – лицо компании для пользователя.

Лицо должно быть красивым, улыбающимся и приветливым.

Пользователь – живой человек.

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

Любое письмо – вопрос.

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

Читай переписку.

Тебе понравится, когда одно и то же спрашивают по несколько раз? Обязательно читай переписку полностью.

Сокращай итерации.

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

Одно предложение – не ответ.

Ответ обязан содержать помимо ответа на вопрос пользователя еще и объяснение причин возникновения проблемы. Ответ в одно предложение – отписка.

Непонятного – боятся.

Письмо в поддержку – крик о помощи. У пользователя что-то пошло не так. Он не понимает в чем дело. Ответ должен успокоить его, а не вогнать в еще большую панику. Саппортер – всегда немного психолог.

Не задерживай ответ.

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

Ты – не робот.

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

Не бойся спрашивать.

Если не знаешь, что ответить пользователю – спроси у коллег. Лучше узнать точно, чем показать свою некомпетентность в вопросе пользователю. Не поленись проверить ответ перед отправкой.

Николай Кугаевский Support 10, basics

Когда же компания понимает необходимость выделения отдельной структурной единицы для поддержки пользователей?

Обычно, это выглядит так: небольшой стартап разрастается, набирает жирок. Количество юзеров потихоньку увеличивается, и программист (менеджер проекта, админ), ранее уделявшие общению с ними некоторое количество рабочего времени, уже не успевают отвечать на входящую почту/звонки. Или просто надоедает отвечать на “Почему не работает?” и “А чо это ваще такое?“. Надо вводить разделение обязанностей и организовывать отдел саппорта. Обычно, растущие проекты подходят к этому довольно-таки наплевательски. Ну а чо? Посадим студента Петю, пускай за n вечнозеленых единиц в почту смотрит и на звонки отвечает. Работёнка не пыльная – квалификации особой не требует. Расскажем ему за полдня что такое наш сервис/программа и вперёд!

Проекту очень повезет, в том случае, если студент Петя не редиска, и отнесётся к работе серьёзно и поймет, что он теперь не просто мальчик на телефоне, а будущий руководитель отдела, о чем в большинстве случаев просто забывают упомянуть. В большинстве случаев происходит наоборот: Петя считает (не потому что он такой плохой, а потому что так объяснили работодатели), что он сидит на телефоне и в ус не дует, его обязанности – отвечать юзерам. Не справляюсь с растущим количеством заявок юзеров, да и хер с ним – гори оно всё синим пламенем. Юзер жалуется на багу – ну и что? Я человек маленький – пускай программисты думают – они умные. Приводит это к плачевным результатам. Недовольны все: юзеры – качеством сервиса, Петя – количеством юзеров, с которым ему уже не справится, начальство – имиджем проекта, о котором красноречиво написали обиженные пользователи на просторах интернета.

Все было бы наоборот, если нашему Петру объяснили при приеме на работу, что он не шлагбаум между сервисом и его пользователями, а Главный Юзер, который имеет непосредственное влияние на сервис. Разница – огромна. Саппорт – представитель всех пользователей внутри компании, защитник униженных и оскорбленных, заказчик доработок и исправления багов. Как правило, руководство компании об этом забывает, закрывая основной и самый важный канал фидбэка.

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

Но об этом далее.

Николай Кугаевский Support basics