n8n с нуля: первый рабочий сценарий автоматизации за вечер

Что такое ноды и триггеры в n8n и как собрать цепочку «заявка с сайта, разбор ИИ, карточка в CRM, уведомление». Пошагово, с граблями и границами no-code.

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

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

Что такое n8n и почему не Make

n8n это конструктор автоматизаций: вы соединяете блоки, а платформа гоняет по ним информацию. Главное отличие от облачных Zapier и Make в том, что n8n ставится на свой сервер. Одна команда docker compose up, и у вас личный сервис на своём домене.

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

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

Ноды и триггеры на пальцах

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

Триггер это первая нода, она запускает всё остальное. Три рабочих лошадки:

  • Webhook. n8n выдаёт адрес, на который ваш сайт отправляет заявку. Срабатывает мгновенно.
  • Schedule. Запуск по расписанию, скажем каждые 15 минут или в 9 утра.
  • Триггеры сервисов. Новое письмо в почте, сообщение в Telegram, строка в таблице.

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

Сценарий: заявка, разбор ИИ, CRM, уведомление

Собираем цепочку из шести нод.

1. Webhook. Метод POST, путь произвольный. В настройках сразу ставьте ответ «сразу», иначе форма на сайте будет висеть, пока отработает вся цепочка, а это 3-5 секунд с вызовом модели. Посетитель за это время успеет уйти.

2. Set. Приводим поля к общему виду: имя, контакт, текст, источник, метка времени. Полезно на будущее: когда добавится вторая форма и Telegram, все входы будут сводиться к одной структуре.

3. HTTP Request к языковой модели. Тут происходит вся магия. Отправляем текст заявки с инструкцией разобрать его на поля.

Промпт, который у нас выжил после переделок, устроен так:

Ты разбираешь заявки строительной компании.
Верни ТОЛЬКО JSON без пояснений:
{"тип_работ": "", "объект": "", "срочность": "низкая|средняя|высокая",
 "бюджет_упомянут": true|false, "готов_к_звонку": true|false,
 "краткое_резюме": "одно предложение"}
Если поля нет в тексте, оставь пустую строку. Не выдумывай.
Текст заявки: {{ $json.text }}

Температуру ставим 0. Модель должна быть скучной и повторяемой, творчество здесь вредит.

4. Code. Проверяем ответ. Пять строк на JavaScript: попробовать разобрать JSON, при ошибке подставить заглушку и поднять флаг «разобрать вручную». Без этой ноды первая же нестандартная заявка уронит весь сценарий. Модель иногда оборачивает JSON в markdown-блок, это лечится вырезанием обратных кавычек.

5. Bitrix24 или amoCRM. Создаём лид: имя, телефон, комментарий из краткого резюме, источник, ответственный по правилу распределения. Если срочность высокая, лид сразу летит старшему менеджеру.

6. Telegram. Сообщение в чат отдела: три строки и ссылка на карточку. Менеджеры смотрят в телефон чаще, чем в CRM, и это не изменить регламентом.

Итого шесть нод. Первая сборка занимает вечер, вылизывание под реальный поток заявок примерно неделю.

Тест перед запуском

Не включайте цепочку на боевой трафик сразу. Возьмите 20 старых заявок из почты и прогоните через сценарий с отключённой записью в CRM.

Смотрите на две вещи: правильно ли модель разложила поля и что произошло с кривыми заявками. Кривые в выборке обязательно найдутся: пустой текст, «перезвоните», сообщение на транслите, спам про SEO-услуги.

Короткий чек-лист перед боевым включением:

  1. Пустая заявка не роняет сценарий, а помечается флагом.
  2. Спам не создаёт лид в CRM.
  3. Повторная отправка той же формы не порождает второй карточки.
  4. Уведомление в чат приходит с телефоном и ссылкой, чтобы менеджеру не пришлось искать.
  5. При недоступности модели заявка всё равно попадает в CRM, пусть без разбора. Терять обращение из-за чужого сбоя нельзя.

У нас на такой прогонке всплыло, что модель считала срочным всё, где встречалось слово «срочно», включая рекламные рассылки. Добавили в промпт условие про источник, и мусор перестал будить старшего менеджера.

