Поиск дублей в CRM через n8n: как навести порядок и не склеить разных клиентов

MAATRIX · 17 октября 2026 · 8 мин чтения

В понедельник Анна оставила заявку с рабочего адреса, во вторник позвонила с мобильного, а в пятницу её коллега написал с общей почты отдела. CRM добросовестно создала три карточки. Можно объединить всё по совпавшей компании и получить красивую статистику. Можно заодно потерять различие между людьми, сделками и полномочиями. Чистота таблицы ещё не означает порядок в клиентской базе.

Поэтому автоматизацию лучше начинать с поиска кандидатов на объединение. n8n соберёт признаки, покажет совпадения и подготовит решение. Удалять карточки будет последним действием, а не первой реакцией на одинаковую фамилию.

Что считать дублем

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

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

Согласуйте с владельцем базы несколько примеров. «Иван Петров» и «И. Петров» с одинаковым личным телефоном — повод для проверки. Два человека с почтой sales@example.org — вполне нормальная ситуация. Совпадение пустых телефонов ничего не доказывает, хотя наивная группировка способна собрать из них самого популярного клиента компании.

Три результата вместо кнопки «очистить»

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

Для каждой пары сохраните идентификаторы исходных карточек, значения признаков, причину попадания в выборку и дату проверки. Пример объяснения: «Совпадает нормализованный телефон; имена различаются; у обеих карточек есть открытые сделки». Такая карточка полезнее безымянного процента уверенности.

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

Собираем первый проход в n8n

Создайте workflow с Manual Trigger. Для настройки используйте копию данных или тестовый набор без настоящих контактов. Доступ к CRM на первом этапе выдайте только на чтение: исследование дублей не требует разрешения удалять всю клиентскую историю.

Получите контакты штатным узлом вашей CRM либо HTTP Request. Поля и способ постраничной выгрузки берите из документации конкретного API. Сохраните исходный идентификатор, дату изменения, контактные данные и необходимые ссылки на связанные объекты. Не выгружайте документы и переписку, если для сравнения они не нужны.

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

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

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

Почему Remove Duplicates не решает задачу целиком

В n8n есть узел Remove Duplicates. Он умеет отбрасывать повторяющиеся элементы текущего входа и учитывать историю прошлых выполнений. Это удобно, например, когда API дважды вернул одну карточку в одной выгрузке.

Но удаление элемента из потока n8n не объединяет контакты в CRM и не переносит их сделки. Если отбросить одну строку по одинаковому телефону, оператор просто перестанет видеть часть доказательств. Для поиска дублей сохраняйте все исходные ID и собирайте группы, а не выбирайте случайного победителя.

Аналогично узел Merge соединяет потоки данных. Для сопоставления используйте устойчивые поля, а не позицию строки. После сортировки одна таблица легко перестаёт соответствовать другой, и объединение «первый с первым» начинает создавать удивительные биографии клиентов.

Что увидит сотрудник

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

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

Особое внимание уделите ответственному, правам доступа, согласиям, подпискам и связанным обращениям. Нельзя переносить разрешение на рассылку с одного контакта на другой только потому, что совпал телефон. Если корректное объединение этих сущностей не поддерживается API, оставьте действие сотруднику в штатном интерфейсе CRM.

Отправлять в чат можно уведомление о готовой группе, но сам разбор лучше проводить там, где контролируются доступ и история решений. Список телефонов в общем Telegram-чате удобен ровно до момента, когда становится понятно, сколько людей этот чат читает.

Объединение с возможностью разобраться в последствиях

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

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

Запишите план слияния и результат в журнал: кто подтвердил, какие карточки участвовали, что стало основной записью, какие ссылки вернул API. При потере ответа сначала проверьте текущее состояние CRM. Повтор операции вслепую может оказаться невозможным или затронуть уже изменённую основную карточку.

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

Как не получить дубли снова

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

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

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

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

После стабильного ручного запуска добавьте Schedule Trigger, установите часовой пояс и опубликуйте workflow. Частоту выбирайте по скорости изменения базы. Небольшой компании часто полезнее спокойный ежедневный разбор, чем непрерывный поток сомнительных предложений.

Для такого процесса с внешней CRM можно начать с VPS MAATRIX Uab Start: 2 vCPU и 4 GB RAM на поддерживаемой Ubuntu или Debian. Большие выгрузки и PostgreSQL потребуют измерения памяти и диска; обрабатывайте данные порциями. В MAATRIX доступен сервер с n8n, а срок хранения копий контактов и круг доступа задаёте вы.

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