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