CRM без дублей: валидация, скоринг и AI на практике

Дубликаты в базах данных — проблема универсальная. Но именно в CRM-системах она приобретает особую остроту: здесь каждая запись — это живой клиент, а не товар с артикулом или уникальным ID. Когда в систему поступает новая заявка, далеко не всегда очевидно, новый ли это лид или уже существующий контакт, который снова вышел на связь. Именно эта неопределённость и становится питательной средой для дублей.

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

А узнать больше можно в нашем видео:

https://www.youtube.com/watch?v=eiGyRJkcbpU

Почему появляются дубликаты

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

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

Чем дубликаты вредят бизнесу

Последствия дублей выходят далеко за рамки "лишних записей в таблице":

1. Потери в продажах. Заявки не обрабатываются, лиды теряются. Один и тот же контакт может быть назначен сразу нескольким менеджерам — и тогда к клиенту обращаются все одновременно или не обращается никто из-за путаницы в ответственности.

2. Усложнение системы. Дубли создают дополнительную нагрузку на функционал, порождают edge-кейсы и нестандартные сценарии, которые невозможно предусмотреть заранее. Система становится всё сложнее и менее предсказуемой.

3. Искажение аналитики. Отчёты, построенные на данных с дублями, перестают отражать реальность. Принимать бизнес-решения на основе такой статистики — значит рисковать стратегическими ошибками.

Что досталось нам в наследство: bad practices реального проекта

Большинство проблем, с которыми мы столкнулись, были заложены ещё на старте — другой командой, которая проектировала систему до нас.

Главная из них — использование единственной сущности «лид» для абсолютно всех сценариев. Гость офлайн-мероприятия, онлайн-заявка с сайта, человек, пришедший в офис лично — всё это попадало в одну таблицу. Со временем в ней накопилось более 500 колонок, а функционал начал конфликтовать сам с собой.

При этом ни один из потоков входящих лидов не проходил нормальной валидации. Тысячи менеджеров-продажников с минимальным контролем и обучением создавали записи практически без ограничений. Результат — критическая масса дублей и полная неопределённость с правилами их объединения: при 500+ колонках и десятках сценариев мёрдж превратился в отдельную нетривиальную задачу.

Два направления борьбы с дублями

Эффективная работа с дубликатами строится по двум направлениям, и важно развивать оба одновременно.

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

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

Как мы автоматизировали мёрдж с помощью AI и скоринга

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

• Поиск дублей. На первом этапе мы применяли жёсткие правила (hard rules) для грубой выборки потенциальных дублей и группировали их. Дальше эти группы передавались на анализ AI: он изучал набор ключевых полей и выносил вердикт — дубли или нет — с пояснением причин (AI Reason).

• Определение мастер-записи. Чтобы выбрать основную запись из группы дублей, мы разработали скоринговую модель — математический алгоритм, который на основе данных по каждому сплиту определял наиболее важный и актуальный рекорд. Чем выше скор — тем вероятнее, что именно эта запись должна стать мастером.

• Автомаппинг полей. Вручную сопоставлять 500 полей нереально. Поэтому мы разработали правила автоматического маппинга, которые минимизировали риск потери важных данных при объединении.

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

• Интерфейс для пользователя. Вся эта логика была реализована в специальном ресурсе. Слева — список групп дублей с фильтрацией и приоритизацией. Справа — поля записей, часть из которых уже преселектирована по правилам. Сверху — скор и AI Reason. Пользователь может согласиться с предложениями системы или выбрать свой вариант, после чего нажимает Apply/Merge.

Заключение

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

Ключевой вывод: думать об этом нужно с первого дня проектирования системы. Чем позже вы займётесь этим вопросом — тем дороже обойдётся его решение. Зато грамотно выстроенная архитектура валидации в сочетании с AI-анализом и скоринговыми моделями позволяет не только навести порядок в данных, но и постепенно перейти к полной автоматизации процесса — освобождая команду для действительно важных задач.