Идеальный поиск нового члена в команду поддержки выглядит так: он вам нравится, вы ему нравитесь, он начинает работать, работает прекрасно, все довольны. Реальный поиск чаще напоминает путешествие Данте: сделать тестовое задание и учесть в нем все нюансы (это невозможно, но вы будете стараться), из десятков выбрать самых достойных, провести с ними интервью и добить на нем проверкой «здесь и сейчас», взять на работу и обучить, понять, что в поле человек работает из рук вон плохо, огорчиться и искать дальше.
В большой команде с отлаженными HR-процессами все это сглаживается и не становится катастрофой, потому что это поток и все предусмотрено процедурами, а вот для небольшой команды, где набором зачастую занимается сам руководитель отдела поддержки (или принимает в наборе очень активное участие), это может стать кошмаром. Обучение нового сотрудника и инвестиции в него, потраченные впустую, — обидно, несправедливо и изматывающе. В какой-то момент я не выдержала и задалась вопросом, в чем же подвох и куда подложить соломы еще на этапе тестирования кандидата. Вот что из этого получилось.
Проблемы Тестовое задание выполняется хорошо (правильные ответы, корректный подход к клиенту, грамотность и так далее), но когда дело доходит до работы с реальными клиентами, сотрудник быстро глохнет:
- Плохо применяет предыдущий опыт: если несколько минут назад он обработал какой-то тикет, а потом через пару часов получил подобный же, параллель не проводится, решение не экстраполируется.
- «Не чувствует» реального клиента: при выполнении тестового задания было время подумать и переписать, в бою нет второго шанса, а время ограничено, как следствие — общается сухо, не отличает легкое недовольство от сильного раздражения, не считывает сигналы пользователя о том, в какую сторону вот-вот пойдет диалог.
- Теряется и путается в решениях: «я не знаю, что ему написать/сказать», «я не знаю, как это решить» и так далее. При стрессе теряет контроль и начинает буксовать вместо того, чтобы искать и перебирать варианты.
Эти нюансы при использовании одного только тестового задания невозможно проверить до того, как кандидат приступит к реальной работе.
Возможные решения Первый и последний пункты могут быть решены механически — просто опишите алгоритмы для самых популярных тикетов, избавив новичка от мук импровизации и мышления. С практикой придет уверенность и наберется опытный багаж.
Второй пункт можно либо простить, либо подождать, пока наберется опыт и выработается «чуйка».
Однако все эти решения требуют времени и терпения, а некоторые кандидаты не превращаются в прекрасных ловких умом лебедей даже по прошествии нескольких месяцев практики. Более того, когда мы даем сотруднику четкие указания и расписываем все алгоритмы — это хорошо и организованно, но как только общение с клиентом отходит от заданного шаблона, работа встает, а сотрудник — ломается, поэтому задача руководителя — еще на этапе собеседования понять, имеет ли кандидат подходящую под требования команды базу.
Я пообщалась с несколькими психологами и HR-специалистами, чтобы понять, в какую сторону можно попробовать двигаться, и предлагаю вам присоединиться к этим поискам и пробам.
Важно: все это теория и о личной практике применения я напишу позднее, когда наберется достаточно материала, а сейчас перед вами наметки и идеи о том, как можно протестировать слабые места кандидата до того, как вы радушно примете его в лоно поддержки.