Если после одной отправки формы в amoCRM появляются две карточки, сначала найдите маршрут заявки. Простое объединение карточек убирает следствие, но следующая отправка может снова создать дубль.
Начните с важного различия: повторная доставка одной заявки и новый заказ прежнего клиента требуют разных действий.
Определите, что именно повторилось
Ситуация
Что проверить
Возможное решение
Одно событие формы доставлено дважды
Идентификатор заявки, время, отправленные данные
Обрабатывать событие один раз
Клиент повторно связался по текущей задаче
Текст обращения, заказ, активная сделка
Добавить обращение к действующей работе по принятому правилу
Клиент оформил другой заказ
Номер заказа, состав, дата, сумма
Создать самостоятельную сделку и связать с нужным контактом
В CRM появились два одинаковых контакта
Номер, email, связи со сделками
Проверить дубли контактов отдельно от дублей заказов
Одинаковый телефон не означает одинаковый заказ. У компании может быть общий номер, а у клиента — несколько параллельных покупок. Автоматическое объединение только по телефону способно потерять историю.
Проследите путь одной тестовой заявки
В согласованном тестовом сценарии отправьте одну заявку с узнаваемым комментарием, например «Проверка формы 14-10, тест 01». Не используйте реальные данные постороннего клиента.
Запишите страницу, форму, точное время и результат в CRM. Затем последовательно проверьте:
Сколько запросов на создание было отправлено в CRM.
Какие ID карточек появились и какой источник указан у каждой.
Обработчики должны иметь названия и журнал событий. Если журналов нет, начните с их добавления: иначе «исправление» будет проверяться по догадкам.
Типовые гипотезы — два одновременно подключённых маршрута, повторная отправка формы, повтор после тайм-аута, повторное действие автоматизации. Подтверждайте каждую журналами. Совпадение времени двух карточек ещё не показывает причину.
Проверьте штатный контроль дублей
В amoCRM откройте «Сделки → Настройки воронки» и настройки «Контроля дублей». Проверьте источники, признаки сопоставления, участвующие воронки и этапы, действие при совпадении и правило обновления полей.
По официальной справке amoCRM проверка зависит от источника; объединение возможно, когда одна заявка находится в «Неразобранном». Вне выбранных воронок и этапов сделки не участвуют в поиске. Если найдено больше трёх дублей, объединение не выполняется.
Поэтому переключатель сам по себе не доказывает, что ваш маршрут защищён. Уточните, попадает ли конкретная интеграция под эти правила. Если обработчик создаёт сделку своим запросом, проверять нужно его фактическое поведение.
До изменения правила решите, можно ли перезаписывать источник, ответственного, бюджет и данные заказа. Новое сообщение клиента не должно без согласованной причины заменять сведения первоначальной заявки.
Если ошибка в интеграции — защитите повторную обработку
Дальше речь о рекомендуемой архитектуре собственного обработчика, а не о гарантированной функции amoCRM.
У исходной заявки должен быть устойчивый ID. Повторная доставка этой же заявки обязана нести тот же ID. При поступлении обработчик проверяет журнал и резервирует событие для обработки. После создания карточки сохраняет ID сделки.
Схема «сначала поискать по телефону, потом создать» недостаточна: два параллельных процесса могут одновременно ничего не найти и оба отправить создание. Проверку и резервирование ID нужно сделать атомарно, например с уникальным ограничением в хранилище обработчика.
Что делать при тайм-ауте
Если запрос ушёл, но ответ не получен, не отправляйте создание вслепую повторно. Карточка могла уже появиться. Отметьте событие как требующее сверки и проверьте результат по внешнему ID, сохранённому в данных сделки, если ваш маршрут это поддерживает. Неоднозначный результат направьте на ручную проверку.
Срок хранения идентификаторов согласуйте с возможным периодом повторной доставки. Слишком короткий журнал позволит старому событию снова создать карточку.
Подготовьте задачу интегратору
Передайте конкретный воспроизводимый пример: URL формы, время, исходный ID заявки, получившиеся ID карточек, названия обработчиков и обезличенные фрагменты журналов. Зафиксируйте правило: что считается техническим повтором, новым обращением и новым заказом.
Попросите указать, где хранится ID, как блокируются параллельные события, что происходит при тайм-ауте и как создаётся уведомление об ошибке. Отдельно опишите, какие поля разрешено обновлять.
Для выбора самих процессов полезна статья о типах воронок продаж. Она помогает определить, к какой действующей работе относится обращение; защиту доставки нужно проектировать отдельно.
Проверьте исправление на разных сценариях
Проверка
Ожидаемое поведение
Одно новое событие
Одна карточка или одно обращение по принятому правилу
Повторная доставка того же ID
Вторая сделка не создаётся
Два одновременных сообщения с одним ID
Создание выполняется один раз
Другой заказ того же клиента
Новый заказ сохраняется самостоятельно
Тайм-аут после отправки создания
Сверка результата; нет слепого повторного создания
Совпадение в другой воронке
Поведение соответствует выбранной области поиска
Проверяйте не только число карточек, но и поля, связи с контактом, историю и задачи менеджера. Исправление должно сохранять полезные повторные обращения, а не просто сокращать количество сделок.