Три грабли, на которые мы наступили

Ретраи дублируют лидов. Сеть моргнула, n8n повторил шаг, в CRM появились две одинаковые карточки. Лечится ключом идемпотентности: перед созданием ищем лид по телефону за последние сутки. Пять минут работы, а без них менеджеры две недели ругаются на дубли.

Исходящие к Telegram могут не уходить. На одном из наших серверов запросы к api.telegram.org резались провайдером, нода отваливалась по таймауту без внятной ошибки. Пришлось поднимать релей. Диагностика заняла в разы больше времени, чем починка, потому что в интерфейсе это выглядело как «иногда не работает».

Молчаливые падения. Сценарий сломался в четверг, заметили во вторник, потому что никто не заметил тишину. С тех пор правило: у каждого рабочего процесса есть Error Workflow, который пишет в чат «сценарий такой-то упал, вот ошибка». И раз в сутки сценарий-сторож шлёт короткую сводку: столько-то запусков, столько-то ошибок.

Безопасность и порядок: то, о чём вспоминают поздно

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

Ключи внутри нод. Токен модели и пароль CRM должны жить в разделе Credentials, а не в поле HTTP-ноды. Разница вылезает при экспорте схемы: в первом случае вы отдаёте коллеге JSON без секретов, во втором отправляете ему свои ключи вместе с файлом.

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

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

Где no-code упирается в потолок

n8n прекрасен, пока схема помещается на экран. Потолок ощущается на трёх симптомах.

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

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

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

Наша рабочая граница выглядит так:

  • всё, что связывает сервисы и живёт на вебхуках, остаётся в n8n;
  • бизнес-логика, расчёты и работа с большими объёмами переезжают в отдельный сервис на Python с PostgreSQL;
  • n8n дёргает этот сервис как обычный HTTP-эндпоинт и отвечает за маршрутизацию.

Гибрид держится годами. Чистый no-code на сложной логике превращается в техдолг, который не поддержит никто, кроме автора схемы.

Чего не ждать от первого сценария

Он не заменит менеджера. Разбор заявки это подготовка карточки, а звонит и продаёт человек.

Он не сделает поток заявок чище. Если с сайта приходит спам, автоматизация начнёт быстро и аккуратно заводить спам в CRM. Фильтр придётся ставить отдельно.

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

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

Следующий шаг

План на ближайшие выходные, если хочется попробовать руками. Поднимите n8n в Docker на любом сервере за пару сотен рублей в месяц. Соберите цепочку из трёх нод: Webhook, Set, Telegram. Убедитесь, что заявка с тестовой формы долетает в чат за секунду.

Дальше добавляйте разбор моделью и запись в CRM. По одной ноде за раз, каждую проверяя на старых заявках.

Короткие ответы на частые вопросы

n8n бесплатный? Версия для своего сервера бесплатна для внутреннего использования компании, платить надо только за сам сервер. Облачные тарифы платные и считаются по числу выполнений. Лицензию перед коммерческим использованием стоит прочитать своими глазами, там есть нюансы про перепродажу.

Нужен ли программист? Для первых сценариев нет, хватит человека, который не боится JSON и умеет читать документацию API. Программист понадобится на двух вещах: поднять и обновлять сервер, написать нестандартные преобразования в Code-нодах.

Можно ли обойтись без своего сервера? Можно, есть облачная версия и есть Make. Для компании, где нет никого с доступом к консоли, это честный вариант. Взамен вы отдаёте содержимое заявок стороннему сервису и платите за объём.

А 1С? Прямой ноды нет, работают через промежуточный слой: обмен файлами по расписанию либо HTTP-сервис на стороне 1С. Так мы и делаем в проектах для снабжения, обмен идёт JSON-файлами по таймеру.

Сколько сценариев тянет маленький сервер? Пара гигабайт памяти спокойно держит десятки лёгких сценариев. Упирается всё обычно не в мощность, а в базу с историей выполнений и в сторонние API с их лимитами.

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

Хотите такой же процесс у себя?

Начните с AI-аудита: разберём процессы, покажем, где автоматизация окупится первой, и предложим сценарий внедрения.

Запросить AI-аудит Написать в Telegram