Заявка с сайта → CRM → Telegram: рабочая автоматизация на n8n

MAATRIX · 17 октября 2026 · 8 мин чтения

Посетитель заполнил форму, увидел «спасибо» и закрыл страницу. Менеджер ничего не получил: CRM отвечала ошибкой ровно в тот момент, когда сайт передавал заявку. В журнале остался красный значок, а в отделе продаж — убеждение, что сегодня просто мало обращений.

Надёжная автоматизация начинается с сохранения заявки. Создание карточки и уведомление идут следом и могут повторяться независимо. Соберём такой процесс в n8n: сайт передаёт данные, сервер фиксирует их, затем создаёт объект CRM и сообщает ответственному в Telegram. Общая схема подходит разным CRM; названия полей и способы авторизации нужно взять из документации именно вашей системы.

У формы должен быть номер обращения

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

{
  "submission_id": "demo-form-20261017-001",
  "name": "Тестовый посетитель",
  "email": "reader@example.com",
  "message": "Нужен сервер для приложения",
  "source_url": "https://example.com/contact",
  "submitted_at": "2026-10-17T10:00:00Z"
}

Идентификатор создаёт сервер сайта или иной доверенный приёмник формы. При повторе одной и той же отправки номер сохраняется. Если пользователь отправил отдельное новое обращение, номер должен измениться. Телефон или электронная почта не подходят как единственный ключ: человек вправе обратиться дважды с разными вопросами.

Лучше передавать заявку в n8n с серверной части сайта. Тогда секрет вебхука не окажется в JavaScript посетителя. Для полностью статического сайта потребуется отдельный защищённый приёмник с проверкой формы и ограничением частоты. CORS ограничивает поведение браузера, но не заменяет авторизацию и защиту от автоматических запросов.

Первый сценарий принимает и сохраняет

Добавьте Webhook с методом POST и отдельным путём, например site-leads. Включите подходящую серверную авторизацию, например Header auth, и сохраните секрет в Credentials. Настройте HTTPS для публичного адреса. Различие тестового и рабочего URL описано в документации Webhook.

В параметре Respond выберите Using Respond to Webhook Node. Немедленный ответ триггера здесь не подходит: подтверждение должно отправляться после записи в базу.

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

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

CREATE TABLE lead_inbox (
  submission_id text PRIMARY KEY,
  payload jsonb NOT NULL,
  state text NOT NULL DEFAULT 'new',
  crm_id text,
  received_at timestamptz NOT NULL DEFAULT now(),
  notified_at timestamptz
);

В Postgres node используйте параметризованный запрос, передавая значения через Query Parameters. Не склеивайте SQL с текстом пользователя. Поддерживаемые операции и параметры приведены в руководстве Postgres node.

WITH attempted AS (
  INSERT INTO lead_inbox (submission_id, payload)
  VALUES ($1, $2::jsonb)
  ON CONFLICT (submission_id) DO NOTHING
  RETURNING submission_id
)
SELECT EXISTS (SELECT 1 FROM attempted) AS inserted;

Здесь первый параметр — номер отправки, второй — сериализованный объект разрешённых данных. Запрос всегда возвращает одну строку с признаком новой записи, поэтому повтор не обрывает цепочку пустым результатом. При inserted = false следующим параметризованным SELECT прочитайте сохранённый payload по исходному submission_id и сравните с нормализованными данными запроса. Совпадение означает допустимый повтор; другой текст под тем же номером направьте в ветку конфликта, не перезаписывая исходное обращение.

Когда можно показывать посетителю «принято»

После успешной фиксации заявки используйте Respond to Webhook и верните номер обращения. Это означает, что система приняла данные и будет их обрабатывать. Не пишите «менеджер уже получил заявку», пока соответствующее действие не подтверждено.

Webhook должен ждать именно сохранения, а не всех внешних интеграций. Если CRM временно недоступна, посетитель всё равно получит подтверждение приёма. Если база недоступна, возвращайте ошибку и позволяйте сайту повторить передачу с тем же номером. Такой порядок честно разделяет приём данных и дальнейшую обработку.

