Связали заявки с сайта и CRM через n8n

Как заявки обрабатывались раньше

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

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

Что нужно было автоматизировать

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

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

Почему использовали n8n

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

В n8n собрали процесс приёма и проверки данных, обращения к API EspoCRM и отправки уведомлений. На стороне сайта оставили создание идентификатора и сохранение неотправленного запроса. Успешный ответ посетителю не подменял подтверждение передачи в CRM.

Как устроили обмен

• Подготовили n8n и закрыли доступ к редактору сценариев. Настроили служебные учётные данные для обращения к CRM.

• Согласовали формат заявки: внешний идентификатор, контакты, интересующее оборудование, комментарий и источник обращения.

• На стороне формы добавили проверку обязательных полей и сохранение запроса до подтверждения обработки.

• В сценарии привели данные к согласованному формату, проверили их и создали обращение в CRM с нужным ответственным.

• Для внешнего идентификатора подготовили поле и контроль уникальности на стороне CRM. Повторную доставку связали с существующим обращением.

• Уведомление менеджеру отправили отдельным шагом после создания записи. Ошибка уведомления не должна создавать новую заявку.

• Настроили отдельный сценарий уведомления об ошибке и передали порядок поиска запроса и повторной обработки.

Как разделили сбои и повторные заявки

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

Также разделили запись в CRM и доставку уведомления. Обращение считается переданным после сохранения в CRM; письмо менеджеру является следующим действием. Ошибка почты попадает в отдельный разбор и не запускает создание обращения заново.

Какие ситуации проверили

• Корректная заявка создаёт обращение с нужными полями, источником и ответственным.

• Неполные данные не превращаются в пустую карточку клиента; отправитель получает понятный результат проверки.

• Повторная доставка того же запроса находит существующее обращение по внешнему идентификатору.

• Недоступность CRM не выдаётся за успешную передачу: запрос сохраняется для повторной обработки.

• Сбой на этапе уведомления фиксируется отдельно, а созданное обращение остаётся доступным менеджеру.

• После устранения причины обмен можно повторить с сохранением исходного идентификатора.

Что изменилось после подключения

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

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

Что нужно контролировать после запуска

В сопровождении проверяются неуспешные выполнения, доступность API, служебные учётные данные и доставка уведомлений. Историю обработки хранят в пределах согласованного срока, учитывая наличие контактных данных.

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

Решение для похожей задачи

Посмотреть состав решения