IT-рекрутер: как защищать воронку найма цифрами
Начните с intake, который можно проверить
Воронка найма ломается задолго до первого сообщения кандидату. Если роль описана списком технологий, hiring manager и рекрутер могут искать разных людей, а последующие цифры лишь аккуратно измерят рассогласование. Проведите intake как рабочую сессию решения. Нужны бизнес-задача найма, результаты первых месяцев, обязательные компетенции, обучаемые навыки, команда, диапазон оплаты, формат работы, этапы и право финального выбора.
Попросите менеджера привести примеры сильного и неподходящего профиля. Формулировка «нужен senior» превращается в наблюдаемые критерии: проектировал сервис при неопределённой нагрузке, разбирал incident, принимал trade-off между consistency и latency. Для рекрутера важно понять, какие свидетельства видны в резюме, какие проверяются на скрининге, а какие остаются техническому интервью. Нельзя требовать от sourcing сигнала, доступного только после глубокого design exercise.
Разделите must-have и preference. Каждый must-have должен иметь цену отсутствия и метод проверки. Если менеджер не может объяснить, почему навык нельзя освоить за два месяца, перенесите его в preference. Отдельно согласуйте disqualifiers: право на работу, график, дежурства, язык, запрещённый конфликт интересов. Они должны быть законными, относящимися к работе и одинаково применяться.
Зафиксируйте SLA обеих сторон. Рекрутер отвечает за первую выборку и коммуникацию, manager — за feedback и доступность интервьюеров. Окно в два дня на разбор профилей имеет смысл только при назначенном резервном владельце. До старта проверьте scorecard на межэкспертное понимание. Дайте двум интервьюерам один обезличенный пример и попросите независимо отметить evidence. Если один считает сильной архитектуру, а другой ждёт только название технологии, bar ещё не операционализирован. Калибровка снижает шум поздних этапов и даёт рекрутеру язык для предварительного screen без имитации технического интервью. Зафиксируйте правила re-entry. Возврат кандидата через месяц после закрытой роли, перевод на соседнюю вакансию и повторный outreach не должны создавать три независимых человека. При этом прошлый rejection нельзя молча переносить на новый scope. ATS связывает profile, но создаёт новую application с собственным consent, stage history и актуальным решением. В вакансиях IT-рекрутеров можно сверить, где роль включает аналитику и employer brand, а где ограничена sourcing и координацией.
Постройте воронку на единой единице учёта
Сначала определите объект: человек, заявка на вакансию или прохождение процесса. Один кандидат может участвовать в двух ролях, вернуться через полгода и иметь несколько источников. Если ATS считает profile, а отчёт — applications, conversion будет расходиться. Задайте уникальный application id, timestamps событий, актуальный stage и reason code. Историю переходов храните отдельно от текущего состояния, иначе time-in-stage нельзя восстановить после возврата.
| Переход | Denominator | Что диагностирует | Частая ловушка |
|---|---|---|---|
| Outreach → reply | доставленные сообщения | релевантность и текст | считать bounced |
| Reply → screen | заинтересованные ответы | условия и квалификацию | смешать отказы |
| Screen → technical | завершённые screens | intake и оценку | считать no-show как fail |
| Technical → offer | завершённые интервью | bar и candidate pool | игнорировать pending |
| Offer → accept | вручённые офферы | ценность предложения | включать draft |
Считайте cohort, а не снимок. Вакансии, открытые на прошлой неделе, ещё не успели дойти до offer; сравнение их общей conversion с закрытыми ролями создаёт ложный провал. Группируйте по дате входа или закрытия перехода и указывайте maturity window. Для текущего управления используйте pipeline inventory, но не называйте его финальной конверсией.
Reason codes должны помогать действовать. «Не подходит» слишком широко. Разведите компенсацию, локацию, hard skill evidence, уровень scope, мотивацию, процесс, встречный оффер и no-show. Оставьте свободный комментарий для контекста, но анализируйте контролируемые категории. Регулярно проверяйте, не выбирают ли интервьюеры удобный code вместо истинного и не появляется ли дискриминационный паттерн.
Красивый процент без определения базы, cohort и незавершённых кандидатов нельзя защищать. Сначала восстановите знаменатель, потом обсуждайте рекрутера.
Найдите узкое место через conversion и time-in-stage
Низкая conversion и долгое ожидание отвечают на разные вопросы. Если screen → technical падает, проблема может быть в sourcing, intake или скрининге. Если conversion нормальна, но кандидаты по неделе ждут интервью, потеря находится в capacity и scheduling. Смотрите обе метрики вместе с абсолютным объёмом: стопроцентная conversion из двух профилей не закрывает план, а маленькое падение на тысячном потоке дорого.
Time-in-stage измеряйте от события до события, показывая median и верхний percentile. Среднее чувствительно к зависшим записям, а одна медиана скрывает длинный хвост. Разделите active waiting и время на стороне кандидата, если процесс допускает паузу. Не обнуляйте duration переводом кандидата назад; история должна сохранить каждый интервал. Отдельно считайте time-to-feedback после интервью — это управляемый сигнал дисциплины команды.
Разрезы выбирайте по гипотезе: роль, уровень, hiring manager, интервьюер, источник, регион, recruiter. Маленькие группы не публикуйте как рейтинг людей. Сначала ищите устойчивый паттерн и контекст. Один manager может нанимать самые сложные роли, поэтому raw time-to-fill несправедлив без job difficulty. Сравнивайте сопоставимые вакансии или используйте ожидаемый диапазон по классу.
Схема разделяет конверсию, очередь, причины отказов и постнаймовые сигналы качества.
Переведите цифры в решение о capacity
План найма разложите назад от start date. Примите реалистичные conversion, длительности этапов, acceptance и notice period. Так станет видно, сколько технических интервью, screens и sourced profiles требуется по неделям. Если доступная capacity интервьюеров ниже расчёта, рекрутер не может компенсировать разрыв ещё большим sourcing: очередь вырастет, candidate experience ухудшится, сильные люди уйдут.
Сделайте сценарии. Базовый использует историческую median, осторожный — нижнюю conversion и длинный notice, ускоренный — дополнительный interview slot или сокращённый этап после доказательства. Назовите условие переключения. Если reply rate падает ниже порога две недели, пересматривается канал и message; если очередь technical превышает capacity, ограничивается верх воронки либо добавляются интервьюеры. Это превращает отчёт в управление.
Канал оценивайте по результату и цене. Количество profiles из job board мало говорит о качестве; нужны qualified screens, offers, hires и recruiter hours. Agency может иметь высокую цену за hire, но быть оправданной для редкой роли и короткого окна. Referral способен давать сильную conversion, но проверьте diversity и одинаковость bar. Не присваивайте последний источник, если кандидат уже был в CRM: установите attribution rule.
Автоматизация должна уменьшать ожидание и ошибки, а не обезличивать процесс. Шаблоны сообщений персонализируются по реальному сигналу профиля, scheduling tool учитывает timezone, reminders не дублируются, rejection отправляется после зафиксированного решения. AI-assisted поиск или summary требует human review, проверки bias и запрета выдумывать опыт. Метрика экономии времени сопровождается качеством shortlist и candidate feedback.
Доведите воронку до качества найма
Закрытая вакансия не доказывает хороший найм. Определите ранние post-hire signals: прохождение испытательного срока, достижение согласованных outcomes, ramp time, оценка manager и самого сотрудника, retention на подходящем горизонте. Не сводите всё к одной субъективной оценке. Результат зависит от onboarding, руководителя и среды, поэтому quality of hire — общая метрика системы, а не персональный KPI рекрутера.
Свяжите post-hire с intake и этапами. Если люди стабильно не достигают конкретного outcome, проверьте, был ли он в scorecard и кто его оценивал. Если успешные сотрудники приходят из profiles, которые ранний фильтр часто отклоняет, bar может ловить не тот сигнал. Малой выборке нужна осторожность; используйте кейсы для гипотез, а не публичного рейтинга интервьюеров.
Candidate experience также влияет на систему. Измеряйте response time, ясность этапов, соблюдение обещаний и причины withdrawal. Короткий опрос после процесса полезнее общего NPS, если вопросы привязаны к действиям: понимал ли кандидат следующий шаг, получил ли возможность раскрыть опыт, пришёл ли feedback вовремя. Не просите rejected кандидата оценивать рекрутера до получения решения.
Для защиты воронки подготовьте одностраничный review: план и факт объёма, conversion по зрелым cohorts, time-in-stage p50/p90, главное узкое место, reason mix, capacity и следующее действие с владельцем. Добавьте ограничения данных и изменившийся контекст. Сравнить компенсацию функции можно на странице зарплат IT-рекрутеров. Сильный рекрутер использует цифры не для оправдания, а чтобы показать, где система теряет квалифицированных кандидатов и какое решение вернёт поток.