Make AI Agent для воронки продаж: пошаговый гайд

Q: Нужны ли amoCRM или Битрикс24 обязательно?

Для памяти между днями — нужна **любая** система записи: CRM, Data Store, таблица. Без записи агент каждый раз начинает с нуля и снова спрашивает бюджет. amoCRM и Битрикс24 удобны тем, что менеджеры уже там работают; Google Sheets как временный костыль возможен, но для продаж хуже контролирует этапы и задачи.

Чем AI-агент отличается от чат-бота в отделе продаж

Чат-бот отвечает по готовым кнопкам и скрипту. Если клиент пишет свободно — «нужна поставка на 40 точек, бюджет до миллиона, срочно» — бот часто ломается или уводит в меню.

ИИ-агент — это сценарий с нейросетью, который читает свободный текст, решает, что делать дальше, и вызывает инструменты: найти контакт в CRM, создать сделку, написать менеджеру в Telegram.

Маркер: простыми словами. ИИ-агент — не «умный чат на сайте», а исполнитель с правами: он может запускать сценарии (tools), читать CRM и возвращать структурированный результат. Без tools это просто диалог с моделью.

В Make.com такой агент собирается на канвасе: инструкции → tools (отдельные сценарии) → запуск через модуль Run an agent. Решения видны в Reasoning Panel — не «чёрный ящик», а пошаговый след: что модель решила и какой tool вызвала.

Маркер: простыми словами. Reasoning Panel — панель на канвасе Make, где видно ход мыслей агента и вызовы инструментов. Нужна, чтобы проверить: агент действительно квалифицировал лид, а не «придумал» ответ.

Какие задачи отдать агенту, а какие оставить менеджеру

Отдайте агенту:

разбор заявки с формы / Telegram;
вопросы на квалификацию (бюджет, срок, роль, регион);
запись полей в CRM;
маршрутизация: горячий → менеджер, холодный → nurture;
черновик ответа клиенту.

Оставьте человеку:

скидки и особые условия;
статусы «договор / оплата / сделка выиграна»;
сложные B2B-переговоры;
любое необратимое сообщение клиенту, если уверенность модели низкая.

Коротко: агент ускоряет ранние этапы воронки. Менеджер закрывает деньги и доверие.

3–4

узких tools на старте

HITL

скидки и деньги — только человек

CRM

память лида между запусками

Где воронка теряет деньги без квалификации лидов

Воронка продаж — путь клиента от первого касания до оплаты: заявка → контакт → квалификация → предложение → сделка. Если на входе нет фильтра, менеджеры тратят день на «просто узнать цену» и «напишите потом».

Практика интеграций бот+CRM показывает типичную картину: без CRM и квалификации теряется до 40–60% эффекта автоматизации; скорость первого контакта падает с часов до минут, когда фильтр и маршрутизация работают. Это не «магия ИИ», а порядок: кто целевой, кто нет, кому звонить сейчас.

Этапы воронки, на которых «сырые» лиды убивают конверсию

Чаще всего ломается участок заявка → квалификация → первый контакт:

Лид пришёл с рекламы или Telegram.
Менеджер видит только имя и телефон.
Звонок вслепую → «неактуально» / «не тот сегмент».
В CRM статус «мусор», а реклама уже оплачена.

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

Лидогенерация без фильтра — типичный разрыв между заявкой и сделкой

Лидогенерация — привлечение заявок. Квалификация лидов — проверка, стоит ли тратить время продавца.

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

Разрыв выглядит так: маркетинг радуется числу заявок, продажи — пустой календарь. Агент закрывает разрыв, если у него есть чёткие критерии и запись в CRM, а не только «красивый ответ в чате».

Схема воронки · не hero

Лид → агент → CRM → менеджер

Заявка не «падает в чат», а проходит узкий контур Make: агент читает свободный текст, вызывает tools, получает Return output и только потом пишет в CRM или зовёт человека.

