Интеграция сайта с CRM: куда пропадают заявки и откуда берутся дубли

Опишите рабочий результат для менеджера

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

Сформулируйте критерий: «После отправки заявки на замер в CRM появляется обращение с контактом, адресом объекта, источником и назначенным сотрудником». Если какой-то пункт собирается позже, это тоже нормально. Главное, чтобы владелец и разработчик одинаково понимали готовность. Сам факт успешного запроса к API ещё не означает, что карточка появилась там, где её ожидает отдел продаж.

Согласуйте карту полей

Сделайте небольшую таблицу: поле формы, поле CRM, обязательность и правило преобразования. Телефон, имя, услуга, комментарий и источник рекламы могут иметь разные форматы. Длинный текст нельзя молча обрезать до непонятного фрагмента. Если CRM требует значение, которого на сайте нет, заранее выберите корректный способ заполнения или измените процесс, а не вставляйте случайную заглушку.

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

Различайте дубль и новое обращение

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

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

Сохраняйте заявку при недоступности CRM

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

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

Назначьте владельца каждого поля

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

Вебхуки помогают получать события об изменениях; такой механизм описан, в частности, в документации amoCRM. Но наличие события не отменяет проверку порядка, повторов и актуальности. Владельцу полезно видеть схему обмена стрелками с подписями: что передаётся, в какую сторону и при каком действии. Если обе стрелки подписаны просто «Все данные», границы интеграции ещё не определены.

Проверяйте полный путь на стенде

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

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

Передайте интеграцию в эксплуатацию

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

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

Что проверить в своей задаче

1. Для формы выбраны сущность CRM, воронка и ответственный.
2. Карта полей согласована с будущим пользователем CRM.
3. Технический повтор отличается от нового заказа старого клиента.
4. Непереданные заявки сохраняются и видны сотруднику.
5. Проверены отказ CRM, восстановление и отсутствие лишних дублей.