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