Воронка найма в Битрикс24 вместо таблицы с кандидатами

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

Почему таблица перестаёт справляться

Не из-за объёма. Таблица выдерживает сотню кандидатов, проблема не в этом.

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

Второе ограничение — отсутствие срока. В таблице нет разницы между кандидатом, с которым говорили вчера, и тем, кто ждёт ответа неделю. А именно ожидание убивает наём: человек, ищущий работу, за неделю находит другую.

Третье — потеря первого контакта. Пока переписка живёт в личном телефоне рекрутера, при его отпуске или уходе кандидаты исчезают вместе с историей разговора. Это то же самое, что происходит с клиентами, и лечится тем же способом — подключением канала к системе.

Как устроена воронка найма

В проекте сети быстрого питания она получилась из четырёх этапов: публикация вакансии, отклики кандидатов, собеседования, назначение на точку.

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

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

Последний этап заслуживает отдельного внимания. В рознице и общепите наём заканчивается не оффером, а выходом на конкретную точку, и разрыв между этими двумя событиями — самое частое место потерь. Доведя воронку до назначения, компания видит не «сколько наняли», а «сколько вышло».

Что изменилось после перевода в систему

Три измеренных результата. Обработка откликов стала вдвое быстрее. Время закрытия вакансии сократилось на 35%. Потерь кандидатов на первом контакте стало на 60% меньше.

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

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

Какие отчёты появляются

Три, и все три раньше собирались вручную.

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

Второй — срок закрытия по вакансиям и по точкам. Он показывает не среднее по компании, а конкретные места, где найм буксует: одна точка закрывает вакансию за неделю, соседняя за месяц.

Третий — причины отказов с обеих сторон. Кандидаты отказываются по своим причинам, компания по своим, и разделение этих двух потоков обычно вскрывает то, о чём в отчётах не пишут: например, что половина отказов приходится на условия, названные слишком поздно.

С чего начать

Опишите путь одного кандидата от отклика до первого рабочего дня и отметьте, где он переходит от человека к человеку. Эти переходы и станут этапами.

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

И только потом настраивайте отчёты. Раньше это делать бессмысленно: пока в воронке нет двух-трёх месяцев регулярной работы, цифры колеблются от единичных кандидатов и решения по ним принимать нельзя.

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

Как выглядят похожие проекты — в кейсах; как мы проектируем схему до настройки — на странице этапов внедрения.