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