Вход: Telegram или webhook формы — один пакет лида.
Агент: Run an agent + tools (поиск контакта, скоринг, сделка).
Ветки: горячий → задача менеджеру; тёплый → nurture; холодный → автоответ.
HITL: скидка, крупный чек, негатив — только человек.

Дальше — какие поля и критерии скоринга зафиксировать до открытия Make, чтобы агент не «болтал».

Редакционная метафора пайплайна, не скриншот Make. Цвета веток: бирюза — автопоток, янтарь — эскалация человеку.

Что умеет Make AI Agent до первой автоматизации

Make AI Agent (поколение New) живёт на канвасе Scenario Builder. Типовой маршрут:

Create agent — создать агента.
Instructions — system prompt: роль, правила, запреты.
Tools — сценарии, которые агент может вызывать.
В рабочем сценарии — модуль Run an agent.
Каждый tool-сценарий заканчивается модулем Return output.

Маркер: простыми словами. Return output — обязательный «ответ инструмента» агенту. Без него агент вызвал сценарий, но не получил результат: дальше галлюцинирует или зависает в логике.

Важно для воронки: между запусками агент не помнит прошлый диалог. Он stateless — обработал вход, отдал выход, забыл. Память для продаж строится снаружи: CRM, Data Store, таблица.

Маркер: простыми словами. External memory (внешняя память) — хранение истории лида не «в голове модели», а в CRM/хранилище: статус, бюджет, last_event. Перед каждым запуском сценарий читает эти поля и передаёт агенту.

Квалификация, маршрутизация и передача в CRM одним сценарием

Рабочая схема для РФ:

Telegram / webhook формы → Run an agent → tools (поиск контакта, create/update deal, уведомление менеджеру) → Return output → ответ клиенту или задача человеку.

Агент отвечает за неструктурированный текст. Жёсткие шаги (дедуп по телефону, whitelist статусов, пауза перед вторым ответом) — обычные модули Make, не «на усмотрение модели».

Оплата Make из России иногда требует иностранной карты или посредника — заложите это в старт. Альтернатива self-host (n8n) имеет смысл, если важны данные on-prem и своя инфраструктура; для маркетолога без DevOps чаще быстрее стартовать с Make и CRM, которые уже есть.

Какие данные собрать, прежде чем открывать Make

Без критериев агент будет «болтать». Перед канвасом зафиксируйте на одной странице:

что считается целевым лидом;
какие 5–8 вопросов достаточно для скоринга;
какие поля обязательны в CRM;
когда звонить сразу, а когда — nurture;
что агенту запрещено писать клиенту.

Критерии «горячий / тёплый / холодный» без размытых формулировок

Пример для B2B-услуг (подставьте свои цифры):

Уровень	Признаки	Действие
Горячий	бюджет в диапазоне, срок ≤ 30 дней, ЛПР или влияющий	задача менеджеру ≤ 5 мин
Тёплый	интерес есть, бюджет/срок размыты	2–3 уточнения + nurture
Холодный	«просто узнать», нет задачи, нецелевой сегмент	автоответ + база nurture
Эскалация	негатив, юр. спор, скидка, крупный чек	только человек

Маркер: простыми словами. Скоринг / BANT — правила оценки лида. BANT: Budget (бюджет), Authority (кто решает), Need (потребность), Timing (срок). Не обязательно тащить аббревиатуру в чат клиенту — используйте её как чек-лист полей для агента.

Поля лида, которые агент обязан заполнить до передачи менеджеру

Минимальный JSON-контракт (компактно, не весь тред переписки):

lead_id / телефон / chat_id
stage (этап)
budget_band (диапазон бюджета)
urgency (срочность)
is_target (целевой / нет)
missing_fields (чего не хватает)
confidence (уверенность модели)
next_action (звонок / nurture / эскалация)
draft_reply (черновик ответа)

Маркер: простыми словами. Structured output — ответ модели в виде полей (JSON), а не свободного эссе. CRM и Router в Make читают поля, а не «угадывают смысл абзаца».

Пошаговая сборка агента в Make

