Ключевая цель — выстроить найм поваров и курьеров.

В массовом рекрутменте скорость ответа критически важна для конверсии в найм. Если рекрутер не связывается с кандидатом в течение часа, процент недозвонов возрастает на 30%.

«Есть контакт» — лидогенератор, поэтому компания заинтересована в скорости обработки. Но был нюанс: чем больше отправляли откликов, тем ниже становилась скорость обработки. В некоторых проектах кандидатам перезванивали лишь через 3 дня.

Поскольку из Авито приходило больше всего откликов, специалисты «Есть контакт» начали автоматизацию с этой площадки. Решили подключить AI-агента к диалогу с кандидатами. Они решали 2 задачи:

1. Быстрый ответ на отклики.
2. Валидация кандидатов в разговоре, чтобы к рекрутерам попадали только те, кто проходит по условиям.

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

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

А еще n8n легко интегрировать с внешними сервисами (например, CRM, Telegram, Google Sheets). Это ускорило запуск MVP и упростило варианты масштабирования в дальнейшем.

В n8n есть встроенная временная память (context или workflow data), но в «Есть контакт» решили не использовать ее для хранения истории диалогов. Вместо этого подключили внешнюю базу PostgreSQL. Почему так:

Отказ от встроенной памяти и переход на внешнюю базу данных стал шагом к надежности, гибкости и масштабируемости системы. Это обеспечило устойчивую работу AI-рекрутера и упростило сопровождение HR-процессов.

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

С ним система теряла масштабируемость и становилась неудобной в управлении. Любые изменения в логике — например, корректировка фильтрации откликов, обновление формата сообщений или замена механизма авторизации — требовали вносить правки во множество workflow вручную. Это занимало много времени и увеличивало риск ошибок.

Чтобы решить проблему, команда разделила систему на три обобщенные и переиспользуемые стадии:

• Авторизация. Все ключи, токены и идентификаторы для подключения к Авито API хранятся в одном сценарии. Это упрощает замену токенов, повторную авторизацию и отладку.

• Обработка данных (бизнес-логика). В отдельном сценарии реализована логика: получение откликов, фильтрация по условиям (например, наличие резюме, релевантность опыта), формирование сообщений и фиксация состояний в БД. Любые изменения теперь вносятся один раз и применяются ко всем кабинетам.

• Маршрутизатор. Этот workflow определяет, к какому аккаунту относится событие (например, отклик), и направляет его в нужный обработчик. Для подключения нового кабинета достаточно зарегистрировать его в конфигурации, без создания отдельного workflow.

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

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

Одной из задач при построении логики HR-бота стало определение категории вакансии. От этого зависело, какой промпт применит модель для ответа кандидату.

Ручная категоризация — привязка каждого объявления к направлению («курьер», «продавец», «менеджер») — выглядела очевидным решением, но при десятках аккаунтов и сотнях объявлений оно оказалось нежизнеспособным.

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

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

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

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

После внедрения AI-рекрутера скорость найма сократилась с 20 дней до 8. Этого удалось добиться за счет более полного сбора спроса на job-бордах, вывода вакансий на первые страницы и опережения конкурентов, а также охвата каналов, где кандидаты обычно не ищут работу — например, в Яндексе и ВКонтакте.

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