Двойные заявки в CRM: как найти причину и исправить отчётность

Следы отправки важнее похожих карточек

Менеджер открывает новое обращение, а коллега уже звонит тому же человеку по соседней карточке. Если одна отправка сайта создаёт две заявки в CRM, сначала нужно сохранить следы события и найти место повторения, иначе удаление лишней карточки очистит список лишь до следующего сбоя.

Начнём с формы, передающей данные в Битрикс24. В разбор входят нажатие кнопки, приём данных сайтом и создание записи в CRM. Похожий телефон ещё не доказывает повтор одной отправки. Человек вправе обратиться снова или запросить другую услугу. Поэтому компания определяет, что считает отдельным обращением, прежде чем настраивать объединение записей по совпавшим контактам.

Удалять сразу — плохой старт. У обеих карточек сохраняют ID, время создания, источник и связанные действия, а затем передают специалисту сведения об отправке формы, чтобы он мог сопоставить их с журналом обмена и отличить повторную доставку от нового запроса. Контактные данные не рассылают широкому кругу сотрудников. Рабочий набор доступен специалистам сайта и CRM, участвующим в разборе.

Как отличить повтор запроса от нового интереса

Повторная доставка относится к одному событию, которое система получила больше одного раза. Повторное обращение относится к новому намерению клиента, даже если имя и телефон совпадают с данными прежней карточки.

Номер телефона не различает отправки. Если компания продаёт несколько услуг, один клиент может интересоваться ими в разное время. Объединение всех записей с его номером скроет самостоятельные запросы. Противоположная крайность — считать каждую техническую попытку новой заявкой. Тогда отчёт завышает объём обращений, а менеджеры выполняют повторную работу. Различить эти ситуации помогает отдельный идентификатор отправки, который сохраняется на всём пути данных.

В задании стоит описать правило: одна успешно принятая отправка создаёт одно обращение, а новая самостоятельная отправка получает новый номер события, даже если связана с существующим клиентом, потому что бизнес должен видеть и историю отношений, и отдельные причины контакта. Такой номер проектирует специалист интеграции. Маркетолог определяет смысл события. Отдел продаж подтверждает, когда повтор следует считать новым интересом. Это решение предшествует настройке кнопок и полей.

Для разбора выбирают одну пару карточек с подтверждённым происхождением. Массовый список похожих телефонов полезен позже, когда уже понятно, какой технический признак искать. Иначе в выборку попадут обычные повторные клиенты, а расследование начнёт исправлять нормальную работу CRM.

Путь отправки от кнопки до CRM

Форма может отправить данные повторно после двойного нажатия, повторного запуска обработчика или неясного ответа сервера. Другой участок риска — передача из сайта в CRM, когда получатель уже создал карточку, но отправитель не получил подтверждение и решил повторить запрос.

Повтор не всегда виден пользователю. Он нажал кнопку один раз и увидел успех. Тем временем на странице могли работать два подключения, каждое из которых передало обращение. Или сайт сохранил данные и поставил задачу на доставку, а повторная попытка пришла после задержки ответа. Эти варианты нельзя различить по внешнему виду формы. Исполнитель сопоставляет время и номер события на каждом участке.

Метод POST, часто используемый для передачи форм, не обладает свойством идемпотентности: повтор запроса может снова изменить данные. Это прямо отмечено в справке MDN. Для заказчика вывод практический: наличие стандартного метода отправки не означает автоматической защиты от повторного создания карточки. Такую защиту включают в задачу обмена и принимают отдельным испытанием.

Если в журнале сайта видна одна принятая отправка, а в CRM появились две карточки, исследование переносится на передачу и обработку данных: повторное нажатие покупателя уже не объясняет расхождение между соседними участками. Если сайт принял два события с разными номерами, сначала выясняют, почему форма сформировала их из одного действия.

Дубликаты контактов и новые сделки

У стандартной CRM-формы Битрикс24 есть раздел «Сущности в CRM» и «Экспертная настройка» правил обработки дублей. В документации формы для контактов и компаний перечислены варианты разрешения, замены и объединения дубликатов.

Это другой уровень сопоставления. Настройка определяет, как использовать найденного клиента. Она не описывает универсальную защиту любой собственной интеграции от двух доставок одного запроса. По умолчанию после заполнения формы создаётся новая сделка. Опция «Использовать активную сделку, не создавать новую» доступна при замене или объединении дублей. Решение о такой настройке принимает отдел продаж, определив судьбу самостоятельных запросов клиента.

Если отдел ведёт несколько параллельных запросов одного клиента, использование активной сделки способно смешать разные поводы обращения, поэтому сначала стоит обсудить с руководителем продаж, в каких случаях сведения дополняют текущую работу, а в каких открывают самостоятельную. Для формы одной услуги правило может быть узким. Для общего обращения на сайте оно требует дополнительных признаков. Название настройки не заменяет описание процесса.

Собственная форма сайта может передавать данные через отдельный обработчик и вообще не использовать стандартные правила CRM-форм. Перед правкой специалист показывает фактический путь. Заказчик принимает решение об учёте клиента и обращения, а исполнитель указывает место, где это решение выполняется.

Защита при повторной доставке

