Человек обратился дважды — и теперь он в базе дважды на обоих уровнях: два контакта с одним номером и две сделки, у каждой своя половина истории. Менеджер открывает одну карточку и не видит, что месяц назад клиенту уже отказали. Отчёт считает двух человек там, где он один, и конверсия занижена.
В большинстве CRM есть своё «объединение дублей». Проблема не в том, что оно плохое, а в том, что оно решает лёгкую половину задачи и не учитывает, что контакты и сделки дублируются по-разному.
#Чем дубль контакта отличается от дубля сделки
Контакт — это человек. Если один и тот же номер и одна и та же почта записаны в двух карточках, это всегда ошибка: один человек должен быть одной карточкой. Вопрос тут только в том, как аккуратно слить.
Сделка — это обращение. Один и тот же клиент мог купить трижды — это три настоящие сделки, и сводить их в одну нельзя. Дубль сделки — это когда одно обращение распалось на две записи: заявку создал бот, а через минуту её же создала форма; менеджер завёл сделку вручную, не увидев, что интеграция уже завела свою.
Поэтому и правила разные. Контакты можно сверять по всей базе за всё время. Для сделок совпадение телефона ещё ничего не значит — нужно правило, которое отделяет повторную покупку от дубля. У нас таким правилом работает пара «та же воронка + небольшой промежуток времени»; где провести границу у вас — зависит от того, как часто клиенты действительно возвращаются.
#Почему сначала контакты, а потом сделки
Сделка держится на контакте. Пока человек живёт в двух карточках, каждая интеграция — бот, форма, телефония — цепляет новые сделки к «своей» из них, и пара продолжает расходиться. Объедините сделки, а контакты оставите — и через неделю на том же месте появятся новые дубли.
Порядок фиксирован: сначала «один человек — одна карточка», потом разбор его сделок. После слияния контактов часть дублей сделок найдётся сама — они окажутся рядом, в одной карточке, и их станет видно.
#Что переносить в мастер-карточку
Поиск дублей сводится к совпадению по телефону или почте — это просто. Сложное начинается дальше: в двух карточках лежат разные данные, и вопрос не в том, какую оставить, а в том, как не потерять ничего из обеих.
Для контакта это как минимум: все телефоны и почты (второй номер становится дополнительным, а не исчезает), теги, подписки, комментарии и ответственный менеджер.
Для сделки — вот что лежит во второй карточке и что мы переносим в мастер:
| Что переносим | Почему это важно |
|---|---|
| Комментарии | Половина контекста сделки — в переписке менеджеров, а не в полях |
| Атрибуты | Источник, кампания, любые пользовательские поля |
| Контакты | В одной сделке может быть телефон, во второй — почта |
| Задачи | Запланированные звонки и напоминания исчезают вместе с дублем |
| Звонки | История коммуникации |
| Файлы | Договоры, счета, скриншоты |
| Дедлайн и сумма | Иначе суммы в отчётах не сойдутся |
Мастер — это самая старая карточка, а не последняя. И для контакта, и для сделки так сохраняется настоящая дата первого обращения, а вместе с ней — правильная воронка.
#Почему одного триггера мало
Кажется логичным запускать проверку по событию «запись создана». Но именно в этот момент в карточке часто ещё нет ни телефона, ни почты — их дописывает бот, менеджер или следующая форма через несколько минут или дней.
Так бывает регулярно: сделка приходит совсем без контактов, искать совпадение не по чему, и встроенное объединение её тоже не видит. Её пара тем временем может лежать в базе уже неделю.
Поэтому триггеров три:
- событие «запись создана» — ловит очевидные случаи сразу;
- ежечасная проверка последних записей — ловит «телефон дописали в тот же день», обходится дёшево;
- полный скан раз в несколько часов — ловит «телефон дописали через неделю».
#Как искать совпадения по телефону
Здесь прячется ошибка, из-за которой сведение дублей либо не находит ничего, либо находит лишнее.
Сначала проверьте, как ваша CRM ищет по телефону. Часть систем нормализует номер перед поиском, часть ищет подстрокой — то есть фактически LIKE по цифрам. Во втором случае:
+380 67 123 45 67и380671234567— это разные строки, и поиск их не свяжет;- зато подстрока даёт ложные совпадения: по
client@example.comнайдётся иxclient@example.com.
Поэтому ключом группы делают последние девять цифр номера. Код страны, плюс и пробелы перестают влиять. Каждого найденного кандидата нужно проверить ещё раз: вытащить его контакты и оставить в группе, только если там действительно есть такой хвост номера или ровно такая же почта.
У контакта телефонов может быть несколько — сравнивать нужно каждый с каждым, а не «основной с основным»: дубль как раз и возникает тогда, когда в одной карточке номер записан первым, а во второй — дополнительным.
Группы по телефону и по почте нужно объединять в одну. Иначе одного и того же человека сведут в два разных мастера, и часть данных попадёт не в ту карточку. Цепочку карточка 1 — телефон — карточка 2 — почта — карточка 3 сводят целиком: все три — в самую старую.
#Когда дубль нельзя удалять
Удаление должно быть отдельным шагом, а не частью общего списка операций. Если перенос комментариев не прошёл, а DELETE стоит в конце того же списка, он всё равно выполнится — и данные исчезнут.
Порядок должен быть такой:
- выполнить все переносы;
- проверить статусы: если хоть одна операция не прошла — дубль не трогать вообще;
- удалить только те дубли, из которых всё перенесено чисто.
С контактами нужна отдельная осторожность: если CRM связана с мессенджером, карточка может держать на себе диалог. Прежде чем удалять контакт-дубль, проверьте на одной паре, что случится с перепиской — она должна переехать в мастер, а не исчезнуть.
Защиту проверяют так же, как и перенос: подставляют заведомо нерабочий адрес для одного из шагов и смотрят, остались ли дубли целыми и появилась ли в отчёте строка об ошибке.
#Зависит ли это от конкретной CRM
Логика не зависит от продукта — меняются адреса методов и названия полей. Перед началом стоит проверить одно: даёт ли API доступ к комментариям, задачам и файлам, а не только к полям карточки. Если нет, автоматическое сведение потеряет ровно то, ради чего его делают.
#Выводы
- Дубль контакта — всегда ошибка; дубль сделки — только когда одно обращение распалось на две записи.
- Порядок фиксирован: сначала контакты, потом сделки — иначе дубли сделок будут возвращаться.
- Мастер — самая старая карточка, чтобы сохранить настоящую дату первого обращения.
- Переносить нужно всё, включая комментарии, задачи и файлы.
- Одного триггера мало: телефон часто дописывают после создания записи.
- Если поиск по телефону работает подстрокой, нужны последние девять цифр и повторная проверка кандидатов; у контактов номера сравнивают каждый с каждым.
- Удаление — отдельный шаг после успешного переноса. Дубль с платежом не удаляют, пока не убедитесь, что платёж можно перенести.
#Частые вопросы
#Достаточно ли встроенного объединения дублей в CRM?
Для простых случаев да — но сначала проверьте, что именно оно переносит. Поля сводят все, а комментарии, задачи и файлы — не все, и как раз в них лежит контекст. Если история коммуникации для вас важна, а встроенное объединение её не сохраняет, нужно отдельное решение.
#Можно ли объединять контакты полностью автоматически?
В большинстве случаев да, если сливать только пары с несколькими совпадениями — например, телефон и почта или телефон и то же имя. Пары с единственным общим номером оставляйте на ручной разбор: за одним номером могут стоять двое разных людей.
#Что делать, если в обеих сделках есть платежи?
Проверьте, есть ли у вашей CRM метод для переноса платежа. Если есть — переносите вместе со всем остальным. Если нет, такие пары не объединяют автоматически: их помечают и разбирают вручную.
#Как часто запускать проверку?
Каждый час проверяйте записи за последние сутки, а раз в несколько часов делайте полный скан. Первое дёшево ловит свежие дубли, второе — те, у которых контакт появился позже.