Автоматизация подбора персонала: ATS и воронка кандидатов

ATS это applicant tracking system, система отслеживания кандидатов. По смыслу это та же CRM, только главный объект в ней не клиент, а кандидат: отклик приходит из источника, попадает в общий список, проходит статусы и либо заканчивается выходом на работу, либо остаётся в базе до следующей подходящей вакансии. Всё остальное в ats системе подбора персонала надстроено над этой логикой: разбор резюме в карточку, шаблоны писем и сообщений, воронка по каждой вакансии, напоминания рекрутеру о просроченных этапах.

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

Кадровому агентству нужны обе логики сразу, и это важно понять до выбора инструмента. Заказчик с договором, перечнем вакансий, счетами и гарантийными обязательствами живёт по правилам CRM. Кандидат живёт по правилам ATS. Когда эти две сущности пытаются уложить в одну воронку, получается каша: статус «интервью» непонятно к кому относится, а отчёт по вакансиям не сходится с отчётом по кандидатам.

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

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

Типовой сквозной процесс агентства выглядит так:

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

Когда процесс описан, автоматизация воронки найма складывается из нескольких простых блоков. Первый: отклики из всех источников падают в один список. Второй: резюме разбирается в карточку кандидата, чтобы рекрутер не перепечатывал опыт и контакты вручную; это та же задача, что мы решаем в AI-обработке документов, только входящий файл не счёт, а резюме. Третий: статусы двигаются сами там, где это однозначно, например после назначенного интервью или после отказа заказчика.

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

Руками остаётся то, что требует суждения: формирование профиля вакансии вместе с заказчиком, интервью, оценка мотивации и адекватности, переговоры по офферу, разбор отказов. Ни одна ATS не закрывает вакансию за рекрутера, она убирает из его дня перепечатывание и поиск по переписке. Если после внедрения рекрутер делает столько же ручной работы, но в новом интерфейсе, проект сделан неправильно.

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

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

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

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

Ещё одно узкое место лежит в клиентской воронке, но бьёт по кандидатской: заказчик, который неделю не даёт обратную связь по представленным людям. Лечится это так же, как и всё остальное: срок на этап, напоминание ответственному, видимый статус «ждём решение заказчика» и отчёт, в котором эта задержка не прячется.

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

AI уверенно делает четыре вещи. Первая: приводит резюме к единой структуре, вытаскивает опыт, навыки, образование, график, город, ожидания по деньгам, даже если файл свёрстан как попало. Вторая: проверяет формальные требования, которые можно однозначно записать, например наличие нужной категории прав, конкретного сертификата, опыта работы в определённой системе, готовности к переезду или к сменному графику. Третья: ведёт первичную переписку в мессенджере, задаёт уточняющие вопросы и дожимает ответ, чтобы рекрутер получил карточку уже без пробелов. Четвёртая: ищет по накопленной базе, то есть отвечает на вопрос «кто у нас уже есть под такую вакансию» вместо ручного перебора.

AI не выносит решение о найме и не ставит оценку личности. Любая попытка попросить модель определить мотивацию, надёжность или перспективность по тексту резюме даёт отсев по случайным признакам: формулировкам, названию прошлого работодателя, длине описания опыта. Для кандидата это выглядит как немотивированный отказ, и претензии он предъявит вам, а не модели. Поэтому решение о приглашении на интервью и о найме остаётся за человеком, а AI обязан показывать, по какому именно критерию он поставил кандидата ниже. Подробнее о том, где машина забирает работу, а где нет, мы разбирали в статье «Заменит ли ИИ сотрудников: что автоматизируется».

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

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

Механика, которую нужно выстроить в системе, выглядит так:

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

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

Чинится это тремя решениями. Первое: вся переписка с кандидатами идёт через рабочий канал, подключённый к системе, а не через личный номер. Второе: права настроены по роли, и выгрузка базы целиком не является обычной операцией рядового рекрутера. Третье: при увольнении доступ закрывается одним действием, а кандидаты переназначаются на другого ответственного без потери истории общения.

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

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

Скорость. Время от заявки заказчика до первого представленного кандидата, время от отклика до первого контакта, срок закрытия вакансии целиком. Первые два показателя управляемы почти сразу, и именно они определяют, достанется вам кандидат или тому, кто ответил раньше.

Переходы по этапам кандидатской воронки: отклик в скрининг, скрининг в интервью у рекрутера, интервью в представление заказчику, представление в оффер, оффер в выход, выход в прохождение гарантийного периода. Смысл не в абсолютных значениях, а в том, какой переход провисает именно у вас. Провал на переходе «представление в оффер» означает проблему с профилем вакансии и ожиданиями заказчика, а не с рекрутерами.

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

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

Порядок работ, который мы считаем рабочим, такой. Сначала описываются две воронки и сроки по этапам, потому что без этого внедрение превращается в покупку интерфейса. Затем настраивается кандидатская воронка со статусами, автоматическими уведомлениями и напоминаниями, и подключаются источники откликов вместе с рабочими каналами переписки. После этого добавляется AI на первую линию: разбор резюме в карточку, проверка формальных требований, уточняющие вопросы кандидату. И только затем настраиваются отчёты заказчику и метрики руководителя, когда данные в системе уже достоверны.

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

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