CRM и API / 02
Интеграция сайта с CRM: как передавать заявки без потерь и дублей
Форма показала сообщение «Отправлено», но сделки в CRM нет. Или клиент нажал кнопку дважды, и менеджеры получили две одинаковые заявки. Интеграция сайта с CRM должна обеспечивать понятный путь данных от формы до ответственного сотрудника, включая ошибки и повторные попытки.
Главная мысль
Успешная отправка формы и создание сделки — разные события. Сохраняйте заявку до подтверждения пользователю, отслеживайте доставку и заранее определите правила повторов.
1. Согласуйте данные до подключения API
Начните с таблицы соответствия полей. Для каждого значения укажите источник, формат, обязательность и поле в CRM. Обычно нужны контакт, текст запроса, услуга, язык обращения и источник страницы. Не собирайте дополнительные данные только потому, что CRM позволяет их хранить.
Разделите контакт и заявку. Один клиент может обратиться с двумя разными задачами: совпадающий email не означает дубликат сделки. Правило объединения контактов и правило устранения повторной отправки должны быть разными. Решите также, можно ли обновлять имя или телефон существующего клиента данными из публичной формы.
| Поле | Назначение | Важное правило |
|---|---|---|
| request_id | Идентификатор заявки | Сохраняется при техническом повторе |
| email / phone | Контакт клиента | Проверяется на сервере |
| service / message | Контекст обращения | Не теряется при создании сделки |
| language / source | Маршрутизация заявки | Значения ограничены допустимым списком |
2. Постройте надёжный путь заявки
Для интеграции, где потеря обращения недопустима, разумна схема: браузер → сервер сайта → сохранённая заявка → отправка в CRM → запись внешнего идентификатора. Подтверждение приёма показывают после надёжного сохранения. Если CRM временно недоступна, пользователь не должен повторно заполнять уже принятую форму.
В небольшой системе роль очереди может выполнять таблица с состоянием обработки и отдельным обработчиком. Для более сложной нагрузки используют специализированную очередь. Важна не технология сама по себе, а возможность различать состояния «принята», «ожидает передачи», «доставлена» и «требует внимания». Ошибка записи в собственное хранилище должна возвращать понятное сообщение, а не ложное подтверждение.
3. Защититесь от повторов и неопределённых ответов
Идемпотентность означает, что повтор одной операции не создаёт новый результат. Для повторной отправки той же заявки используйте стабильный идентификатор и серверную проверку. Отключение кнопки после нажатия полезно для интерфейса, но не защищает от сетевых повторов или параллельной обработки.
Сложнее случай, когда CRM создала сделку, но ответ потерялся. Простой повтор может создать дубль. Если API поддерживает ключ идемпотентности, используйте его; иначе понадобится поиск по внешнему идентификатору и процедура сверки. Возможности конкретной CRM нужно проверить до обещаний обработки «ровно один раз».
При обратных уведомлениях тоже проверяйте условия доставки. Например, Stripe документирует возможные повторные события и отсутствие гарантии порядка доставки. Это пример поведения внешнего API, а не универсальное правило для каждой CRM: её контракт проверяют отдельно.
4. Разделите временные и постоянные ошибки
Тайм-аут или временная недоступность часто допускают повтор с увеличивающейся задержкой. Ошибка формата поля требует исправления данных. Истёкший ключ доступа требует внимания ответственного. Бесконечно повторять все ошибки одинаково — значит скрывать проблему и создавать лишнюю нагрузку.
Ограничьте число автоматических попыток, учитывайте документированные лимиты API и сохраняйте причину последнего отказа. Для заявок, которые не удалось передать, нужен список ручного разбора. Контролируйте не только число ошибок, но и возраст самой старой ожидающей заявки: система может отвечать успешно, пока очередь незаметно растёт.
5. Ограничьте доступы и содержимое журналов
Ключ CRM должен использоваться на сервере. Выдавайте интеграции только необходимые разрешения, отделяйте тестовое окружение от рабочего и заранее определяйте порядок смены ключей. Входящие уведомления проверяйте способом, который описан поставщиком API: одного секретного адреса недостаточно для уверенности в отправителе.
В техническом журнале обычно достаточно идентификатора заявки, времени, статуса и безопасного кода ошибки. Полные сообщения клиентов и токены не должны бесконтрольно копироваться в логи. Отдельно согласуйте сроки хранения и доступ к данным с ответственным за их обработку в компании.
6. Как принять интеграцию перед запуском
Проверяйте не только появление сделки в тестовой CRM, но и весь сценарий работы менеджера: назначение ответственного, язык, услугу, уведомление и возможность найти исходную заявку. Для каждого теста зафиксируйте ожидаемый результат и способ его наблюдения.
В передаче проекта должны быть описание полей и статусов, перечень настроек без секретов, инструкция по повторной обработке и контакты ответственного за сопровождение. Если бизнесу требуется двусторонняя синхронизация, отдельно определите главную систему для каждого поля и правило разрешения конфликтов.
- Обычная заявка создаёт запись с правильными полями и ответственным.
- Повтор одного запроса не создаёт вторую сделку.
- Новый запрос того же клиента сохраняется как отдельное обращение.
- При недоступности CRM заявка остаётся доступной для обработки.
- Потерянный ответ CRM проверяется без слепого создания дубля.
- Неверные данные и недействующий ключ заметны ответственному.
- После восстановления связи очередь обрабатывается, результат можно сверить.
Частые вопросы
- Можно ли отправлять данные в CRM прямо из браузера?
- Публичный API поставщика иногда допускает такой сценарий. Но секретный ключ нельзя размещать в браузере. Серверный приём позволяет централизованно проверять данные, контролировать повторы и отслеживать доставку.
- Когда достаточно готового плагина?
- Когда он поддерживает нужные поля, совместим с вашей версией сайта и CRM, показывает ошибки и позволяет восстановить неуспешную передачу. Эти свойства стоит проверить на тестовых заявках до запуска.
- Обязательна ли двусторонняя синхронизация?
- Нет. Для приёма заявок часто достаточно передачи с сайта в CRM. Обратная синхронизация нужна, когда сайт показывает клиенту статусы или данные, которыми управляют в CRM.
Применим к вашей задаче
Расскажите, на чём работает сайт, какую CRM используете и что должно происходить после заявки. Определим схему интеграции и проверки перед запуском.
Обсудить задачуУслуга по теме: Backend, API и CRM-интеграции