Настройка n8n: пошаговый чеклист связки заявок

Запрос «n8n настройка» в поиске редко означает «установить Docker и забыть». На разборе чаще слышу: форма на сайте уже шлёт POST, бот в Telegram принимает сообщения, а менеджер по-прежнему копирует телефоны в личный чат. Люди ищут не каталог узлов, а порядок: куда падает обращение, какие поля обязательны, где строка учёта и кто отвечает клиенту.

Автоматизация заявок - весь контур «вход → учёт → сигнал → ответственный» на любой платформе. Уведомления о заявках - первый измеримый сигнал после формы: одно сообщение с полями и ссылкой на строку учёта. Здесь фокус на том, как перевести уже согласованный контур в n8n workflows, не смешивая темы с обзором «нужен ли вам n8n вообще» - это sibling n8n для бизнеса.

Карта, которую я рисую до canvas:

триггер (форма / webhook / Telegram bot)
        ↓
   обязательные поля (имя, контакт, суть, источник)
        ↓
   учёт (таблица или CRM - одна точка write)
        ↓
   уведомление ответственному (Telegram / email)
        ↓
   человек при сбое (execution + эскалация клиенту)

Пять звеньев, без которых n8n только ускоряет хаос. Триггер - одна primary-точка входа на пилоте, не пять форм с разными полями. Поля - 3-5 штук письменно до подключения CRM. Учёт - одна строка с id, статусом и именем того, кто взял в работу. Уведомление - не «весь чат компании», а один ответственный и резервный. Человек - тот, кто откроет execution, если workflow упал в 02:00.

На одном разборе у сервисной компании заявки приходили из Tilda в почту владельца, дублировались в WhatsApp, а «учёт» жил в заметках. Реклама шла, в ленте формы копились ответы. Я предложил один webhook, пять полей и таблицу. Только после недели без потерь я подключил n8n - иначе автоматизация через n8n закрепила бы разорванный процесс.

Что не настраиваю в n8n, пока нет карты:

Если процесс ещё не описан словами на одной странице, сначала наставничество - карта до узлов, потом canvas.

n8n настройка для связки заявок начинается не с выбора всех интеграций, а с контура размещения: Cloud или self-host. Cloud убирает с вашего плеча reverse proxy и TLS - production URL webhook появляется после publish workflow. Self-host Community даёт контроль данных на своём VPS, но HTTPS, WEBHOOK_URL за proxy и бэкап executions - ваша зона ответственности. Concurrent production executions в Cloud ограничены тарифом (см. Pricing на n8n.io); на self-host в regular mode лимита по умолчанию нет, опционально N8N_CONCURRENCY_PRODUCTION_LIMIT.

Порядок первого workspace, который я прохожу на пилоте:

1. 01

   Создать аккаунт Cloud или поднять Docker на VPS с публичным https-доменом.

2. 02

   Завести Credentials для Telegram (BotFather /newbot, username заканчивается на bot) и для CRM или Google Sheets.

3. 03

   Создать workflow «Заявка - тест», не смешивая prod и эксперименты в одном файле.

4. 04

   Добавить Webhook или Telegram Trigger, узел Set для маппинга, один write в учёт.

5. 05

   Нажать Listen for test event или отправить тест-запрос на /webhook-test/... - данные видны в редакторе.

6. 06

   Publish workflow и переключить форму на production URL /webhook/... - только после зелёного теста.

Active workflow и production URL - разные режимы одного узла Webhook. Test URL (/webhook-test/...) работает, пока редактор слушает событие; production URL регистрируется при publish и пишет executions в журнал. Форма на сайте, которая всё ещё смотрит на test URL, даёт иллюзию «n8n сломан» - на самом деле webhook просто не в prod.

Self-host vs cloud для webhook заявок с сайта:

Токены и ключи API - только в Credentials UI n8n. Credential overwrites через env официально не рекомендованы: данные могут утечь пользователям инстанса. При экспорте workflow в git проверяю, что в JSON нет bot token - только ссылки на credential id.

Первый workflow я держу плоским: не больше пяти узлов до первой тест-заявки end-to-end. Ветки IF, дедуп и второй канал - после того, как одна заявка стабильно доходит до строки учёта и алерта.

