Увидел на Хабре статью “Пять условий офигительного тех. саппорта”. Так как приходилось строить и руководить тех.поддержкой провайдера, решил ознакомиться.

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

Все таки решил почитать и самые худшие опасения подтвердились.

1. Быстрая реакция и ответы или “Ну когда же? Скажите конкретно, когда”

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

• инженеру не приходилось решать несколько проблем одновременно;
• это не нагружало инженеру дополнительной непродуктивной работы по обновлению статуса проблемы;
• текущий статус (кроме статуса “Готово”) хоть как-то отражал прогноз времени решения;
• клиенту не приходило в голову после “когда?” задавать вопрос “почему так долго?”.

В результате инженер вгоняется в стресс дурными вопросами тех.поддержки “когда?” и “почему?”. С большой вероятностью он в это время занят другой задачей и переключение контекста стоит ему времени (до 20 минут).

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

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

Клиент от процесса получает чистое удовольствие, асфальтируя мозг тех.поддержке (пока тех.поддержка не перестанет “отвечать на его ответы”, но это уже из области деформации психики).

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

2. Ясное объяснение или “Описать красный цвет слепому”

Процитирую:

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

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

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

Клиенту этого видеть не обязательно.

Если проблема на стороне провайдера, то ответа “Все исправлено, проверьте” вполне достаточно. Публично посыпать голову пеплом, рассказывая “мы неправильно настроили хостинг, ошиблись при планировании установки, залили пивом сервер, мой позор лишь смерть искупит”, совершенно ни к чему. Если проблема на стороне клиента, то достаточно указать на причину и предложить клиенту исправить её самому. Если его квалификации достаточно, проблема будет решена. Если нет, то придется или научить клиента делать правильно (потраченное время и стресс для тех.поддержки) или решить проблему силами провайдера и сообщить, что проблема решена. Объяснения клиенту ни к чему, он их в силу своей низкой квалификации не поймет.

3. Никогда не спорьте с клиентом или “Куда ты завел нас, проклятый старик?”

С клиентом спорить нельзя. Не потому что он прав, а совсем наоборот. Любое высказывание со стороны клиента должно считаться ложным, пока не будет подтверждено записями со стороны провайдера. Приятно общаться с клиентом, который говорит правду, но в большинстве случаев (опыт подсказывает, в 80%) клиент будет выдавать неверную информацию в силу своей низкой квалификации (95%) или намеренно, чтобы перевести беседу в выгодное себе русло (5%).

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

4. Давайте решение или “Нет ножек — нет варенья”

Некоторые проблемы являются не техническими, а организационными (как решать технические, рассказано в п.2), например, интересующий клиента функционал отсутствует в текущем тарифном пакете. Это следствие недоработки со стороны продавца, который для успешной продажи умолчал о важных для клиента характеристиках.

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

Если сотрудника тех.поддержки в такой ситуации бросить на амбразуру с неквалифицированным клиентом, ему придется переделывать работу продавца, то есть убеждать уменьшить потребности или увеличить затраты. За редкими исключениями, сотруднику тех.поддержки это будет не по силам (иначе он бы и так продавцом работал). В результате стресс как у одной, так и у другой стороны.

В таком случае клиента из тех.поддержки передают обратно продавцам, объяснив особенности, а те уже квалифицированно отвечают клиенту на вопросы “Почему я должен платить больше?”.

5. Клиент не дурак или “Рожденный ползать летать не может”

Действительно, нельзя делить клиентов на умный/дурак. Их нужно делить на квалифицированных и неквалифицированных. Не раз и не два клиенты провоцируют тех.поддержку на “Клиент — дурак!”, чтобы потом задавить авторитетом с высоты “Я — директор/начальник/главный админ/суперпрограммист, поэтому слушайте меня и делайте, что скажу”. Не думайте, что клиент умственно неполноценный, но и не забывайте п.3.

Резюме

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

Все это происходит от неправильного понимания роли тех.поддержки. Тех.поддержка не решает проблемы клиентов. Проблемы клиентов решает компания, предоставляя свои услуги. Тех.поддержка решает проблемы компании.