Ниже — минимальный контур, который новичок может повторить за вечер. Цель: заявка → квалификация → запись в CRM → эскалация менеджеру.

Шаг 1. Триггер заявки и первый ответ агента

Создайте сценарий-фронт: Telegram Watch Updates или Custom webhook с формы сайта.
Добавьте модуль поиска контакта по телефону / chat_id (CRM или Data Store).
Соберите bundle: текст сообщения + уже известные поля лида.
Модуль Run an agent — передайте этот bundle в агента-квалификатора.

Признак успеха: в истории сценария видно входящее сообщение и запуск агента без ошибки auth.

Шаг 2. Модуль ИИ: промпт, правила, стоп-условия

Создайте агента (Create agent) с узкой ролью: «квалификатор лидов, не продавец».

В Instructions зафиксируйте:

задавать только недостающие поля из списка;
не обещать скидки и сроки поставки;
при confidence ниже порога — next_action = escalate;
возвращать только structured output по контракту полей.

Подключите 3–4 tool-сценария (не 15 «на всякий случай»):

qualify_parse — разбор текста → JSON полей;
crm_upsert — найти/создать лид и сделку;
notify_manager — сообщение в Telegram/задачу в CRM;
faq_safe — ответы только из Knowledge/FAQ-файла.

Каждый tool заканчивается Return output. Если tool делает Search Rows и возвращает много строк — агрегируйте до Return, иначе агент получит только первый bundle.

Признак успеха: в Reasoning Panel видны tool calls; agent получает непустой Return output.

Шаг 3. Ветки: квалифицирован → CRM; отказ → nurture; эскалация → человек

После агента поставьте Router по полям:

is_target = true и высокий confidence → create/update deal + задача менеджеру;
is_target = false → nurture (серия касаний, без звонка);
ключевые слова скидка/негатив/юрист или низкий confidence → только задача человеку, без автоотправки клиенту.

Маркер: простыми словами. HITL (human-in-the-loop) — человек подтверждает опасный шаг. Агент готовит черновик и данные; письмо клиенту или «денежный» статус уходит только после approve.

Признак успеха end-to-end: тестовая заявка создаёт/обновляет карточку в amoCRM или Битрикс24, менеджер получает уведомление, клиент не получает обещаний, которых нет в FAQ.

Типичные ошибки новичка на этом шаге

Нет Return output в tool — агент «глухой». Решение: последний модуль tool-сценария = Return output.
Слишком много tools — агент путает FAQ с create_deal. Решение: 3–4 узких tools, как роли команды.
Агент пишет в CRM «что угодно» — статусы плывут. Решение: модель отдаёт JSON, а смена статуса — детерминированный модуль по whitelist.
Два ответа на одно сообщение в Bitrix — webhook не успел ответить за ~3 секунды, пришёл повтор. Решение: быстрый ack + асинхронная очередь / debounce.

Защита от повторов (debounce): если Bitrix прислал webhook дважды, сценарий не должен дважды писать клиенту.

Ориентир по сборке tools и Return output — официальный how-to Make.

Связка с amoCRM и Битрикс24 без ручных переносов

Для русскоязычного отдела продаж чаще всего хватает нативных модулей Make + HTTP API.

amoCRM: поиск по телефону → если нет — создать контакт и сделку; проставить теги (ai_qualified, hot/warm/cold); создать задачу менеджеру.

Битрикс24: crm.lead.add / crm.deal.add / crm.deal.update через webhook. Важно: ответ на входящий webhook уложиться быстро, тяжёлую логику увести в очередь — иначе дубли.

Создание сделки и смена этапа воронки из Make

Паттерн lookup → classify → write:

Прочитать лид по ключу.
Отдать агенту только нужный контекст.
Записать статус, недостающие поля, last_event, next_action.

Не храните в CRM полный чат «как есть». Храните компактные поля — иначе память раздувается, а менеджер не читает карточку.

Какие статусы агент может менять сам, а какие — только после проверки

