Краткий ответ
Связь сайта с CRM проектируют как маршрут обращения с понятным владельцем каждого этапа. Подтверждение сайта, создание записи в CRM и начало работы менеджера различаются; сбой обмена не должен приводить к незаметной потере заявки.
Определите основную запись обращения
Решите, где подтверждается приём заявки и какая система хранит её первоначальный идентификатор. Если сайт сначала надёжно сохраняет обращение, дальнейшая передача в CRM является отдельным этапом. Если сохранение зависит от ответа CRM, интерфейс должен учитывать её недоступность. Оба подхода требуют явных правил и проверок.
Пользователь не обязан понимать внутреннюю архитектуру. Ему нужен правдивый результат: обращение принято либо отправка не завершена. Не показывайте успех только после нажатия кнопки. При ошибке сохраняйте введённые данные и объясняйте безопасный следующий шаг, не заставляя человека многократно создавать одинаковые обращения.
Согласуйте границы систем
| Этап | Владелец | Проверяемое состояние |
|---|---|---|
| Ввод и проверка | Сайт | Допустимые поля |
| Принятие | Согласованное хранилище | Идентификатор обращения |
| Передача | Интеграция | Связь с записью CRM |
| Назначение | CRM и продажи | Ответственный сотрудник |
| Работа с клиентом | Менеджер | Следующий шаг |
Согласуйте карту полей и обязательные значения. Внутренние справочники CRM могут не совпадать с названиями услуг сайта. Храните устойчивые коды и понятные подписи отдельно. Если маркетолог меняет заголовок страницы, это не должно незаметно ломать назначение заявки или создавать новое направление в отчётах.
Продумайте повтор и исключение
После сетевого сбоя неизвестно, успела ли принимающая система создать запись. Повтор без проверки может дать дубль. Используйте согласованный идентификатор и правила идемпотентности, учитывая реальные возможности API. Если CRM не поддерживает нужную операцию напрямую, архитектура должна компенсировать ограничение безопасным способом.
Разберите отсутствие обязательного справочника, смену доступа и ошибку назначения. У каждой проблемы нужен наблюдаемый статус и ответственный. Не оставляйте заявку только в техническом журнале, который никто не читает. План интеграции включает восстановление и сверку, а не лишь формат успешного запроса.
Учебный пример заявки на несколько услуг
На учебном корпоративном сайте клиент выбирает разработку и аналитику. В CRM принята одна основная услуга и дополнительные интересы. Команда согласует, как передавать выбор, чтобы не создавать две несвязанные сделки автоматически. Менеджер получает исходный контекст и уточняет объём в одном разговоре.
Во время проверки ответ CRM задерживается. Сайт сохраняет подтверждённое обращение, интеграция позже завершает передачу, а повторная попытка связывается с той же записью. В другой архитектуре состояние может быть иным, но оно должно быть предусмотрено. Пример показывает важность бизнес-правила, которое невозможно получить простым копированием всех полей формы.
Согласуйте ответственность за отказ
При недоступности CRM сайт должен вести себя по заранее выбранному сценарию. Укажите, где сохраняется обращение, кто получает уведомление и как запускается повторная доставка. Нельзя оставлять пользователя с подтверждением успеха, если команда не знает, где искать его сообщение.
Отдельно проверьте изменение справочников: названий услуг, ответственных и источников. Переименование поля на одной стороне может влиять на отчёты другой. Составьте перечень таких связей и владельцев, чтобы обычная настройка CRM не становилась необъяснимой потерей части обращений с корпоративного сайта.
Проверьте результат вместе с продажами
Успешный API-ответ ещё не означает, что сотрудник увидел задачу. Проверьте карточку, ответственного, уведомление и доступ к истории. Используйте безопасный тестовый сценарий, чтобы не засорять рабочую статистику. Отдельно подтвердите, что данные других клиентов и секреты не попадают в открытые сообщения или аналитические параметры.
Итог передачи включает контракт, карту полей, проверочные сценарии и порядок обновления. Для аналитики фиксируйте принятую заявку отдельно от последующей квалификации. Тогда сайт, интеграция и продажи могут объяснить состояние каждого обращения и развивать процесс без споров о том, какая система якобы уже выполнила чужую часть работы.
Как принять интеграцию, если письмо пришло, а сделки нет
Разделите состояния обращения: принято сайтом, поставлено в доставку, создано во внешней CRM, назначено ответственному. Уведомление по почте подтверждает только соответствующий канал. Оно не доказывает, что менеджер получил рабочую карточку сделки.
Для учебной заявки сохраните внутренний ID и внешний ID CRM, затем временно отключите интеграцию и восстановите её. После повторной доставки должна появиться одна связанная запись, а задержка — остаться видимой в журнале. Отдельно отправьте новое обращение с тем же контактом: объединение клиентов не должно уничтожать отдельную задачу. Правила этих повторов и связей следует согласовать до запуска, иначе сайт и отдел продаж будут по-разному считать заявки.
Термины из материала
Применить к вашему проекту
Спроектируем передачу заявок с корпоративного сайта в CRM с контролем повторов и ошибок.
Обсудить задачу