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

Проблемы

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

• Плохо применяет предыдущий опыт: если несколько минут назад он обработал какой-то тикет, а потом через пару часов получил подобный же, параллель не проводится, решение не экстраполируется.

• «Не чувствует» реального клиента: при выполнении тестового задания было время подумать и переписать, в бою нет второго шанса, а время ограничено, как следствие — общается сухо, не отличает легкое недовольство от сильного раздражения, не считывает сигналы пользователя о том, в какую сторону вот-вот пойдет диалог.

• Теряется и путается в решениях: «я не знаю, что ему написать/сказать», «я не знаю, как это решить» и так далее. При стрессе теряет контроль и начинает буксовать вместо того, чтобы искать и перебирать варианты.

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

Возможные решения

Первый и последний пункты могут быть решены механически

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

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

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

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

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

Подсказка

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

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

Появились вопросы или есть тема, которую хотелось бы осветить в подобной статье? Не стесняйтесь и пишите на support@usedesk.ru — уникальная почта, письмам на которую рады всегда.