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