Дубли и спорные рекомендации: как проверять заявки

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

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

Сначала определите, что считается дублем

Правило уникальности должно быть записано до запуска. В нём указывают:

• какие поля используются для сопоставления: нормализованный телефон, email, идентификатор компании или их сочетание;

• считается ли повторное обращение отдельным лидом;

• через какой срок контакт может участвовать в новой кампании;

• как обрабатывается действующий клиент;

• что происходит, если одна компания оставила несколько контактов;

• кто принимает решение в неоднозначной ситуации.

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

Как настроить правила дедупликации в CRM

Дубли лидов в CRM проверяют по нескольким уровням, потому что один идентификатор не покрывает все ситуации. Сначала нормализуют точные контактные ключи: телефон, email, ИНН или другой разрешённый идентификатор организации. Затем ищут связанные сущности: существующий лид, контакт, компанию и открытую сделку. Наконец, учитывают срок и контекст обращения.

Правило лучше оформить как последовательность:

1. Найти точное совпадение по нормализованному ключу.

2. Проверить, относится ли запись к тому же человеку или организации.

3. Определить статус и владельца существующего обращения.

4. Сопоставить даты с действующим окном атрибуции.

5. Выбрать действие: объединить, связать, отклонить либо отправить на ручную проверку.

6. Сохранить причину и исходные записи независимо от решения.

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

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

Разделите три типа случаев

Технический дубль

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

Спорная атрибуция

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

Возможное нарушение

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

Правила саморефералов должны быть явными

Компания сама решает, разрешены ли рекомендации себя, родственников, связанных организаций и сотрудников. Эти ограничения нужно показать участнику до первой рекомендации.

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

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

Как разбирать две рекомендации одного клиента

Применяйте один порядок ко всем участникам:

1. Зафиксируйте обе записи и запретите дальнейшее ручное переписывание источника без причины.

2. Сопоставьте время первого принятого события, персональные идентификаторы и канал.

3. Проверьте окно атрибуции и наличие клиента в CRM до обеих рекомендаций.

4. Найдите подтверждение контакта: отправленную форму, согласие, запись разговора в допустимом контуре или комментарий ответственного.

5. Примените заранее выбранный принцип — например, приоритет первой принятой рекомендации.

6. Запишите решение, основание, автора и время изменения.

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

Что должно быть в карточке проверки

Проверяющему нужен компактный набор фактов:

• участник и программа;

• дата и способ передачи контакта;

• нормализованный ключ совпадения;

• предыдущие лиды и сделки по этому контакту;

• действующее окно атрибуции;

• текущий статус начисления;

• автоматические сигналы без обвинительной формулировки;

• решение, комментарий и ответственный.

В интерфейсе полезнее написать «совпадает телефон» или «найдена более ранняя рекомендация», чем сразу помечать запись словом «мошенничество». Нейтральная формулировка помогает не смешивать техническую ошибку и умышленное действие.

Иерархия доказательств источника

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

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

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

Порог автоматического и ручного решения

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

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

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

Что автоматизировать, а что оставить человеку

Автоматически можно нормализовать контакты, искать совпадения, проверять обязательные поля, рассчитывать срок окна и останавливать подтверждение спорного начисления. Система также может показать связанные записи и журнал изменений.

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

Денежное вознаграждение само по себе может усиливать поведение, ориентированное только на выплату, поэтому правила качества и проверки нужны ещё до масштабирования программы.[20] Но это не означает, что каждая ошибка участника является злоупотреблением.

Как сохранить проверяемую историю

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

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

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

Профилактика перед запуском

Проверьте семь пунктов:

1. Определены уникальность лида и окно атрибуции.

2. Описаны действующие клиенты и повторные обращения.

3. Есть отдельное правило для саморефералов и связанных лиц.

4. Указан момент, после которого появляется право на вознаграждение.

5. Назначен сотрудник, разбирающий спорные рекомендации.

6. Источник и изменения сохраняются в истории.

7. Тестовые дубли не проходят в реестр выплат.

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

Метрики качества проверки

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

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

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

Как это связано с Рекомкод

Рекомкод связывает рекомендации со статусами, сделками, начислениями и выплатами в рабочих разделах программы.[13][17][18] Ролевой доступ разделяет сведения участника и внутреннюю работу команды.[14] Эти функции дают основу для проверяемого процесса, но не заменяют условия конкретной компании и решение ответственного по спорному случаю.

При проектировании важно не обещать «автоматический антифрод», если фактически настроены только поиск совпадений и ручная проверка. Корректная формулировка — контроль дублей, прозрачная атрибуция и управляемое подтверждение результата.

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

Источники

• [13] https://app.recomcode.ru/help/manager-ambassador-playbook

• [14] https://app.recomcode.ru/help/ambassador-journey

• [17] https://app.recomcode.ru/help/referral-crm

• [18] https://app.recomcode.ru/help/rewards-window

• [20] https://doi.org/10.1509/jmkg.71.1.084