Отключение кнопки после нажатия защищает от повторного действия человека в открытой форме, но не останавливает повторную передачу между серверами, которая может начаться уже после закрытия страницы. Чтобы повтор доставки не создавал новую заявку, принимающая сторона сравнивает идентификатор события с уже обработанными отправками и возвращает понятный результат предыдущей обработки.

Ключ принадлежит отправке. Использовать вместо него телефон неудобно: новое обращение того же человека может быть ошибочно отвергнуто. Генерировать новый ключ при каждой попытке доставки тоже бессмысленно, поскольку получатель перестанет узнавать повтор. Один номер сохраняют на всём пути повторных попыток. Специалист объясняет срок хранения сведений об обработке и показывает, что случится при доставке после долгой задержки. Заказчик сопоставляет этот ответ с реальным обменом: какие ошибки он покрывает, а какие потребуют отдельного разбора сотрудником.

Две копии могут прийти одновременно, и обе успеют получить ответ «такого события ещё нет» перед созданием первой карточки. Поэтому в задании отдельно называют параллельную доставку: исполнитель воспроизводит её и показывает, что CRM сохранила одно обращение, доступное менеджеру по ссылке. Последовательного повтора здесь недостаточно. Посетитель при этом получает ответ о принятии формы, а технические подробности обработки остаются в журнале интеграции.

При потере связи интерфейс сообщает о результате настолько определённо, насколько его знает сайт. Обещание «заявка не отправлена» опасно, если CRM могла уже принять данные. Лучше продумать состояние ожидания и безопасный повтор вместе с номером события, чтобы человек не пытался угадать, сколько раз нажать кнопку.

Испытания исправленной формы

Исправление принимают набором разных отправок в тестовой среде или с подменой внешних действий. Цель испытания — увидеть судьбу одного события в системе, сохранив реальные заявки, уведомления и звонки вне эксперимента.

Обычный успешный путь обязателен. Затем воспроизводят повторное нажатие, повтор доставки, задержку подтверждения и одновременные копии. Для каждого случая записывают исходный номер события и созданную карточку. Отдельно повторяют обращение от прежнего клиента с новым номером события. Оно помогает заметить слишком грубую защиту, которая вместе с техническим дублем блокирует настоящую повторную потребность клиента.

• Одна отправка сохраняется один раз и получает доступную менеджеру карточку.
• Повтор того же события возвращает прежний результат без второй заявки.
• Новое обращение того же человека обрабатывается по правилам отдела продаж.
• Задержка ответа не заставляет посетителя создавать несколько независимых отправок.
• Ошибка доставки попадает к ответственному и не исчезает из учёта.

Испытание заканчивают открытием отчёта и карточки менеджером под рабочими правами, потому что отсутствие второй записи в техническом журнале ещё не показывает, правильно ли обращение отнесено к источнику, назначено сотруднику и включено в нужную воронку. Отдел продаж подтверждает доступность сведений и продолжает тестовый сценарий обработки. Маркетолог сопоставляет источник с отправленной формой. Специалист сохраняет протокол доставки с номером события. Если карточка одна, но попала не тому сотруднику, замечание остаётся открытым до восстановления всего пути обращения.

Возвращаем отчётам понятный смысл

После устранения причины остаются старые записи. Их нельзя просто вычесть из общего числа по доле совпавших телефонов: среди похожих карточек могут находиться самостоятельные обращения, которые уже обработали разные сотрудники.

Очистка требует списка оснований. Для каждой подтверждённой пары сохраняют связь с исходным событием, выбранную основную карточку и действия, которые нужно перенести или учесть. Руководитель продаж решает судьбу работы менеджеров. Аналитик отмечает период, затронутый сбоем. Техническая команда объясняет, с какого момента исправление действует. В результате каждой исключённой из отчёта строке соответствует подтверждённое основание.

Подтверждённые технические повторы лучше сначала выделить отдельным признаком для анализа, чем массово удалять: в карточках могут оставаться комментарии, задачи и следы передачи, нужные для выяснения исхода обращения и разбора спорных цифр. После сверки компания выбирает окончательную очистку. Исходную выборку сохраняют в закрытом учёте. В отчёте описывают правило пересчёта и отмечают, какие записи исключили из количества обращений. Сотрудник, повторяющий расчёт позднее, сможет получить тот же итог и понять, почему он отличается от прежнего отчёта.

Число отправок формы, число обращений и число уникальных клиентов отвечают на разные вопросы. Отчёт становится полезнее, когда каждое название связано с ясным правилом подсчёта. Дубли технического события тогда не превращаются ни в успех рекламы, ни в претензию к менеджерам за якобы потерянные заявки.

Без учёта событий ошибка вернётся

Если закончить работу только объединением найденных карточек, следующий повтор доставки снова попадёт в воронку. Затраты проявятся в повторных звонках, споре за ответственность и отчётах, где техническая особенность обмена выглядит новым спросом, хотя клиент совершил одно действие.

Журнал сохраняют после исправления. В сопровождении назначают, кто принимает сообщение о неудачной передаче, кто разбирает повтор и где хранится связь события с карточкой. После изменений формы или интеграции команда повторяет набор испытаний. При заказе настройки CRM и обмена с сайтом передайте этот набор вместе с подтверждёнными дублями, чтобы исполнитель показал судьбу каждой отправки и оставил сотрудникам признаки, по которым они смогут обнаружить повторение ошибки. При следующем сбое сотрудники смогут найти связанные события по сохранённым номерам.