Семь сценариев n8n для бизнеса: от заявки до контроля оплаты

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

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

1. Заявка с сайта становится задачей отдела продаж

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

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

2. Письмо с запросом получает тему и ответственного

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

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

3. Вопрос сотрудника находит ответ в базе знаний

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

Приёмка: правильный источник открывается по ссылке, отменённая инструкция не используется, закрытый документ недоступен посторонней роли. Для отсутствующего ответа предусмотрен переход к владельцу знаний. Подробнее подготовка источников разобрана в статье о корпоративной базе знаний с ИИ. Начните с одного подразделения, а не со всех файлов организации.

4. Коммерческое предложение собирается как черновик

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

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

5. Зависшая сделка превращается в напоминание

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

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

6. Оплата обновляет учёт и маркетинговую аналитику

Вход — подтверждённое событие оплаты из учётной системы. Оно связывается с заказом и сделкой, обновляет согласованные поля и при наличии нужных идентификаторов передаётся в аналитику. Частичная оплата, возврат и повторное уведомление должны иметь отдельные правила. Не следует считать каждое поступление новым покупателем или новой полной продажей.

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

7. Еженедельный отчёт собирается без ручного копирования

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

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

Как выбрать первый сценарий

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

Что включить в сопровождение

Запланируйте обновления подключений, проверку прав, хранение журналов и реакцию на сбой. Срок хранения исходных данных выбирают по задаче и требованиям компании; полный текст переписки не обязательно нужен в каждом логе. Контрольный запуск после изменения CRM или формы помогает обнаружить поломку до потери настоящих обращений.

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

Термины из статьи

• Стоимость клиента
• Сквозная аналитика

Источники

• n8n: возможности AI-агентов и логики процессов
• Яндекс.Метрика: передача офлайн-конверсий