В документации Respond to Webhook есть важная особенность: узел отвечает один раз, используя первый входящий элемент. Поэтому не разветвляйте поток так, чтобы несколько веток пытались независимо отвечать посетителю. Организуйте одну понятную ветку успеха и отдельные ветки контролируемого отказа.

Второй сценарий занимается CRM

Создайте отдельный workflow с Schedule Trigger. Для первого пилота он периодически выбирает записи со статусом new. Внешний запрос выполняйте штатным узлом CRM, если он поддерживает нужную операцию, либо HTTP Request с авторизацией из Credentials.

Сначала вручную создайте тестовую карточку через выбранный API и выпишите соответствие полей. Например, текст обращения идёт в описание, источник — в отдельное поле, а submission_id — в внешний идентификатор. Это ваши сопоставления, а не универсальная схема всех CRM.

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

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

Ошибки разделяйте. Недействительный ключ требует вмешательства, неверное обязательное поле — исправления данных, временная недоступность — ограниченного повтора. При ограничении частоты учитывайте рекомендации API и заголовок ожидания, если он возвращается. Не запускайте сотню повторов немедленно: CRM от этого не проникнется сочувствием.

Telegram сообщает о результате, а не хранит всё обращение

Создайте бота, подключите его к разрешённому чату и настройте Telegram credentials в n8n. Тестовую отправку сначала направьте себе. В рабочем уведомлении достаточно номера заявки, краткого описания, ответственного и ссылки на карточку CRM.

Не копируйте в общий чат всю переписку и лишние контакты. Доступ к чату и доступ к CRM часто устроены по-разному. Если уведомление содержит ссылку, сама CRM должна проверять права вошедшего сотрудника; секретная ссылка не заменяет эту проверку.

После успешной отправки сохраните notified_at. Если уведомление не прошло, повторяйте только его, не создавая карточку заново. Для оператора полезна отдельная очередь: заявки приняты, CRM создана, уведомление ожидает отправки. Она показывает, где именно задержался процесс.

Не считайте успешную отправку боту доказательством, что человек прочитал обращение. Если нужен контроль ответа менеджера, отслеживайте соответствующее действие в CRM отдельным процессом. Уведомление и выполнение работы — разные события.

Испытание из шести коротких сцен

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

Временно отключите тестовый доступ к CRM. Заявка должна сохраниться, а обработка — перейти в понятное состояние ожидания. Восстановите доступ и убедитесь, что карточка появилась один раз. Затем повторите опыт с Telegram: ошибка сообщения не должна откатывать создание CRM.

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

Публикация и сервер под процесс

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

В карточке ошибки показывайте этап, время последней попытки и понятное действие. Например: «Не заполнено обязательное поле “Город” — исправьте данные и повторите создание». Кнопка повторной обработки должна возвращать существующую запись в очередь, сохраняя её идентификатор. Копирование заявки вручную создаёт второй объект и обходит защиту от дублей.

Когда появится несколько обработчиков, добавьте захват заданий с ограниченным сроком владения. Исполнитель отмечает, что взял запись, и освобождает её после завершения; зависшая работа должна возвращаться в очередь по контролируемому правилу. Одной отметки «обрабатывается» без срока недостаточно: после аварии она может остаться навсегда. Это изменение проверяют отдельно на двух параллельных запусках, прежде чем повышать производительность.

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

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

После тестов опубликуйте оба workflow и переключите сайт на Production URL. В актуальном n8n рабочий вебхук регистрируется при публикации; тестовый адрес предназначен для отладки. Проверьте отправку с настоящей формы после публикации и найдите выполнение в разделе Executions.

Для небольшого потока заявок можно начать с VPS MAATRIX Uab Start: 2 vCPU, 4 GB RAM и 80 GB диска. При нескольких интеграциях, собственной базе и больших объёмах истории измерьте нагрузку и рассмотрите Heka Standard с 8 GB. Подойдёт поддерживаемая Ubuntu или Debian. Ограничьте срок хранения выполнений, резервируйте базу и ключ шифрования credentials.

В MAATRIX доступен VPS с установкой n8n. Остаётся подключить свои системы и настроить бизнес-правила. Самая ценная функция такого процесса незаметна на схеме: одна временная ошибка внешнего сервиса больше не превращает заинтересованного посетителя в потерянное обращение.