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