Помочь применить это руководство?Спросить команду DripTell
Клиент задает вопрос в Instagram, утром возвращается в WhatsApp, а позже отправляет форму с рабочей почтой. Если каждый новый диалог создает лид, один человек превращается в три записи еще до первого ответа продавца.
Решение начинается с проверки личности до создания записи. Нормализуйте надежные идентификаторы, найдите существующий контакт или лид, привяжите новый разговор при точном совпадении, а сомнительные пары отправьте на короткую ручную проверку. Новый лид нужен только тогда, когда есть достаточно оснований считать человека или покупательскую задачу новыми.
Сначала определите человека
Разговор, контакт, лид и возможность означают разное. Разговор является взаимодействием. Контакт представляет человека. Лид отражает потенциальную работу для продаж, а возможность представляет сделку, которую стоит развивать. Если каждое взаимодействие становится новым лидом, владение, последующие действия и отчеты быстро теряют смысл.
- 1Сохраните взаимодействиеЗапишите входящее событие и источник до решения о новом лиде.
- 2Нормализуйте данныеПриведите телефон и почту к единому виду, сохранив исходные значения.
- 3Найдите существующееПроверьте контакты, активные лиды и связанную историю до создания.
- 4Выберите один исходПрисоедините точное, проверьте сомнительное, создайте только явное новое.
- 5Проверьте результатПосле объединения проверьте владельца, согласие, действия и автоматизацию.
Начинайте с идентификаторов, которые предоставил сам клиент. Для WhatsApp это может быть телефон в нормализованном международном формате. Для формы это может быть подтвержденная электронная почта. Идентификатор Instagram полезен внутри канала, но нельзя без подтверждения считать его тем же человеком, который известен по телефону или почте.
Нормализуйте данные до сравнения. Уберите различия в оформлении номера, приведите регистр электронной почты к одному виду, но сохраните исходное значение для аудита. Не сопоставляйте только по отображаемому имени. Имена повторяются, семья может использовать общий телефон, а корпоративный ящик может принадлежать нескольким людям.
Microsoft объясняет, что правила обнаружения дублей сравнивают коды, построенные по полям вроде электронной почты, имени и фамилии. Компания также предупреждает, что записи, обработанные одновременно, все равно могут дублироваться, и рекомендует периодические задания как второй уровень проверки в документации по обнаружению дублей. Это важно, когда несколько каналов создают записи параллельно.
Поэтому единый входящий ящик должен передавать данные в одно решение об идентичности, а не создавать отдельного клиента для каждого канала.
Используйте три исхода сопоставления
Бинарное правило выглядит удобно. Запись либо есть, либо ее нет. На практике данные сложнее, поэтому нужны три исхода.
Точное совпадение позволяет добавить разговор к существующей записи. Возможное совпадение должно ждать проверки без запуска нового обращения. Явное отсутствие совпадения позволяет создать запись, сохранив источник и подтверждение согласия.
| Исход | Пример доказательства | Безопасное действие | Состояние работы |
|---|---|---|---|
| Точное совпадение | Одинаковый подтвержденный телефон или адрес после нормализации | Добавить разговор к существующему контакту и активному лиду | Сохранить владельца и следующее действие |
| Возможное совпадение | Похожее имя и компания при различии одного идентификатора | Отправить на ручную проверку | Не запускать вторую цепочку |
| Совпадения нет | Разные надежные идентификаторы и нет связанной истории | Создать новый контакт или лид | Назначить одного владельца |
| Общий идентификатор | Семейный телефон или общий рабочий ящик | Хранить людей отдельно с явной связью | Подтвердить личность до персонального обращения |
Это операционная политика, а не универсальная формула. Надежность идентификатора зависит от канала и отношений с клиентом. Запишите правило, проверьте его на реальных пограничных случаях и показывайте проверяющему причину решения.
Сопоставление должно происходить до квалификации лида. Квалификация отвечает, стоит ли развивать потребность. Дедупликация сначала выясняет, существует ли запись.
Не дайте двум автоматизациям создать две записи
Поиск перед созданием необходим, но не достаточен. Два события могут одновременно не найти запись, а затем создать по копии. Такое случается, когда клиент отправляет форму сразу после сообщения или webhook повторяет доставку события.
Назначайте каждому входящему событию ключ идемпотентности, чтобы повтор не создавал работу снова. Если правила бизнеса позволяют, обеспечьте уникальность нормализованного сильного идентификатора. Финальный поиск и создание выполняйте как одну контролируемую транзакцию. Если другая операция успела создать запись, присоедините разговор к ней.
Сохраняйте событие канала даже без нового лида. Клиент действительно связался снова, и это часть истории. Такой контроль отличается от предотвращения повторных исходящих сообщений, хотя оба механизма должны работать вместе.
Сервис сопоставления не должен отправлять кампанию, назначать продавца или двигать стадию. Он только разрешает идентичность и передает одну запись следующему процессу.
Объединяйте записи без потери контекста
Дубли появляются из импорта, ручного ввода, смены номеров и старых интеграций. Выберите основную запись по опубликованному правилу. Сохраните первый источник, актуальное согласие, историю разговоров, открытые задачи, активную возможность, владельца и следующее действие. Перед объединением остановите пересекающиеся автоматизации, затем убедитесь, что второй follow-up не остался запланированным.
Microsoft пишет, что при объединении основная запись сохраняется, вторичная деактивируется, а выбранные данные, заметки и действия привязываются к основной записи в руководстве по объединению. Возможности зависят от типа записи и пути создания, поэтому проверяйте именно свои формы, импорты и интеграции.
Не объединяйте сомнительную пару автоматически только из-за похожего имени. Ошибка может открыть чужую историю, направить продавца не тому человеку или заменить правильное решение о согласии.
Измеряйте процесс по источникам
Считайте дубли отдельно для форм, импорта, WhatsApp, Instagram, ручного ввода и API. Отслеживайте автоматически присоединенные точные совпадения, ручные проверки, ложные совпадения, пропущенные дубли и время ожидания проверки.
Проверяйте последствия. Связались ли два продавца с одним человеком? Перезапустилась ли цепочка после объединения? Изменился ли уровень квалификации, потому что дубли вошли в знаменатель или были удалены? Чистая таблица еще не означает исправный процесс.
Полезная модель CRM и лидов хранит источник, согласие, владельца, стадию и следующее действие в одной истории клиента. Тогда процесс продаж может продолжаться без просьбы повторить уже рассказанное.
Еженедельно проверяйте выборку решений и улучшайте правила на основе ошибок. Цель не в отсутствии предупреждений, а в одном ответственном решении для каждого реального человека и покупательской задачи.
Часто задаваемые вопросы
Всегда ли один номер означает одного клиента
Нет. Это сильный сигнал, но бывают семейные и общие телефоны, переназначенные номера и ошибки ввода. При сомнении учитывайте отношения и проводите проверку.
Нужен ли новый лид вернувшемуся клиенту
Не только из-за нового разговора. Создавайте новую работу продаж, когда появилась отдельная потребность или возможность, а человека и историю сохраняйте в существующем контакте.
Можно ли искать дубли после назначения
Можно, но это поздно. Второй владелец или автоматическая цепочка уже могли начать работу. Сильнейшая проверка должна происходить до создания и назначения, а периодические задания ловят пропуски.
Что делать с неясным совпадением
Поместите его в очередь с назначенным проверяющим, доказательствами и сроком. Не объединяйте записи, не запускайте второе обращение и не теряйте разговор до решения.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники