Автоматизация найма в Make.com — это про то, чтобы путь от резюме до собеседования перестал быть хаотичной перепиской в мессенджерах и таблицах, особенно если вы работаете в России и живете в реальности 152-ФЗ. В этом тексте я покажу, как собрать прозрачный, управляемый и юридически аккуратный процесс: от того момента, когда кандидат отправил отклик, до записи его в календарь на интервью. Никакой магии, только понятная логика, Make.com, немного ИИ и здравый смысл. Материал рассчитан на тех, кто хочет, чтобы рутинные HR-операции делались сами: основатели небольших компаний, HR-специалисты, операционные менеджеры и те, кто уже трогал n8n или Make.com и хочет углубиться. Мы разберем, как не попасть под штрафы Роскомнадзора, как выстроить маршруты данных кандидатов, как подключить чат-бота, календарь, почту и таблицы. И да, я сразу заложу один живой пример — Антон-предприниматель решил перестать лично сортировать резюме из почты и Telegram-бота, чтобы вернуть себе хотя бы пару вечеров в неделю, и здесь будет его путь.
Я помню, как в какой-то момент HR-процессы начали напоминать свалку: Excel-таблица, доска в Trello, почта, Telegram, HeadHunter, Notion, и в каждом инструменте — по своему кусочку правды. В России это ничем хорошим не заканчивается, потому что в отличие от красивых зарубежных кейсов, у нас поверх всей этой красоты лежит 152-ФЗ, требования к хранению и локализации персональных данных, согласия кандидатов и периодическое «Здравствуйте, Роскомнадзор». Поэтому, когда речь заходит про автоматизацию найма, особенно через Make.com, я всегда стартую не с кнопочек, а с вопроса: а куда текут данные, где они лежат и кто к ним имеет доступ. Иногда это раздражает (сама бы тоже с радостью сразу к сценарию прыгнула), но именно тут закладывается, будет у вас стройная система или очередной комбайн из костылей.
История с Антоном началась очень по-русски: основатель небольшого IT-сервиса, пятьдесят человек, HR-функция наполовину на офис-менеджере, наполовину на самом Антоне. Резюме сыпались в бот, на почту, через форму на сайте, еще и какой-то менеджер по старой памяти просил писать «в личку». Антон честно пытался раз в день все это складывать в таблицу, но через неделю пропал один кандидат, через две — два сильных разработчика ушли к другим, потому что им просто не ответили вовремя. На третьей неделе он пришел ко мне с формулировкой: «Я готов на любую автоматизацию, только без странных серых схем и хранения данных бог знает где». Мы договорились: базовый сценарий в Make.com, данные — в локализованных хранилищах, согласия кандидатов — по-честному, а не «давайте пока сделаем, а потом как-нибудь узаконим».
Как понять, что автоматизация найма в Make.com вам вообще нужна
Часто меня спрашивают не «как автоматизировать найм», а «зачем, если и так живем». Ответ простой: автоматизация найма в Make.com нужна, когда ручной контроль над воронкой перестает работать, а ошибки по людям становятся дороже, чем настройка сценария. В российских реалиях это обычно выглядит так: отклики сыпятся с HeadHunter, сайта, Telegram и VK, ответ кандидату может уйти через три дня, и никто не понимает, где застревают сильные люди. При этом HR-специалист сидит вечерами, перекладывая данные по стадиям, но собственник все равно недоволен скоростью закрытия вакансий. Это означает, что пора перекладывать механику движения резюме и статуса кандидата на автоматизацию, а человеку оставлять оценку и общение.
Я заметила, что в найме повторяются одни и те же пять узких мест: сбор откликов, фильтрация по базовым критериям (опыт, город, зарплатные ожидания), коммуникация с кандидатом, постановка задач на интервью и фиксация результатов. Все остальное — вариации. На этих узлах Make.com чувствует себя как дома: он умеет забирать данные из форм, почты, ботов, класть их в таблицу или CRM, вызывать ИИ-модель для оценки ключевых слов, отправлять письмо или сообщение в мессенджер, создавать событие в календаре и напоминание в таск-менеджере. Чтобы не утонуть в возможностях, я обычно прошу клиента честно описать, как сейчас выглядит путь резюме до собеседования. Антон тогда прислал рисунок от руки: стрелочки от бота к нему в Telegram, от почты в Excel, от Excel в его голову (так и подписал), а уже потом — в Google Calendar. Я посмотрела и поняла, что любая система будет лучше, чем этот «арт-объект».
Чтобы не потеряться, полезно разложить будущую автоматизацию на несколько уровней зрелости. В первом уровне мы просто собираем отклики в одно место и фиксируем статусы. Во втором подключаем первичный скрининг и шаблонные ответы. В третьем — добавляем более умную маршрутизацию, интеграцию с календарями и напоминаниями. В четвертом — подключаем аналитику: сколько кандидатов, откуда, где все ломается. Не обязательно сразу лезть на четвертый уровень (хотя однажды я сама туда прыгнула сразу и потом полдня распутывала свои же связи), но понимать лестницу полезно. В России к этому добавляется слой с персональными данными: где лежат резюме, как оформлено согласие на обработку, есть ли политика конфиденциальности и учтена ли трансграничная передача, если вы тянете что-то через иностранные сервисы.
Вот как это можно увидеть структурно, чтобы голова держала картину, а не только «кнопочки в Make».
«Автоматизация найма — это не только про скорость закрытия вакансий, а про управляемость: вы точно знаете, где сейчас каждый кандидат, кто отвечает за следующий шаг и какие данные при этом используются».
В контексте 152-ФЗ автоматизация найма в Make.com должна проектироваться с оглядкой на то, что Make — иностранная платформа. Это не приговор, но это сразу означает, что мы не складываем туда массивы персональных данных из России бездумно. Я на практике выношу хранилище в российские сервисы: Postgres или MySQL на российском хостинге, отечественные облака, таблицы в Яндексе или локальный сервер клиента. Make.com в такой архитектуре работает как оркестратор: забрал минимум данных, протолкнул в нужное хранилище, дернул ИИ по тексту резюме, вернул метаданные. Получается гибрид: голова процесса в Make, тело — в русском сегменте. Антон к этому изначально относился скептически, хотел «чтобы все было в одном месте», но согласился, когда я показала ему выдержки из требований по локализации и типичные штрафы.
Как связать боль найма и конкретные процессы для автоматизации
Когда я первый раз сталкивалась с запросами на автоматизацию найма, звучало это так: «Марина, нам нужен бот, который будет сам отбирать кандидатов». Это красивая мечта (звучит приятно, но неправдоподобно), но для реального проекта нужно перевести эмоции в процессы. Я обычно прошу команду ответить на три простых вопроса: где мы теряем кандидатов, где тратим больше всего ручного времени и где чаще всего ошибаемся. У Антона ответы вышли вполне типичными: теряем на этапе «откликнулся, но ему не ответили», тратим время на переписку с базовыми уточнениями и ошибаемся при переносе слотов интервью. С этого момента разговор становится предметным: мы не «автоматизируем найм вообще», а наводим порядок в конкретных местах.
Дальше полезно пройтись по цепочке: откуда приходят резюме, куда они должны попадать, кто и как принимает решение о движении вперед, где фиксируются статусы. Вот как это выглядит на практике: кандидат заполнил форму на сайте компании, данные ушли в российскую базу (например, в таблицу или BD), Make.com получил три поля — ссылку на резюме, имя и контакт для связи, дернул ИИ для оценки базовых критериев, добавил тег «подходит/сомнительно/нет», записал в общую таблицу кандидатов и отправил HR уведомление в Telegram. Тот же сценарий можно завести на почтовый ящик «jobs@» или на отклики с HeadHunter через их API или экспорт. Ключевое — как можно раньше «слить» все каналы в единый реестр, а не держать четыре параллельные реальности.
В разговорах с российскими компаниями всплывает еще одна тема — кто вообще владелец процесса найма. Иногда это собственник, иногда HR, иногда руководитель направления. От этого зависит, у кого в руках будут рычаги в Make.com: кто сможет останавливать сценарий, менять фильтры, добавлять новые статусы. Я заметила, что самые устойчивые решения получаются, когда владелец процесса хотя бы раз сам открыл интерфейс Make и потыкал блоки. Не для того, чтобы все делать руками (на это есть специалисты), а чтобы понимать, как устроены маршруты данных и что именно происходит при нажатии виртуальной кнопки. В истории с Антоном так и получилось: первый обзорный созвон мы провели прямо в интерфейсе Make, и это сильно снизило его тревожность.
Чтобы чуть заземлить все сказанное, полезно сформулировать одну мысль явно.
Автоматизация найма через Make.com имеет смысл только тогда, когда вы четко описали текущий путь кандидата и понимаете, где нужна машина, а где — человек.
Что нужно собрать до первой интеграции Make.com и системы найма
На этапе подготовки многие спешат и открывают Make.com раньше, чем на столе появляется базовая карта процессов и набор артефактов. Я в какой-то момент поняла, что экономлю всем нервы, если настраиваю минимальный «чек перед стартом»: список точек входа кандидатов, шаблоны коммуникаций, структура карточки кандидата, требования по персональным данным. Без этого вы просто тратите время в интерфейсе Make, постоянно возвращаясь к HR с вопросами «а тут что писать», «а такой статус у вас вообще есть». В случае с Антоном мы потратили один спокойный вечер на сбор всех входящих каналов: сайт, Telegram-бот, почта, редкие отклики в VK и рекомендации, которые приходили через его личный аккаунт. Картина стала сильно проще, когда мы честно признали, что 80 % трафика делают сайт и бот.
Второй блок подготовки — договориться, какие данные о кандидате мы действительно храним и где. По 152-ФЗ персональные данные в России надо обрабатывать осознанно: понимать цели, сроки, доступы, хранение. Разработчику не нужен паспорт кандидата на первом касании, ему нужен стек технологий и опыт. HR не обязательно знать дату рождения на этапе отклика, достаточно контакта и города. Это звучит очевидно (хотя у меня есть отдельная коллекция форм, где спрашивают цвет глаз кандидата), но именно здесь мы режем избыточные поля и уменьшаем объем ПДн, гуляющих по интеграциям. Для Антона мы оставили в автоматическом потоке только профессиональные данные и контакты, а все «чувствительное» вынесли в отдельный, менее автоматизированный контур.
Отдельная история — шаблоны сообщений. Когда система начнет сама писать кандидатам, очень быстро выяснится, что у компании нет единого тона голоса и формулировок. Кто-то пишет «Добрый день», кто-то «Здравствуйте», кто-то отправляет голосовые (да, и такое я видела), а кто-то — просто одно «Подходит». Перед стартом автоматизации мы с Антоном сели и за час слепили понятный набор: сообщение после отклика, приглашение на тест, предложение слота на интервью, отказ. Make.com в этом месте становится просто рассыльщиком, а не сочинителем текстов. Хотя временами мы подключаем и ИИ, но строго для черновиков, а не для финальной отсылки, особенно когда речь про юрсмысл.
Когда эти артефакты собраны, интерфейс Make.com перестает пугать: вы не «играете в кубики», а просто выкладываете знакомые шаги в виде модулей. Я люблю момент, когда клиент вдруг видит, что его хаотичный процесс превращается в аккуратный поток: вход — обработка — решение — действие. В истории с Антоном это случилось, когда мы собрали схему на доске и выяснили, что половину ручных шагов можно смело отдавать автоматике. Он тогда отложил кружку с уже остывшим кофе и сказал: «Если это заработает, я впервые за месяц лягу спать в нормальное время».
Подготовка к автоматизации — это не бюрократия, а способ один раз договориться о правилах игры, чтобы потом не чинить последствия спешки.
Какие инструменты и сервисы связать с Make.com для найма в России
Если говорить прагматично, настройка Make.com для найма — это связывание нескольких привычных сервисов в один рабочий поток, с учетом того, что вы работаете в России и должны соблюдать 152-ФЗ. В минимальной конфигурации вам нужны: источник откликов (форма на сайте, HeadHunter, Telegram-бот), место хранения данных (таблица, CRM или база данных на сервере в РФ), средство коммуникации с кандидатом (почта, Telegram, VK), календарь для записи на собеседование и таск-менеджер или чат для внутренних уведомлений. Make.com между ними выступает диспетчером: он не обязан знать все детали кандидата, ему достаточно маркеров, чтобы правильно направлять поток. Это критично, потому что чем меньше персональных данных вы проводите через иностранный сервис, тем спокойнее спите.
Для российских компаний я часто строю архитектуру по принципу «тонкий Make — толстая база». Это означает, что в Make.com мы отдаем минимум: ID кандидата, ссылку на резюме (которое лежит на российском сервере), результаты скрининга, статусы. Сами резюме, фамилии, телефоны и email могут храниться в российском облаке или на сервере, доступ к которому контролируется внутри страны. При этом Make в режиме реального времени уведомляет HR в Telegram, обновляет статусы в таблицах и дергает вебхуки. В истории с Антоном мы использовали форму на сайте, Telegram-бот, таблицу в Яндекс 360 и корпоративную почту на российском домене, а Make оказался прослойкой, которая все это оживила. Ему оказалось достаточно видеть только часть данных, чтобы принимать решения и запускать автоматические действия.
На практике список типовых связок для автоматизации найма через Make.com у меня часто повторяется. Чтобы было проще ориентироваться, полезно посмотреть на это в виде структурированного перечня ролей сервисов.
- Источник откликов: сайт с формой, HeadHunter, Telegram-бот, сообщения в VK.
- Хранилище кандидатов: CRM, таблица (Google/Яндекс), база данных на сервере в РФ.
- Коммуникации: корпоративная почта, Telegram, VK, иногда SMS-шлюз.
- Организация интервью: Google Calendar, Яндекс.Календарь, корпоративные календари.
- Внутренние уведомления: Telegram-чаты, Slack- или VK-каналы для команды.
- Аналитика: BI-система или те же таблицы с дашбордом по конверсии.
Еще один слой — ИИ-сервисы для первичного скрининга резюме. Здесь уже приходится быть аккуратнее: передавать текст резюме внешнему ИИ без согласия кандидата впрямую нельзя, и это не просто придирка юристов. Я решаю задачу так: либо включаю в форму явное согласие на обработку данных с использованием ИИ-инструментов для оценки релевантности, либо анонимизирую резюме перед отправкой, убирая все, что может однозначно идентифицировать человека. Звучит немного заморочно (нет, подожди, это действительно заморочно), но в долгую это дешевле, чем испугаться при первой проверке Роскомнадзора.
Антон сначала хотел загнать все резюме в одну SaaS-CRM без привязки к РФ, но когда мы разобрали риски, согласился на гибрид: основная база в российском хранилище, Make.com как оркестратор, а внешние ИИ — только поверх обезличенных данных. В итоге это стало компромиссом между удобством и регуляторикой. При этом для команды HR ничего особо не изменилось: они видели удобную таблицу с фильтрами, тегами и статусами, а вся магия и ограничения происходили «под капотом».
Как выбрать, что именно автоматизировать воронке найма через Make.com
Когда у людей под рукой появляется Make.com, возникает соблазн автоматизировать вообще все: от чтения резюме до финального оффера. Я тут обычно слегка торможу процесс и предлагаю построить карту усилий и эффекта. Есть шаги, где автоматизация дает мгновенный выигрыш: сбор заявок из разных каналов в одну таблицу, автоответ после отклика, напоминания о предстоящих собеседованиях, обновление статусов. Есть шаги, где автоматизация спорна: глубокая оценка софт-скиллов, финальное решение по кандидату, переговоры по офферу. Я в таких случаях честно говорю: да, ИИ и Make могут помочь, но ответственность все равно останется на человеке, и не надо пытаться снять ее нажатием на кнопку «Auto». Это звучит менее романтично, чем «полностью автоматизированный найм», зато похоже на правду.
Я заметила закономерность: лучшие результаты получаются, когда на первом этапе мы берем 2-3 процесса из списка «болит больше всего», а не пытаемся сделать идеальную воронку. В истории с Антоном мы выбрали: сбор всех резюме в единый реестр, автоответ кандидатам и напоминания о собеседованиях. Все остальное оставили в полуавтоматическом режиме, чтобы команда не утонула в новинках. Через пару недель, когда все втянулись, стало понятнее, куда двигаться дальше. В этот момент Make.com воспринимается не как «еще одна страшная система», а как помощник, который уже доказал свою полезность.
Приоритезация шагов автоматизации в найме хорошо стыкуется с российской спецификой: любые доработки, влияющие на обработку ПДн, приходится согласовывать с юристами или службой ИБ. Если вы будете каждые три дня приносить в отдел ИБ новую схему маршрутизации, вас там быстро разлюбят. Гораздо разумнее принести один понятный дизайн-процесс, описать, какие данные где ходят, и потом уже итеративно донастраивать только логику внутри утвержденного контура. Я в таких случаях иногда выступаю переводчиком между HR и ИБ: объясняю, зачем HR нужен тот или иной шаг, и показываю ИБ, что риски контролируются и ничего страшного не происходит.
В итоге получается интересный эффект: автоматизация перестает быть «игрушкой HR» и превращается в общий проект компании. Собственник видит экономию времени и снижение хаоса, HR — освобождение от рутины, ИБ — понятные границы обработки ПДн. Антон так и сказал на одном из созвонов: «Я наконец понял, что автоматизация найма — это не про роботов, а про то, чтобы люди делали свою работу вовремя и не теряли кандидатов по глупости». Возвращаясь к нашему остывшему кофе из начала — если вы дошли до такого понимания, можно наконец допить кофе теплым, а не ледяным.
«Наиболее эффективная автоматизация в найме — та, которая щадит время HR и собственника, но не ломает человеческий контакт с кандидатом».
Как учитывать 152-ФЗ и ИИ в автоматизации найма через Make.com
Тема нейросетей и ИИ в найме сейчас в России звучит громко, но с точки зрения закона там много нюансов. По 152-ФЗ вы не можете просто взять любое резюме и бездумно отправить его в зарубежный ИИ-сервис для «оценки релевантности», если в согласии кандидата нет ничего про такую обработку. Формально это и трансграничная передача, и автоматизированная обработка, и потенциально принятие решений, имеющих юридические последствия. В реальности это редко дойдет до суда (хотя я бы на это не рассчитывала), но точно дойдет до головной боли, если кто-то пожалуется. Поэтому, если вы хотите встроить ИИ в цепочку через Make.com, продумайте два момента: как вы объясните кандидату, что его данные может оценивать ИИ, и как вы ограничите набор передаваемых сведений.
На практике я использую два подхода к ИИ в найме. Первый — аналитический: мы передаем в ИИ только текст компетенций и опыта, убирая ФИО, контакты и специфические идентификаторы, а на выходе получаем обезличенный скоринг или резюме навыков. Такой подход меньше бьет по ПДн и уменьшает риски, хотя полностью их не снимает. Второй — черновой: ИИ формирует черновики писем, сообщений и коротких описаний кандидата для внутреннего пользования, а человек все равно смотрит и правит. Здесь ИИ выступает помощником редактора, а не «властелином судеб кандидатов». Когда я говорю об этом командам, кто-то разочарованно вздыхает (хотели волшебную кнопку), но потом понимает, что даже такой аккуратный ИИ сильно экономит время.
С точки зрения Make.com настройка ИИ-интеграций мало чем отличается от любых других API-вызовов: вы отправляете текст, получаете ответ, используете его как одно из полей в сценарии. Но на уровне организации процесса в России нужно заложить еще пару шагов: проверить, где физически расположены сервера ИИ-провайдера, прописать это в документах по обработке ПДн, при необходимости обновить политику конфиденциальности на сайте. Звучит скучно (забудь, что я только что сказала — это правда скучно, но нужно), но один раз такой подход экономит массу нервов при проверках и при росте компании.
В кейсе Антона мы начали с самого мягкого — использовали ИИ только для того, чтобы по тексту резюме вытаскивать основные технологии и стек, а далее уже человек принимал решение, звать ли на интервью. В согласии на обработку ПДн на сайте мы добавили формулировку про использование автоматизированных инструментов для оценки соответствия кандидата требованиям вакансии. Параллельно внесли изменения в политику обработки ПДн, упомянув, что речь идет о текстовом анализе без принятия окончательного решения без участия человека. Да, это звучит немного официально, но в этой части по-другому нельзя, иначе все предыдущие аккуратные шаги по автоматизации нивелируются одной жалобой от обиженного кандидата.
Использование ИИ в автоматизации найма через Make.com безопасно только тогда, когда вы честно описали его роль кандидатам и ограничили объем передаваемых персональных данных.
Как пошагово собрать цепочку от резюме до собеседования в Make.com
Пора перейти от концепций к конкретике: как выглядит базовый сценарий автоматизации найма в Make.com, если вы работаете в России и хотите довести кандидата от отклика до собеседования без километра ручной рутины. Я обычно строю цепочку в четыре крупных блока: прием отклика, первичная обработка, коммуникация с кандидатом и организация интервью. Внутри каждого блока есть несколько модулей, но на высоком уровне картина всегда такая. Важно держать в голове, что Make.com — это про маршруты: вы настраиваете, что делать с данными на каждом шаге, а не просто «запускаете бота». В истории с Антоном мы начали с формы на сайте и Telegram-бота, но структуру сценария делали такую, чтобы потом можно было подключить HeadHunter и другие источники.
Стартовая точка — триггер. Это может быть вебхук от формы сайта, новое письмо на почте или сообщение в боте. Как только срабатывает триггер, Make.com забирает данные и проверяет минимальные условия: есть ли у нас согласие на обработку ПДн, заполнены ли ключевые поля, нет ли дубликата кандидата в базе. Если с этим все в порядке, данные отправляются в российское хранилище — таблицу или BD. На этом шаге вы уже соблюдаете базовые требования 152-ФЗ: данные сразу приземляются в российской юрисдикции, а Make выступает транспортом, а не местом долговременного хранения. Дальше по желанию подключаете ИИ для анализа текста резюме: он оценивает, насколько опыт совпадает с требованиями, вытаскивает ключевые навыки, формирует короткий тег или скор.
После первичной обработки сценарий переходит к коммуникации. Если кандидат прошел базовый фильтр, Make.com формирует и отправляет письмо или сообщение в мессенджер: «Спасибо за отклик, вот короткий тест/вопросы/предложение выбрать удобное время для интервью». Если нет — отправляет аккуратный отказ. Все шаблоны вы настраиваете заранее, а Make подставляет в них нужные данные. В кейсе Антона мы сделали так: кандидат после формы на сайте получал письмо с благодарностью и ссылкой на мини-опрос, а после его заполнения система либо предлагала слоты на интервью, либо вежливо отказывала. HR в это время не писал одно и то же вручную двадцать раз в день, а занимался содержательными задачами.
Как на практике выглядит базовый сценарий Make.com для найма
Вот как это выглядит на практике, если разложить цепочку на конкретные шаги в Make.com, без углубления в каждую настройку. Триггер — вебхук от формы на сайте или сигнал от Telegram-бота. Первый модуль — валидация данных: проверяем, что заполнены имя, контакт и ссылка на резюме. Второй модуль — запись в хранилище кандидатов в РФ: создается или обновляется запись в таблице с полями по вакансии, статусу, источнику. Третий модуль — при необходимости отправка текста резюме или описания опыта в ИИ-сервис для оценки соответствия базовым критериям. Четвертый модуль — логика маршрутизации: если результат оценки выше порогового значения, присваиваем статус «подходит», если ниже — «сомнительно» или «нет».
Следующий шаг — коммуникация. Пятый модуль — выбор нужного шаблона письма или сообщения в мессенджер на основе статуса. Шестой — отправка сообщения через SMTP, Telegram API или другой канал. Седьмой — запись результата коммуникации в хранилище, чтобы потом можно было посмотреть историю. Дальше включается блок интервью: если кандидат подтвердил готовность общаться, Make.com либо создает приглашение в календаре с указанием слота, либо отправляет ссылку на выбор времени (например, через форму или календарь бронирования). После того как слот выбран, сценарий добавляет событие в календарь интервьюера и отправляет напоминания участникам за сутки и за час до встречи.
В истории Антона мы в первый релиз заложили только часть этой цепочки: прием откликов, запись в хранилище, автоответ и напоминания. Организацию слотов для интервью добавили позже, когда команда привыкла к базовому сценарию. Антон сначала переживал, что Make.com «занукается» от такого количества ветвлений, но быстро увидел, что сценарий читается достаточно просто: одно большое дерево решений с понятными развилками. Я сама, когда возвращаюсь к таким схемам через месяц, спокойно ориентируюсь, потому что каждый блок подписан по-человечески, а не «Модуль 1», «Модуль 2».
Чтобы не превращать это в сухую схему, полезно выделить одно наблюдение отдельно.
Сценарий Make.com для найма удобно строить по логике: триггер — проверка — запись — решение — действие, а не пытаться охватить все возможные варианты поведения кандидатов сразу.
Как учесть нестандартные ситуации кандидатов в сценариях Make.com
Реальный найм никогда не бывает идеально прямолинейным: кто-то опоздал с ответом, кто-то пришел не по той вакансии, кто-то написал длинное письмо вместо заполнения формы. Если пытаться сразу учесть в Make.com все варианты поведения кандидатов, сценарий раздуется до неконтролируемого монстра. Я в таких случаях делю ситуации на два класса: типовые, которые возникают регулярно и влияяют на конверсию, и редкие, которые проще решить вручную. Например, просьба кандидата перенести интервью — это типовая история, ее имеет смысл обрабатывать автоматически: кнопка или ссылка «перенести», сценарий снимает старый слот и предлагает новые. А вот письмо в стиле «я ваш поклонник, возьмите меня стажером» попадает уже в зону осознанного ручного ответа.
На практике сценарий Make.com развивается итеративно. В первый месяц вы видите, какие кейсы повторяются чаще всего, и добавляете под них ветки: обработку просроченных откликов, напоминания кандидатам, которые перестали отвечать, автоматическое закрытие «висящих» заявок. При этом я стараюсь не давать системе принимать окончательные решения без участия HR в неоднозначных случаях. Например, если ИИ оценивает резюме как «сомнительное», я предпочитаю отправить HR уведомление в Telegram с просьбой посмотреть и кликнуть «звать/нет», а не рубить кандидата сразу. Да, это немного увеличивает ручной труд, но снижает риск упустить сильного человека из-за того, что алгоритм не заметил нужный паттерн в тексте.
В кейсе Антона за первые две недели всплыли три нестандартных сюжета: кандидаты, которые писали напрямую ему в личный Telegram, люди, которые отправляли резюме без указания города, и отклики от старых знакомых. Для каждого мы добавили аккуратные обходные пути: отдельный вебхук для пересылки сообщений из личных чатов в общий контур, дополнительный шаг запроса города, ручной тег «знакомый» с особой логикой. Получился небольшой зоопарк, но контролируемый. В какой-то момент Антон шутил, что Make.com знает о его знакомых чуть больше, чем он сам 🙂
Это подводит к простой мысли, которая сильно помогает не утонуть в сложности.
«Лучший способ справиться с нестандартными кейсами в автоматизации найма — признавать их существование, но не пытаться автоматизировать все сразу, а добавлять обработку только для тех, что действительно повторяются».
Где именно подключать человека в автоматизированной цепочке найма
Иногда команды настолько увлекаются автоматизацией, что забывают: финальные решения в найме по-хорошему должен принимать человек. Я для себя выделяю несколько точек, где участие человека не просто желательно, а критично. Во-первых, оценка неочевидных резюме, когда кандидат формально не подходит по чек-листу, но у него есть сильный потенциал. Во-вторых, сложные переговоры по условиям: зарплата, график, формат сотрудничества. В-третьих, любые конфликтные ситуации: жалобы, непонимание, недовольство процессом. Make.com может помочь собрать фактуру, показать историю коммуникаций, напомнить о сроках, но не должен быть тем, кто «поссорился с кандидатом».
Поэтому в сценариях я всегда оставляю окна для ручного решения. Например, кандидат попадает в статус «на рассмотрении», HR получает уведомление и прямо в карточке в таблице или CRM может выбрать действие: «пригласить на интервью», «запросить дополнительные данные», «отказать». Make тут только подхватывает выбранный вариант и запускает соответствующую ветку сценария. Такой подход особенно уместен для российских компаний, где формальное «решение алгоритма» по кандидату может быть воспринято болезненно, если об этом узнать. Лучше, когда HR честно берет на себя ответственность: да, мы приняли решение, исходя из этих факторов, а система нам помогла не забыть про срок ответа.
Возвращаясь к Антону, на третьей неделе работы сценария он признался, что сначала хотел «полностью автоматизировать все до оффера», а потом понял, что это было бы и неправильно, и опасно для репутации компании. В итоге у нас получилась гибридная модель: Make.com делает тяжелую рутину, ИИ помогает разбирать длинные резюме, а люди принимают решения и общаются с кандидатами. Это звучит чуть менее футуристично, чем «роботы нанимают людей», но сильно ближе к устойчивой реальности.
Автоматизация найма через Make.com не отменяет человека в критических точках, а освобождает его от всего остального, что мешает думать, а не только кликать.
Какие результаты дает автоматизация найма и где спрятаны подводные камни
Через пару недель после запуска автоматизации найма в Make.com обычно становится понятно, окупается ли история. В кейсе Антона картина сложилась довольно понятная: среднее время от отклика до первого ответа сократилось с двух дней до пары часов, количество потерянных кандидатов почти обнулилось, а HR перестала сидеть вечерами за перепиской. Формально экономия составила около 15-20 часов в неделю на рутине, которые команда перераспределила на собеседования, оценку и работу с брендом работодателя. Для небольшого бизнеса это очень ощутимая цифра. При этом прозрачность процесса выросла: в любой момент можно было открыть таблицу и увидеть, на каком этапе каждый кандидат и кто за него отвечает.
С точки зрения метрик автоматизации найма в России я обычно смотрю на несколько элементов: скорость реакции на отклик, конверсию от отклика до интервью, долю кандидатов, ушедших в никуда (без ответа), нагрузку на HR-специалиста в часах, и базовую «экологичность» по 152-ФЗ — нет ли утечек, странных маршрутов данных, неучтенных хранилищ. В проектах с Make.com хорошо видно, как после внедрения сценариев проседают «черные дыры»: позиции, где раньше кандидаты терялись. Иногда эффекты не такие впечатляющие, как в красивых презентациях, но даже сокращение ручной работы на 30-40 % уже меняет жизнь команды. При этом важно честно признавать: автоматизация не решит проблем с неконкурентными зарплатами, неубедительными вакансиями или плохим менеджментом, она только делает процесс чище.
Теперь о камнях. Во-первых, переавтоматизация: желание втащить в Make.com каждый чих и веточку. Во-вторых, игнорирование ИБ и юристов: настроили все красиво, а потом внезапно поняли, что половина данных гуляет по зарубежным сервисам без формализованного согласия. В-третьих, отсутствие владельца процесса: сценарий один раз настроили, потом никто не следит за его актуальностью, и через полгода половина статусов не используется, а шаблоны писем не отражают реальную практику. Я поэтому с самого начала прошу клиента назначить человека, который отвечает не только за сам найм, но и за его автоматизированный контур. Это может быть HR, операционный менеджер или кто-то с техническим уклоном, но такой человек должен быть.
Каких ошибок в автоматизации найма на Make.com я вижу больше всего
Если честно посмотреть на проекты автоматизации найма в Make.com, повторяющиеся ошибки достаточно типичны. Первая — отсутствие нормальной карты процесса до старта. Люди бегут сразу в сценарии, а потом обнаруживают, что половину шагов вообще можно было выбросить. Вторая — игнорирование людей, которые будут этим пользоваться каждый день. HR узнает о том, что у него теперь автоматизированный найм, в тот момент, когда в Telegram начинают сыпаться странные уведомления. Третья — чрезмерное доверие к ИИ и автоматическим фильтрам, когда хороший кандидат выбрасывается на основании пары кривых правил. Я однажды видела сценарий, где все резюме без слова «senior» автоматически помечались как «неподходящие» (звучит странно, но это реально случилось).
Четвертая проблема — недооценка русско-правового контекста. В западных кейсах очень любят показывать, как все резюме летают через внешние SaaS, BI и ИИ-инструменты, а у нас это спокойно может уткнуться в 152-ФЗ и жёсткий отдел ИБ. Если вы строите автоматизацию найма в России, особенно на Make.com, который сам по себе расположен за пределами РФ, то архитектуру нужно рисовать с учетом локализации данных. Пятая — отсутствие мониторинга. Сценарий один раз сделали, он вроде работает, а потом API какого-то сервиса меняется, и часть потока тихо падает. Через месяц выясняется, что двадцать кандидатов просто не получили ответа, потому что один модуль в Make начал выбрасывать ошибку.
На практике спасает очень простая дисциплина: регулярный короткий аудит сценариев, логирование ключевых шагов и понятные алерты при сбоях. В кейсе Антона мы настроили отдельный канал в Telegram, куда Make.com отправлял сообщения, если что-то шло не так: не удалось записать в хранилище, не отправилось письмо, сломался API бота. Это позволило не жить в иллюзии, что «автоматизация работает идеально», а видеть, где нужно вмешательство. Заодно команда привыкла, что автоматизация — не черный ящик, а прозрачный механизм, в котором можно разобрать и починить любую часть.
Чтобы чуть заострить мысль для тех, кто любит сразу стартовать с максимальной сложности, выделю одно наблюдение.
Большинство проблем автоматизации найма на Make.com возникают не из-за сложности инструмента, а из-за отсутствия внятного процесса, владельца и минимального мониторинга.
Как измерять эффект от автоматизации найма в российских реалиях
Я заметила, что компании часто либо вообще не считают эффект от автоматизации, либо считают его по очень условным метрикам. Для найма через Make.com в России имеет смысл смотреть не только на скорость закрытия вакансий, но и на управляемость и соответствие требованиям по ПДн. Базовый набор метрик может выглядеть так: среднее время до первого ответа кандидату, доля кандидатов, не получивших ответа, время HR на обработку одного отклика, количество ручных шагов в процессе, число инцидентов, связанных с обработкой ПДн. Плюс можно добавлять NPS по кандидату: сколько людей готовы рекомендовать ваш найм другим, но это уже более продвинутый уровень.
Кейс Антона к концу второго месяца дал довольно прозрачную картинку. Время до первого ответа сократилось примерно в четыре раза, доля «потерянных» кандидатов упала почти до нуля, HR освободила по ощущениям один полный рабочий день в неделю. Кроме того, стало проще отвечать на вопросы ИБ и юристов: все потоки данных были задокументированы, согласия обновлены, архитектура понятна. Это как раз тот случай, когда автоматизация через Make.com не только экономит время и деньги, но и снижает регуляторные риски. Такой эффект сложно показать в одной красивой цифре, но это то, что дает спокойно спать собственнику и ИБ-специалисту.
На этом фоне особенно заметно, как меняется отношение к ИИ и внешним инструментам. В начале Антон относился к ним как к чему-то «магическому», а к концу проекта говорил о них как об обычных модулях в цепочке: есть триггер, есть ИИ-оценка, есть человеческое решение. Автоматизация найма стала для него не про «чудо», а про понятный, управляемый рабочий процесс. И мне этот сдвиг всегда кажется самым ценным.
«Хорошо настроенная автоматизация найма в Make.com не производит эффекта фокуса — она просто тихо экономит время и снижает хаос, позволяя людям делать свою работу лучше».
Что учесть перед масштабированием и как не утонуть в продвинутых настройках
Когда базовый сценарий заработал, обычно возникает логичный вопрос: а что дальше, куда это все масштабировать. Здесь начинается вторая серия истории Антона. Через месяц после запуска он вернулся с новой задачей: нанимать нужно уже не только разработчиков, но и маркетинг, поддержку и операционный блок, при этом у каждой функции своя логика отбора. Возник соблазн сделать один универсальный мегасценарий Make.com на все случаи жизни, но мы в итоге разошлись по более спокойному пути: разбили контур на несколько модулей по типам вакансий и вынесли общие вещи в отдельные сценарии. Это требует чуть больше дисциплины, но зато лучше управляется и проще поддерживается.
При масштабировании автоматизации найма я смотрю на три направления. Первое — расширение по вакансиям: разные воронки, разные критерии, разные интервьюеры. Второе — углубление аналитики: отслеживание конверсий по источникам, по типам кандидатов, по стадиям. Третье — повышение устойчивости: резервные сценарии на случай падения одного из сервисов, более тонкая работа с ошибками, логирование. Здесь Make.com позволяет спокойно наращивать сложность, но я всегда предупреждаю: не надо гнаться за максимально красивой архитектурой, если у вас команда из одного HR и одного технаря на полставки. Лучше иметь три простых сценария, которые все понимают, чем один гениальный, который боятся трогать.
Помнишь про кофе из начала? На этом этапе Антон уже наливал себе чай и иногда даже успевал выпить его горячим. Команда привыкла к тому, что часть рутины исчезла, и начала генерировать более тонкие запросы: можно ли делать автотеги по источникам, вести историю версий резюме, автоматически напоминать руководителям, если они задерживают обратную связь. Вот здесь Make.com раскрывается особенно приятно: вы не строите все с нуля, а добавляете новые ветки и модули в уже знакомую структуру. Главное — не забывать время от времени останавливать этот рост и делать ревизию: что реально дает ценность, а что родилось только потому, что «так можно было».
Отдельного упоминания заслуживает вопрос обучения команды. На старте обычно автоматизацией занимается один человек, а потом сценарий начинает жить своей жизнью, и любая мелкая правка превращается в квест «найти того, кто это настраивал». Я в таких ситуациях настаиваю на базовом онбординге для ключевых людей: как открыть сценарий в Make.com, где смотреть логи, как перезапустить модуль, как временно отключить ветку. Не нужно делать из HR-разработчиков, но понимание общей логики сильно снижает страх. Плюс можно всегда иметь под рукой структурированные материалы — у меня часть таких вещей лежит на сайте promaren.ru, и люди периодически пишут: «Мы прочитали, попробовали и, кажется, начали понимать, что у нас вообще происходит».
Как финализировался кейс Антона и какие цифры получилось зафиксировать
Автоматизация найма у Антона закончилась не в тот момент, когда мы нажали кнопку «Активировать сценарий», а спустя пару месяцев, когда процесс устаканился и перестал шататься при каждом порыве ветра. Мы провели небольшой аудит: посмотрели конверсию по воронке, нагрузку на людей, стабильность интеграций, соответствие ПДн-контуров описанным правилам. В сухом остатке вышло так: экономия времени HR и самого Антона — около 20 часов в неделю, сокращение средней длительности закрытия вакансии — на 25-30 % по сравнению с прошлым кварталом, снижение доли кандидатов, не получивших никакого ответа, с примерно 15 % до единичных случаев, когда ломался внешний сервис. Плюс более тонкий, но важный показатель — отсутствие инцидентов по ПДн при росте потока резюме.
По ощущениям команды, работа стала менее дерганой. HR перестала жить в почте и мессенджерах, Антон перестал быть единственной точкой, где все скапливалось, руководители получили более прозрачную картину по своим вакансиям. Я отдельно радовалась тому, что в диалогах перестали звучать фразы «у нас все сломалось» и «мы ничего не понимаем, что делает этот ваш Make». Вместо этого появились вопросы типа «а можно еще добавить такую ветку» или «как нам посчитать время на каждом этапе». Это хороший индикатор: автоматизация перестает быть черной коробкой и становится нормальным инструментом, как таблицы или почта.
Для меня этот кейс стал очередным подтверждением: если не гнаться за магией, не пытаться переложить на ИИ всю ответственность и работать в белой зоне по 152-ФЗ, автоматизация найма через Make.com превращается из страшной истории в спокойную рабочую практику. Да, иногда сценарий падает, иногда боты ведут себя странно, иногда API внешних сервисов меняются без предупреждения… но при грамотной архитектуре это не катастрофа, а просто задачка на вечер. И да, к этому моменту чай или кофе уже редко успевают остыть до состояния льда.
Масштабирование автоматизации найма — это не гонка за сложностью, а аккуратное увязывание новых потребностей с уже работающим и понятным контуром.
Куда двигаться дальше, если базовая автоматизация уже работает
Если вы дочитали до этого места, скорее всего, базовый каркас картины уже в голове: автоматизация найма через Make.com, российские реалии, 152-ФЗ, ИИ как помощник, а не хозяин. Логичный вопрос — что можно сделать дальше, чтобы система не превратилась в музей достижений прошлого квартала. Я бы предложила несколько направлений. Первое — развивать аналитику: смотреть не только на конверсию, но и на качество закрытия вакансий, источники лучших кандидатов, время на этапах. Второе — автоматизировать смежные процессы: онбординг новых сотрудников, сбор обратной связи после испытательного срока, перенастройку доступов и прав в системах. Третье — интегрировать найм с более общей архитектурой автоматизации компании: чтобы Make.com, n8n, внутренние сервисы и ИИ-агенты не жили каждый в своей вселенной.
Возвращаясь к тому, с чего я начала, автоматизация найма — это не разовый проект, а часть культуры обращения с процессами и данными. Если в компании принято решать задачи по принципу «давайте быстрее что-нибудь скрутим», то сценарии в Make.com быстро превратятся в тот же хаос, только в новом интерфейсе. Если же есть привычка описывать процессы, думать про риски ПДн, считать эффект и не бояться экспериментировать, автоматизация начинает действительно работать на людей. Антон, к примеру, после найма пошел в автоматизацию обработки входящих заявок клиентов и внутренней поддержки, используя уже наработанные принципы. Часть этих историй я время от времени разбираю в Telegram-канале MAREN, как раз для тех, кто хочет изнутри посмотреть, как это устроено без глянца.
Получается интересный замкнутый круг — но в хорошем смысле. Чем больше вы осмысленно автоматизируете, тем меньше боитесь сложных инструментов и регуляторики, тем аккуратнее проектируете процессы дальше. В какой-то момент появляется ощущение, что контент, найм, операционка действительно начинают «делаться сами», а люди возвращают себе время для тех задач, где их голова незаменима. И мне как человеку с бэкграундом во внутреннем аудите и ИТ-рисках особенно нравится, когда это делается в белой зоне, без серых схем и «авось пронесет».
Если в этом тексте хочется взять с собой одну мысль, то она будет такой: автоматизация найма через Make.com в России — это не про то, чтобы отдать людей на откуп алгоритмам, а про то, чтобы построить честный, прозрачный и предсказуемый процесс, где машины делают скучное, а люди — осмысленное.
А дальше решение за вами: или продолжать вручную перетаскивать резюме по чатам, или один раз сесть, описать процесс и позволить технологиям тихо сделать свою работу.
Для тех, кто чувствует, что теории уже достаточно и хочется практики, самый продуктивный следующий шаг — открыть свои текущие процессы и честно посмотреть, какие из них можно отдать на автоматизацию, а какие требуют человеческого внимания. Можно пройтись по цепочке найма с этим текстом рядом, можно заглянуть на promaren.ru за структурами и примерами, можно прийти в мой Telegram-канал MAREN, где я периодически разбираю реальные кейсы и показываю кусочки сценариев в живом режиме. Главное — не застревать на этапе «интересная тема, надо как-нибудь заняться», а сделать один конкретный шаг: описать путь кандидата, собрать артефакты, придумать первую простую автоматизацию.
Если хочешь структурировать знания по Make.com, n8n и ИИ-агентам под свои задачи, хорошей практикой будет выбрать один процесс — например, автоматизацию первичного отклика кандидату — и довести его до рабочего состояния. Это лучше любого курса по теории: один живой сценарий с понятной пользой для команды. А дальше можно наращивать сложность, добавлять аналитику, подключать ИИ-модули и строить более широкие цепочки. Вся эта история про то, чтобы вернуть себе время и перестать жить в ощущении вечного завала. И да, заодно сделать так, чтобы кандидаты не зависали в тишине неделями, а получали честную и быструю обратную связь.
Что еще важно знать про автоматизацию найма в Make.com
Вопрос: Как начать автоматизацию найма в Make.com, если в команде нет разработчиков?
Ответ: Начать можно с очень простого сценария: взять один источник откликов, одну таблицу и автоответ кандидату. В интерфейсе Make.com большинство модулей настраивается через формы, без кода, поэтому HR или операционный менеджер при небольшом погружении смогут собрать базовый поток. Если станет сложно, можно подключить внешнего специалиста на разовый аудит и донастройку.
Вопрос: Можно ли в России использовать Make.com для хранения резюме и персональных данных кандидатов?
Ответ: Я бы не рекомендовала использовать Make.com как основное хранилище ПДн кандидатов в РФ. Безопаснее держать резюме и контакты в российском хранилище, а Make.com использовать как оркестратор, который минимально касается персональных данных. Такой подход лучше стыкуется с требованиями локализации и снижает регуляторные риски.
Вопрос: Что делать, если API одного из сервисов сломался и сценарий найма в Make.com перестал работать?
Ответ: Важно предусмотреть мониторинг и оповещения: Make.com позволяет отправлять сообщения при ошибках в отдельный канал или чат. Если API меняется, стоит временно отключить зависимую ветку, вернуть на время часть шагов в ручной режим и либо обновить настройки, либо заменить сервис. Полезно периодически проверять логи и состояние модулей, чтобы не узнавать о сбое через месяц.
Вопрос: Как сочетать автоматизацию найма в Make.com и требования 152-ФЗ по согласию на обработку ПДн?
Ответ: Нужно явно прописать в формах и политиках, что данные кандидатов могут обрабатываться автоматизированными средствами, в том числе через интеграции и ИИ. Согласие должно охватывать цели обработки, список действий и возможную передачу данных третьим лицам. В сценариях Make.com полезно ограничить объем передаваемых сведений и предусмотреть хранение основной массы ПДн в РФ.
Вопрос: Можно ли полностью автоматизировать отбор кандидатов через Make.com и ИИ без участия HR?
Ответ: Полностью перекладывать отбор на ИИ в найме я бы не стала, особенно в российских реалиях. ИИ и Make.com хорошо справляются с фильтрацией по формальным критериям и рутиной, но финальные решения лучше оставлять за человеком. Это снижает риск ошибочных отказов, улучшает репутацию работодателя и лучше стыкуется с ожиданиями кандидатов и регуляторов.
Вопрос: Сколько времени обычно занимает внедрение базовой автоматизации найма в Make.com?
Ответ: Для небольшой компании с 1-2 основными источниками откликов базовый сценарий можно запустить за 2-4 недели. Первые дни уходят на описание процесса и подготовку артефактов, затем настраиваются сценарии и тестируются на ограниченном потоке. После запуска еще 1-2 недели лучше закладывать на доработки по результатам работы и обратной связи команды.
Метки: ai-agents, makecom, n8n, автоматизация, автопостинг, контент-план