Как избежать дублей клиента в CRM из разных каналов

Пример расчёта (условные цифры): клиент сначала пишет в Telegram, а вечером оставляет телефон на сайте. Если CRM создаёт две независимые карточки, два менеджера могут одновременно отправить разные предложения. На БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ можно разобрать, какие признаки совпадения доступны именно в ваших каналах.

Канал знает клиента по своему идентификатору. Сайт может передать телефон и электронную почту, Telegram - идентификатор аккаунта, WhatsApp - номер, но доступный набор данных зависит от интеграции и согласия человека. При первом обращении система часто не может доказать связь между этими записями. Это нормальная неопределённость, а не ошибка, которую нужно скрыть автоматическим склеиванием.

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

Вопрос к вам: по какому признаку ваша CRM сейчас считает два обращения принадлежащими одному человеку?

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

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

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

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

Пример расчёта (условные цифры): из 100 обращений 12 могут иметь похожее имя, но лишь 5 подтверждённый общий контакт. Автоматическое объединение всех 12 сэкономит несколько ручных проверок и создаст риск семи ошибочных связей. Эти числа иллюстрируют логику, не прогноз для вашего бизнеса.

Запишите, что является контактом, обращением, заказом и диалогом. Настройте связи так, чтобы новый запрос знакомого клиента не пропадал в старой закрытой сделке.

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

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

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

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

Объединение только по подтверждённому признаку. Плюсы: меньше ошибочного доступа к чужой истории. Главный риск: часть дублей останется и потребует ручной разбор. Это разумная стартовая настройка для чувствительных данных.

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

Такая таблица нужна и разработчику, и владельцу процесса. Лайфхак: в карточке показывайте не только итог «совпадение», но и основание: какой идентификатор совпал и когда он был подтверждён.

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

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

Защита от дублей влияет на воронку, задачи менеджеров и аналитику источников. В A3bot можно выстроить передачу данных в CRM так, чтобы неопределённые совпадения проверял человек. Стоимость зависит от каналов и устройства текущей базы.

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

Напишите, какой процесс хотите автоматизировать: A3bot