
Разбор · Опубликовали 08.10.2026
Дубли заявок сначала связывают с исходными событиями, затем исправляют повторную передачу в CRM
Как найти источник повторной отправки, сохранить историю продаж и принять ремонт по проверкам повторов и новых обращений.
Текст подготовлен машиной агентов под надзором Евгения Шилова, инженера, который ведёт vibecoding.ru · факты проверены 8 октября 2026
Дубли заявок сначала связывают с исходными событиями, затем исправляют место, которое повторно создаёт сделку в CRM.
Клиентского кейса ремонта CRM у нас нет, поэтому покажем механику проверки и наш похожий случай с повторными письмами.
Не хотите разбираться сами? Внедряем ИИ в ваш бизнес: задачи без лимита, одна цена в месяц, отмена в любой момент.
1. Одинаковый контакт ещё не означает дубль заявки.
Клиент может обратиться повторно по другому вопросу. Совпадающий телефон помогает найти похожие карточки, но не объясняет, почему они появились.
При объединении дублей клиентов нужно сохранить связи с заказами и историю общения.
Технический дубль возникает, когда система повторно обрабатывает одно обращение и создаёт ещё одну сделку. Новое обращение того же клиента требует отдельного решения отдела продаж.
Roistat отбирает похожие заявки по телефону, email и другим полям. Фильтр применяет заданное правило, но не выясняет причину повторной отправки.
Менять CRM до разбора источника рано. Выбор своей или готовой CRM решает другую задачу: здесь нужно починить путь уже полученной заявки.
Повтор доставки отличается от нового обращения.
Документация Roistat и AWS, проверена 08.10.2026. Это схема разбора, не результат ремонта клиентской CRM.
2. Каждую сделку связывают с событием и попытками передачи.
Первый результат диагностики должен объяснять происхождение сделок. В журнале обработки нужны источник обращения, его номер и результат передачи в CRM.
Номер события сохраняют при повторной доставке. Номер попытки меняется: так видно, сколько раз система пыталась передать одно обращение.
Stripe описывает повторы доставки и разные события для одного изменения. Поэтому номер для сверки берут по правилам источника, а не по похожему тексту.
Агенту достаточно обезличенных примеров и номеров событий. Данные клиентов в разработке требуют отдельного порядка доступа, всю CRM в чат не копируют.
След заявки должен доходить до результата в CRM.
Принципы идентификации запросов AWS и событий Stripe, проверены 08.10.2026. Состав журнала для заявки предложен редакцией.
3. Повтор должен возвращать результат, а не создавать новую сделку.
Выключенная после клика кнопка защищает только этот экран. Повтор может прийти от интеграции, из очереди или после перезапуска обработчика.
Защиту ставят перед созданием сделки. Ключ исходного события и состояние обработки сохраняют так, чтобы параллельные запросы не начали её независимо.
После таймаута результат сверяют. CRM могла создать сделку, а ответ потеряться: запись в нашей базе и создание сделки в чужой CRM происходят отдельно.
CRM с защитой повторов получает прежний ключ. Если защиты нет, неизвестный исход сверяют по внешнему номеру и журналу, остановив новое создание до выяснения.
Исправление должно переживать сбой ответа.
AWS, «Making retries safe with idempotent APIs», и документация Stripe о ключах повторных запросов, проверены 08.10.2026. Шаги для CRM предложены редакцией. Возможности конкретной CRM проверяют отдельно.
4. Старые дубли разбирают, сохраняя историю продажи.
Ремонт отправки не объединяет сделки, которые уже накопились. У них могут различаться ответственные, переписка и связанные заказы.
Сначала готовят список кандидатов и причину совпадения. К каждой группе добавляют исходное событие и след передачи, если они сохранились.
Решение принимает ответственный за продажи. Он выбирает основную сделку и согласует перенос истории средствами конкретной CRM, после чего результат сверяют с исходным списком.
Без следа событий одинаковые карточки остаются кандидатами на ручной разбор. Правило «оставить самую свежую» может убрать сделку, в которой менеджер уже договорился с клиентом.
Совпадение не даёт разрешения на удаление.
Редакционный порядок приёмки данных, 08.10.2026. Это предлагаемая процедура, не описание функции любой CRM.
5. Агент чинит код, инженер проверяет повторы и новые заявки.
Инженер ведёт машину агентов этого сайта, а работу принимает по наблюдаемому результату. Для дублей таким результатом станет связь события и сделки, а не только зелёная сборка.
У повторной обработки есть последствия за пределами CRM. Поэтому её проверяют и у писем, и у заявок, а не только по состоянию кнопки.
Собственный случай помогает выбрать проверку, но не доказывает ремонт чужой CRM. Ограничение частоты отправки письма и защита новой заявки решают разные задачи.
Повторный вызов стал повторным письмом.
17.07
Публичный вызов подписки отправлял новое письмо при каждом обращении для неподтверждённого адреса. Повторную отправку ограничили интервалом ожидания. Это наш случай с письмами, не с дублями CRM.
Собственный журнал разбора отправки писем, запись 17.07.2026, перепроверена 08.10.2026. Правило относится только к тому исправлению.
Задачу для ИИ-агента формулируют через проверяемое поведение. Одна и та же заявка после повтора должна вести к прежней сделке, новая заявка того же клиента должна оставаться новой.
Проверка должна включать одновременную обработку и потерю ответа. Последовательная отправка не обнаружит ошибку, при которой оба обработчика успели решить, что заявки ещё нет.
Ответственность за ошибки агента остаётся у людей. Агент готовит код, инженер принимает правку, ответственный за продажи согласует разбор старых сделок.
Критерий приёмки записывают до правки. Одинаковый номер события с изменённым содержимым тоже отправляют на разбор: молча считать его уже обработанным опасно.
Проверки должны ловить и дубли, и потерю нового обращения.
Набор приёмочных сценариев редакции на основе документации AWS и Stripe, 08.10.2026. Это план проверки для вашего проекта, не результаты нашего испытания CRM.
6. После ремонта считают исходные заявки и результаты обработки.
Пустой список дублей ещё не доказывает исправление. Фильтр может скрыть повторные сделки вместе с настоящими новыми заявками.
За согласованный период сверяют события, сделки, повторы и неизвестные исходы. Каждое исключение получает ответственного за разбор.
Ремонт своего кода входит в подписку на агентную разработку. «Один проект» стоит 250 000 ₽/мес. на 08.10.2026. Это цена подписки, не одного ремонта.
Первой задачей можно сделать ремонт передачи и проверку повторов. Чтобы обсудить разбор заявок, опишите источник, путь до CRM и наблюдаемый повтор.
Что и как мы проверяли
| Факт | Что известно | Проверено |
|---|---|---|
| Повторы Stripe | Официальные страницы о событиях и ключах запросов. Поддержка ключа описана для Stripe, её нельзя приписывать любой CRM. | 2026-10-08 |
| След запроса AWS | Статья Malcolm Featonby: потеря ответа, идентификатор запроса, согласованная запись. Перенос принципа на CRM сделан редакцией. | 2026-10-08 |
| Фильтр Roistat | Официальная документация о проверке заявок по совпадающим полям. Настройки зависят от интеграции. | 2026-10-08 |
| Наш случай с письмами | Перечитана запись разбора 17.07.2026. Повторную отправку письма ограничили интервалом ожидания. Кейса ремонта клиентской CRM у нас нет. | 2026-10-08 |
| Цена подписки | Живая страница /services: «Один проект», 250 000 ₽ в месяц. Это цена подписки, не смета разового ремонта. | 2026-10-08 |
7. Частые вопросы
Как правильно: «заявка дубль» или «дублирование заявки»?+
Так называют похожую проблему разными словами. Для ремонта нужно уточнить, повторилась доставка одного события или клиент сделал новое обращение.
Достаточно ли включить поиск дублей в CRM?+
Если причина в настройке штатной интеграции, её проверяют первой. Если ваш код повторяет создание после сбоя, фильтр совпадающих телефонов не заменяет ремонт этого кода.
Какой срок хранения ключа выбрать?+
Он должен покрывать согласованное окно повторов источника, включая задержки и перезапуски. Универсального срока для всех CRM нет, наш интервал повторной отправки письма сюда переносить нельзя.
Можно ли убрать дубли автоматически?+
Кандидатов можно найти автоматически. Перенос переписки, связанных заказов и выбор основной сделки требуют согласованного правила и проверки результата.
Если номера исходного события нет, откуда его взять?+
В своём источнике номер создают до первой отправки и сохраняют при повторе. Для стороннего источника без устойчивого номера сначала согласуют способ распознать обращение; старые карточки сверяют по журналам и данным CRM.
Источники
- Stripe: повторная доставка событий, проверено 08.10.2026 — официальная документация
- Stripe: ключи повторных запросов, проверено 08.10.2026 — официальная документация
- Malcolm Featonby: безопасные повторы API, проверено 08.10.2026 — инженеры вендора
- Roistat: проверка поступающих заявок на дубли, проверено 08.10.2026 — официальная документация
- vibecoding.ru: цена подписки «Один проект», проверено 08.10.2026 — публичные условия сервиса
- vibecoding.ru: открытая история работы машины, проверено 08.10.2026 — прибор проекта, не доказательство ремонта CRM
Запомнить
- Одинаковый контакт ещё не доказывает дубль. Сначала найдите исходное событие.
- Сохраняйте связь события, попыток передачи и сделки, чтобы видеть место повтора.
- После таймаута сверяйте результат в CRM до нового создания.
- Старые карточки разбирайте с ответственным за продажи, сохраняя историю.
- Принимайте ремонт по проверкам повторов и новых обращений, затем наблюдайте исключения.