Покупатель оставил телефон на сайте, дождался вращающегося индикатора и нажал кнопку ещё раз. Через минуту ему звонят два менеджера. Каждый видит свою карточку в CRM, системе учёта клиентов, и считает обращение новым. Третий экземпляр появляется после того, как сервис передачи данных повторяет запрос с оборванным ответом.
Это условный пример, знакомый по устройству многих интеграций. У него несколько причин, поэтому правило «удалять всё с одинаковым телефоном» опасно. Постоянный покупатель может оформить два самостоятельных заказа. Сотрудники компании иногда оставляют общий рабочий номер. Автоматическое объединение таких обращений скрывает часть работы.
Для борьбы с дублями нужно определить, что именно повторилось. Один запрос мог приехать несколько раз, клиент мог дополнить прежнюю заявку или заказать новую услугу. Дальше разобрана схема, по которой руководитель продаж и разработчик смогут согласовать эти случаи, проверить передачу данных и принять результат на тестовых обращениях.
Найдите место, где появилась вторая карточка
Начните с нескольких подтверждённых дублей. Для каждой пары выпишите время отправки формы, время приёма сервером и время создания карточки. Добавьте источник обращения и номер запроса, если система его сохраняет. Телефон нужен для поиска примера, но причину появления копии обычно объясняют записи о передаче данных.
Допустим, сервер принял одну заявку, а CRM получила два запроса на создание. Тогда искать ошибку следует между этими системами. Если сервер уже получил две отдельные отправки, проверьте поведение формы и повторные действия клиента. Уведомления в почте тоже считайте отдельно. Три письма могут относиться к одной карточке, и исправление почтовой рассылки никак не изменит количество сделок.
Проверьте, сколько маршрутов ведёт в CRM. Форму иногда подключают напрямую через встроенную интеграцию, а затем добавляют ещё один сервис автоматизации. Оба исправно создают карточки. При этом менеджер может вручную переносить обращения из почты, потому что прежняя инструкция всё ещё требует такого действия. Список подключений полезно сверить с фактической работой отдела.
Эта проверка тесно связана с поиском потерянных обращений. В материале о заявках, которые пропадают с сайта разобрана передача между формой, сервером и местом работы менеджера. Одна схема пути заявки помогает искать оба дефекта. Для каждого перехода нужен наблюдаемый результат, иначе команда вынуждена гадать по последнему письму.
Разделите контакт, обращение и попытку отправки
Один человек может оставить много заявок. Поэтому контакт хранит сведения о человеке, обращение описывает конкретную потребность, а попытка отправки показывает, как эти сведения доставляли. Даже если CRM называет сущности иначе, такое разделение стоит сохранить в правилах интеграции.
Представим учебный пример с заказом уборки. Клиент просит убрать квартиру в пятницу, а через час заказывает уборку офиса в понедельник. Совпадение телефона ожидаемо, услуги и адреса различаются. Оба обращения должны дойти до менеджера. Если покупатель повторно отправил прежнюю форму из-за задержки ответа, у отдела должна остаться одна задача по квартире.
Отдельный случай возникает при уточнении. В повторном сообщении человек меняет площадь квартиры или добавляет необходимость вымыть окна. Полезно привязать сообщение к открытому обращению и показать менеджеру разницу. Молчаливое удаление «дубля» лишит исполнителя новых требований. Правило объединения должно сохранять исходные значения, время уточнения и автора изменения.
Опишите эти решения вместе с руководителем продаж. Для совпавшего номера открытого обращения обычно достаточно обновления истории. Для одного телефона без номера заявки требуется сравнение услуги и содержания. При сомнении система ставит отметку для проверки человеком. Допустимый уровень самостоятельности зависит от последствий ошибки: потерянная новая продажа может стоить дороже лишней карточки.
Закрепите номер за одной отправкой
Технический повтор проще узнавать по специальному идентификатору. Это номер операции, который остаётся прежним при повторных попытках доставить одну заявку. Сервер запоминает результат первой успешной обработки и при повторе возвращает ссылку на созданное обращение. Разработчики называют такое поведение идемпотентностью.
Номер нужно создавать до первой отправки и сохранять на весь срок повторных попыток. Если при каждом сетевом сбое генерировать новый, сервер увидит самостоятельные операции. При оформлении следующего заказа нужен следующий номер. Поведение кнопки «Отправить ещё одну заявку» поэтому тоже входит в техническое задание, вместе с обновлением страницы и возвращением к форме.
Готовые сервисы описывают подобный механизм в своих правилах. Например, документация Stripe об идемпотентных запросах объясняет повтор операции с прежним ключом и проверку совпадения параметров. Это пример конкретного API, программного интерфейса сервиса. Наличие такого механизма у вашей CRM следует проверить отдельно, вместе со сроком хранения ключей и поведением при ошибке.
Если один номер пришёл с другим содержимым, интеграция должна сохранить конфликт для разбора. Подмена данных под прежним номером опасна: клиент мог исправить адрес, а программа вернула старый результат. В задании заранее определите, какие изменения относятся к уточнению, и предусмотрите отдельное действие для правки уже принятой заявки.
Защитите запись от одновременных запросов
Проверка «такой номер уже есть» перед созданием карточки оставляет промежуток между чтением и записью. Два запроса способны пройти проверку одновременно и оба создать обращение. Поэтому защита нужна в месте, где система окончательно сохраняет номер обработанной операции.
В собственной базе разработчик может задать запрет на повтор сочетания источника и номера операции. В документации PostgreSQL такое ограничение называется UNIQUE. Источник в сочетании нужен потому, что два независимых сервиса могут выдать одинаковые номера. Для обязательных частей сочетания следует запретить пустое значение.
Сохранение обращения и отметки об обработке выполняют согласованно. Иначе сбой между действиями оставит заявку без отметки, и повтор создаст копию. Если CRM находится во внешнем сервисе, местная база сама по себе проблему не закрывает. Понадобится поддержка повторов со стороны CRM либо поиск по переданному внешнему номеру с разбором неопределённого результата.
При автоматизации обработки заявок полезно сразу разобрать этот промежуток с подрядчиком. Покажите сценарий, в котором CRM создала карточку, а ответ потерялся. Исполнитель должен объяснить, как следующая попытка найдёт уже созданную запись и что произойдёт, если поиск временно недоступен.