Действие	Агент сам	Только HITL
Тег «нужна квалификация»	да	—
Этап «новый → в работе квалификация»	да	—
Этап «отправлены материалы» (после nurture)	да, по правилу	—
«Счёт выставлен» / «оплата» / «выиграна»	нет	да
Отправка оффера со скидкой	нет	да
Ответ при негативе клиента	draft only	да

Правило из практики автоматизации рутины: обратимое (черновик, запись полей, чтение) — агенту; необратимое (письмо клиенту, денежный статус, удаление) — человеку. В прод-кейсах Битрикс+ИИ модель не пишет статусы напрямую: отдаёт structured output, а код/сценарий применяет whitelist.

Автоворонка поверх агента: когда нужен nurture, а не сразу звонок

Не каждый «тёплый» лид готов к звонку. Автоворонка — цепочка касаний после «не сейчас»: полезные сообщения, кейс, напоминание, повторный оффер.

Бот и цепочка касаний после «не сейчас»

Схема:

Агент пометил warm + missing_fields.
Сценарий (не агент) запускает серию: день 0 / день 2 / день 5.
Если человек ответил — снова Run an agent на новый текст.
Если стал hot — задача менеджеру.

Расписание follow-up — обычная автоматизация. Разбор свободного ответа — снова агент. Так вы не тратите credits агента на таймеры.

Нейросеть в продажах: скрипты менеджера vs решения агента

Нейросеть в продажах бывает в двух ролях:

Подсказчик — предлагает реплики менеджеру в CRM.
Квалификатор — сам ведёт ранний диалог и пишет поля.

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

Где агент квалифицирует, а где только подсказывает реплики

Много типовых заявок, ночной поток, Telegram — агент-квалификатор.
Крупный чек, долгий цикл, тендер — менеджер + подсказки.
После эскалации агент может готовить summary для менеджера, но не закрывать сделку сам.

Кейсы из открытых публикаций (ориентиры, не отраслевой бенчмарк): у LeadGet до 60% сделок на ранних этапах шли через агентов при декомпозиции ролей; в кейсе Velmi/Bitrix ответ ускорился с часов до десятков секунд, доля квалифицированных выросла примерно на 35%. Подробный разбор цифр и архитектуры — в подборке кейсов на Sostav и разборе Bitrix24+ИИ на Хабре.

Ключевой вывод кейсов: один «большой» агент на все этапы путается. Нужны узкие роли: Engagement → Qualifier → Support → Handoff. В Make это несколько agents или несколько tool-сценариев + оркестратор.

Ошибки, из-за которых агент «съедает» тёплые лиды

Слишком жёсткий скоринг и потеря B2B-заявок

Если агент требует сразу бюджет «точной цифрой», B2B-лиды уходят. В B2B бюджет часто диапазон, а ЛПР появляется на 2–3 касании.

Как чинить: разрешите budget_band = unknown, копите missing_fields, не ставьте cold только из-за одного пустого поля.

Дубли в CRM и сломанные этапы после интеграции

Типичные поломки:

create без поиска по телефону → два контакта на один номер;
агент двигает этап назад («новый») после того, как менеджер уже в переговорах;
двойной канал форма+Telegram без общего ключа.

Как чинить: дедуп до create; запрет понижать этап без HITL; единый lead_id/телефон как ключ памяти.

Ещё риск: свободный web-browsing у агента. Для квалификации лидов он обычно не нужен и расширяет поверхность ошибок. Давайте минимум прав.

Как проверить, что агент реально двигает конверсию

Без метрик агент — дорогой чат. Смотрите воронку, а не «красивость ответов».

Метрики: доля квалифицированных, скорость ответа, конверсия этап→этап

Минимум на 2–4 недели теста:

Метрика	Зачем
Время до первого ответа	Цель — минуты, не часы
Доля `is_target` среди всех заявок	Не раздувать «квалифицировано» ради отчёта
Конверсия квалификация → диалог с менеджером	Агент не должен «хоронить» тёплых
Конверсия этап→этап в CRM	Сломанные статусы видно сразу
Доля HITL-эскалаций	Если 80% — порог confidence слишком строгий или промпт слабый
Дубли лидов	Технический долг интеграции

