Клиент оставил одну заявку, а менеджеры получили две карточки и оба начали ему звонить. В такой ситуации недостаточно скрыть повторную запись: нужно выяснить, где одна отправка превратилась в несколько действий. Причиной может оказаться повторное нажатие кнопки, повторная доставка события или попытка интеграции восстановиться после сбоя.
Ниже — порядок проверки для сайта и Telegram-бота, которые передают обращения в CRM. Это рекомендации по устройству процесса, а не описание конкретного внедрения. Общую схему подключения форм и оплаты разобрали в статье об интеграции сайта с CRM; здесь сосредоточимся на повторах.
Разделите дубли контактов, заявок и событий
Одинаковый телефон ещё не означает одинаковую заявку. Покупатель может заказать вторую услугу, обратиться в другой филиал или вернуться через месяц. Если объединять все обращения по номеру, вместе с дублями можно потерять реальные заказы.
- Дубль контакта: две записи об одном человеке. Их объединение затрагивает историю общения и права доступа.
- Дубль заявки: один запрос клиента создал несколько карточек работы.
- Повтор события: система получила уже обработанное уведомление ещё раз. Нового намерения клиента в нём нет.
Зафиксируйте, что считается отдельной заявкой именно в вашем процессе. Например, завершённая анкета на расчёт сайта и запрос на разработку бота могут быть двумя задачами одного контакта. Повторная передача той же анкеты после сетевого сбоя должна оставаться одной задачей.
Найдите место появления повтора
Возьмите одну пару дублирующихся карточек и восстановите путь: отправка формы или действие в боте, приём сервером, постановка на передачу, запрос к CRM, создание карточки. Сравните время, идентификаторы и результат каждой попытки. Это помогает отличить две исходные отправки от одного обращения, которое интеграция отправила дважды.
Проверьте, нет ли одновременно двух маршрутов. Например, форма может отправлять заявку через встроенный модуль CRM и отдельный обработчик. В этом случае защита внутри одного обработчика не остановит создание карточки по второму пути.
В журнале достаточно хранить идентификатор заявки, канал, этап и результат операции. Не копируйте туда целиком контакты, переписку и документы без необходимости. Ограничьте доступ к журналу и заранее определите срок хранения. Вопросы источника рекламы рассматриваются отдельно: UTM-метки помогают связать заявку с переходом, но сами по себе не устраняют дубли.
Дайте заявке устойчивый идентификатор
Для формы сайта полезно назначать идентификатор одной логической отправке. Повтор этой же операции должен использовать тот же идентификатор; новая заявка — новый. Серверу нужно проверять его независимо от того, что происходит с кнопкой в браузере.
У Telegram есть идентификатор события update_id. Официальная документация Telegram Bot API указывает, что он помогает игнорировать повторные обновления. При неуспешном HTTP-ответе на webhook Telegram повторяет доставку. Поэтому уже принятый update не должен заново создавать заявку.
При этом два отдельных нажатия кнопки могут дать разные события. Для анкеты нужен ещё идентификатор самой заявки: он связывает шаги диалога и отправку в CRM. Защита по update_id решает повтор доставки, а правила анкеты — повтор завершения одной и той же заявки.
Не используйте только текст сообщения или телефон как уникальный ключ. Два заказа могут выглядеть одинаково, но быть самостоятельными. Условия создания новой заявки стоит внести в техническое задание на Telegram-бота.
Проверьте одновременную обработку и повторную отправку
Отключение кнопки после нажатия удобно для пользователя, но серверная защита всё равно нужна. Два запроса могут прийти почти одновременно. Если оба сначала проверят «заявки ещё нет», а затем создадут её, простой проверки перед записью окажется недостаточно.
Обсудите с разработчиком атомарную фиксацию идентификатора — операцию, при которой право обработать конкретную отправку получает только один обработчик. Это может обеспечиваться уникальным ограничением в хранилище и согласованным порядком записи. Конкретное решение зависит от используемой системы.
Полезно разделить приём обращения и передачу в CRM. Сначала надёжно сохранить входящую заявку, затем выполнять передачу с контролируемыми повторами. Успешное подтверждение приёма должно означать, что обращение сохранено и может быть восстановлено после сбоя. Если подтвердить webhook до сохранения, следующий этап может потерять заявку.
Отдельно обработайте неопределённый ответ CRM
Сложный случай: CRM создала карточку, но ответ не дошёл до интеграции. Отсутствие ответа не доказывает, что операции не было. Слепое повторение запроса на создание может дать вторую карточку.
Если CRM и её API позволяют хранить и искать внешний идентификатор заявки, используйте его для сверки перед повторной передачей. Проверьте ограничения конкретного API: наличие такого поля ещё не означает, что одновременные запросы автоматически защищены от дублей.
Когда достоверно проверить результат нельзя, выделите состояние «требует сверки». Сотрудник или отдельный процесс должен сопоставить обращение с карточками и решить, нужна ли новая попытка. Это лучше, чем показывать «всё отправлено» при неизвестном результате. Контроль таких состояний связан с задачей сокращения потерь заявок с рекламы.
Разберите существующие дубли без потери истории
До массового объединения подготовьте резервную копию или доступную выгрузку и согласуйте правила проверки. Сопоставляйте содержание заявки, время, канал, ответственного и историю действий. Не удаляйте карточку только потому, что в соседней записан тот же номер.
Для работы с Россией и Беларусью учитывайте страну, филиал и валюту заказа. Обращения одного контакта в разные подразделения могут иметь разные условия и ответственных. Формат номера телефона стоит нормализовать, но сам номер не должен быть единственным основанием для объединения.
Перед изменением проверьте, куда попадут заметки, задачи, вложения и источник обращения. Если механизм CRM не переносит нужную историю, безопаснее сначала связать записи и передать их на ручную проверку. Для спорных случаев назначьте ответственного, чтобы очистка базы не остановилась на бесконечной очереди исключений.
Проведите приёмку на сбоях и реальных повторах
Проверяйте интеграцию в тестовой воронке или на специально обозначенных обращениях, без звонков реальным клиентам. Для каждого сценария заранее запишите ожидаемое число заявок и действия менеджера.
- Дважды отправьте одну форму с тем же идентификатором: должна остаться одна заявка.
- Запустите параллельную обработку одной отправки: повтор не должен создавать вторую карточку.
- Повторно передайте тот же Telegram update: бизнес-действие выполняется один раз.
- Смоделируйте создание карточки с потерей ответа CRM: система сверяет результат или оставляет понятное исключение.
- Отключите CRM, затем восстановите: сохранённая заявка передаётся без размножения.
- Создайте новый заказ того же клиента: он проходит как самостоятельная заявка.
- Проверьте обращения одного контакта в разные филиалы: условия и ответственные не смешиваются.
После исправления сравнивайте число принятых обращений, сохранённых заявок, подтверждённых карточек и ошибок передачи. Один общий счётчик «успешно» не объяснит, на каком этапе появился повтор.
Для оценки разработки или доработки Telegram-бота подготовьте схему маршрутов, название CRM и обезличенный пример дубля. Состав работ по подключению системы разобран в материале о стоимости интеграции бота с CRM. Если повторы начинаются в форме, потребуется проверить также обработку заявок на сайте.