Webhook для заявки - типовой вход, когда Tilda, конструктор форм или свой сайт умеет POST JSON на URL n8n. Узел Webhook принимает тело, отдаёт его следующим узлам; максимальный payload по документации n8n - 16 MB (self-host можно сузить через N8N_PAYLOAD_SIZE_MAX). Аутентификация входящего POST: Basic, Header или JWT - выбираю до того, как URL попадёт в публичную форму.

Пример POST-тела, которое я прошу разработчика формы или ставлю в Postman для теста - без секретов и prod URL:

{
  "name": "Анна",
  "phone": "+79001234567",
  "message": "Нужен расчёт на пятницу",
  "source": "landing-main",
  "utm": {
    "source": "yandex",
    "medium": "cpc",
    "campaign": "service-sept"
  }
}

Следующий узел Set приводит имена к тому, что ждёт таблица или CRM: lead_name, contact, text, source, utm_campaign. Ошибка «поле пустое в CRM» часто не в CRM, а в маппинге: форма шлёт tel, а HTTP Request ждёт phone.

Для webhook telegram bot через Bot API картина другая. Telegram принимает setWebhook только на HTTPS; поддерживаемые порты - 443, 80, 88, 8443. Опциональный secret_token приходит в заголовке X-Telegram-Bot-Api-Secret-Token - его сверяю в IF или в auth webhook node, чтобы POST не принимал кто угодно. Один бот - один webhook URL: если n8n держит test и prod одновременно, срабатывает только один режим. Workaround из docs: отдельный test-бот или unpublish workflow на время отладки.

Схема «форма → n8n → учёт» для сайта:

форма (POST JSON)
    → Webhook (production URL после publish)
    → Set (маппинг полей)
    → Google Sheets / HTTP CRM
    → Telegram Send Message (ответственному)

Схема «бот → n8n» через Telegram Trigger описана в следующем разделе; api telegram webhook и webhook telegram bot в поиске часто смешивают - первое про Bot API, второе про приём update от Telegram в n8n, не про POST с лендинга.

Перед подключением формы проверяю три вещи: production URL скопирован после publish, auth на webhook включён, тест-заявка отправлена с публичной страницы, не из редактора конструктора (у многих preview шлёт другой origin).

n8n telegram workflow на пилоте - не «бот на все вопросы», а один сценарий приёма заявки с фиксированными полями. Telegram Trigger слушает Message или Callback; bot access token живёт в Credentials, не в parameters узла. После триггера - Set с маппингом текста или кнопок в lead_name, lead_text, source=telegram_bot, затем write в CRM или таблицу и Send Message ответственному с id строки.

На разборе у студии записи клиенты писали боту «хочу на пятницу 15:00». Менеджер пересылал сообщения в общий чат. Я предложил шаблон: кнопки «Запись» / «Вопрос», одно текстовое поле для даты, webhook в n8n, строка в Google Sheets и алерт двум ответственным. Через три дня стало видно, сколько обращений зависло без ответа - не из-за бота, а из-за отсутствия учёта до n8n.

Telegram Trigger vs webhook от формы:

Продолжение темы полей карточки и статусов - в интеграции Telegram и CRM. Здесь фокус на узлах n8n: IF на пустой телефон, Send Message с текстом «укажите номер», Error Trigger в отдельном workflow.

Минимальный фрагмент цепочки Telegram → учёт (плейсхолдеры, без токенов):

{
  "nodes": [
    {
      "name": "Telegram Trigger",
      "type": "n8n-nodes-base.telegramTrigger",
      "parameters": { "updates": ["message"] },
      "credentials": { "telegramApi": { "id": "CREDENTIAL_ID", "name": "Bot prod" } }
    },
    {
      "name": "Map fields",
      "type": "n8n-nodes-base.set",
      "parameters": {
        "assignments": {
          "assignments": [
            { "name": "contact", "value": "={{ $json.message.contact?.phone_number || 'не указан' }}" },
            { "name": "message", "value": "={{ $json.message.text }}" },
            { "name": "source", "value": "telegram_bot" }
          ]
        }
      }
    }
  ]
}

IF на ошибку HTTP Request в CRM: при 4xx/5xx - Send Message владельцу workflow с execution.id и текстом клиента, чтобы человек мог перезвонить, пока интеграция чинится.