Зафиксируйте baseline до запуска агента. Иначе не отличите эффект от сезонности рекламы.

Ориентир по SLA: в отраслевых пересказах ответ в первый час сильно повышает шанс квалификации vs ответ через сутки. Агент здесь выигрывает скоростью, если не врёт в содержании.

Make или n8n — когда менять инструмент, а не промпт

Не меняйте стек из-за одного плохого промпта. Меняйте, когда упираетесь в архитектуру.

Сигнал	Что делать
Нужна прозрачность решений для ОП	Make + Reasoning Panel
Нужна память между днями «из коробки»	n8n с memory-nodes или Make + CRM memory
Высокий объём и self-host	n8n
Максимально простой SMB без сложной логики	иногда быстрее Zapier Agents, но RU CRM чаще через HTTP
Уже сидите в Make + amo/Bitrix	сначала доведите Qualifier, не мигрируйте

Итог выбора для этой задачи: если цель — квалификация лидов и воронка на привычном Make, оставайтесь в Make и вынесите память в CRM. Переход на n8n оправдан командой с DevOps и требованиями к on-prem, а не «потому что в чате посоветовали».

FAQ

Можно ли собрать Make AI Agent без разработчика?

Да, базовый контур (Telegram/форма → агент → CRM → уведомление) собирается на no-code. Потребуются аккаунт Make, CRM и понимание полей сделки. Сложные кастомные API и очереди для высоких нагрузок уже ближе к разработчику — но для старта отдела продаж часто хватает модулей Make.

Чем квалификация лидов агентом отличается от формы на сайте?

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

Нужны ли amoCRM или Битрикс24 обязательно?

Для памяти между днями — нужна любая система записи: CRM, Data Store, таблица. Без записи агент каждый раз начинает с нуля и снова спрашивает бюджет. amoCRM и Битрикс24 удобны тем, что менеджеры уже там работают; Google Sheets как временный костыль возможен, но для продаж хуже контролирует этапы и задачи.

Сколько сценариев Make хватит на старте воронки?

Ориентир: 1 фронт-сценарий + 1 агент-квалификатор + 3–4 tool-сценария + 1 серия nurture. Этого достаточно, чтобы проверить конверсию. Не начинайте с «агента всего отдела продаж».

Как создать ИИ-агента «почти бесплатно» на старте?

У Make есть бесплатный/младший тариф с лимитом credits; агент тратит credits на reasoning и каждый tool call. Для теста хватит узкого scope и малого числа tools. Обещать «бесплатно навсегда» нельзя: нагрузка растёт с лидами. Перед боем сверьте актуальные лимиты в кабинете Make.

ИИ-агенты имеют смысл только для крупного отдела?

Нет. Имеет смысл там, где есть поток заявок и дорогая минута менеджера. Если лидов 5 в неделю и все «свои», сначала закройте ручной процесс. Если 50–400+ в месяц и половина нецелевые — квалификатор окупается быстрее обучения нового менеджера.

Что проверить у себя за один вечер

Описать критерии горячий/тёплый/холодный на полстраницы.
Собрать JSON-поля лида.
Создать агента с узким промптом и 3–4 tools + Return output.
Подключить Run an agent к Telegram или webhook.
Записать результат в CRM, а не только в чат.
Включить HITL на скидки, негатив и денежные статусы.
Прогнать 10 тестовых заявок и посмотреть Reasoning Panel + дубли.

Что проверяли по источникам

Официальный маршрут сборки Make AI Agents и роль Return output: How to build AI agents with Make.
Память агента между запусками и паттерн внешней памяти через CRM/Data Store — публикации Make про agent workflow memory.
Кейсы мультиагентной квалификации и цифры эффекта: Sostav.
Прод-грабли Bitrix webhook, structured output и запрет «LLM пишет статусы напрямую»: Хабр.
HITL и минимум прав агента — практика автоматизации рутины нейросетями (открытые разборы 2026).