Примеры автоматизации n8n, которые я чаще собираю на пилоте, - не каталог из двадцати шаблонов, а два рабочих маршрута. Автоматизация бизнеса n8n здесь - про заявки, не про HR и 1С; шум из хвоста «автоматизация заявок» отсекаю на этапе карты.

Шаблон A - форма → CRM → Telegram. Webhook ← POST с лендинга → Set → HTTP Request в CRM → Send Message менеджеру с ссылкой на карточку → Error Trigger workflow при падении CRM.

Шаблон B - Telegram → таблица → ответственный. Telegram Trigger ← сообщение клиента → Set (нормализация телефона) → Google Sheets append → Send Message ответственному с номером строки → Schedule не нужен, только realtime.

На пилоте не смешиваю A и B в одном workflow: разные триггеры - разные файлы, общий sub-workflow только для маппинга, если поля совпадают.

Расширения после 3-7 дней без потерь: dedup по phone в IF, второй канал уведомлений, статус new → in_progress через webhook обратно из CRM. Каждое расширение - отдельная test-заявка и запись в чеклисте, не «добавил узел и забыл».

Для cron-напоминаний «заявка без ответа 2 часа» нужен Schedule Trigger и отдельный workflow, который читает таблицу - это уже второй слой после стабильного приёма. Подробнее про выбор платформы и пилот - в материале n8n для бизнеса, здесь не повторяю сравнение с Zapier.

Ошибки на связке заявок редко «магические» - почти всегда test URL вместо production, неактивный workflow или токен в экспорте. Таблица симптомов, с которой я начинаю разбор execution:

Error Trigger - отдельный workflow: создаю «Ошибки заявок», добавляю узел Error Trigger, в Settings основного workflow указываю его как Error workflow. При падении узла CRM или Sheets ответственный получает Telegram с текстом ошибки и id execution, если ошибка не в самом trigger.

Если ошибка в trigger (битый webhook URL, отозванный bot token), в данных error workflow меньше полей execution{} - execution.id может отсутствовать. Это не баг n8n, а сигнал чинить вход до prod, а не только нотификацию.

N8n Assistant и похожие ассистенты обещают собрать или починить workflow текстом. Я использую их после рабочего контура и критерия проверки: N тест-заявок без потерь, publish включён, error workflow настроен. Без триггера, согласованных полей и человека на эскалации ассистент правит узлы в пустоте - быстрее, но не ближе к клиенту, который ждёт звонка.

Чеклист, который я прохожу перед тем, как отдать production URL заказчику формы или бота:

1. Карта контура на одной странице: триггер, поля, учёт, уведомление, ответственный.
2. Credentials созданы: Telegram bot, CRM/Sheets, webhook auth - без токенов в JSON.
3. Workflow опубликован (Active); форма смотрит на production URL, не test.
4. Set-узел: все обязательные поля замаплены; тест POST с публичной страницы.
5. Write в учёт: одна строка с id, status=new, assigned_to или пусто до ответа.
6. Алерт ответственному и резервному: оба получили test-сообщение.
7. Error workflow подключён в Settings; тестовое падение CRM шлёт алерт.
8. Пилот 3-7 дней: журнал executions без «тихих» провалов; дедуп при необходимости.

Пункт 4 повторяю три раза с разными браузерами и с телефона - конструкторы форм иногда шлют другой JSON с mobile. Пункт 8 - не галочка: если за неделю два execution красные и никто не открыл, автоматизация n8n снова превращается в чёрный ящик.

После чеклиста имеет смысл зафиксировать владельца workflow в команде заказчика: кто смотрит Executions, кто меняет Credentials при ротации bot token, куда писать при смене домена формы.

Самостоятельная n8n настройка уместна, когда контур описан, есть человек на executions и пилот на одной связке. Зову настройку под ключ или подключаюсь сам, когда нет HTTPS и некому держать self-host, спорят о полях CRM месяц, нужны несколько каналов с dedup и SLA, или команда не открывала n8n после первого сбоя. Это не конкуренция с DIY - в n8n для бизнеса разобрано, когда пилот на своих силах, а когда проще заказать сборку и handover.

Критерий «готово» для меня один: тест-заявка с публичной точки входа → строка учёта → алерт → живой ответ клиенту в согласованные сроки, без ручного копипаста между системами. Всё остальное - улучшения после 3-7 дней стабильного контура.