Гарантия лучшей цены

Оставить заявку
Все материалы

WantLead

Автоматизация бизнеса: 3 проверки против дублей контактов

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

23 октября 2026 11 мин чтения Вартан Тахиев, основатель leadlife
Автоматизация бизнеса: 3 проверки против дублей контактов

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

Новый звонок не всегда означает новый контакт

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

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

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

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

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

Отдельно разбираем задачу отслеживания звонков с сайта.

Перед передачей продавцу нужны 3 разные проверки

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

| Что проверять | Какую ошибку ищем | Что поручить настройщику |

|---|---|---|

| Формат телефона | Пробелы, скобки и код страны скрывают совпадение | Сравнивать телефоны после приведения к единому виду |

| Клиентскую карточку | Знакомый номер создаёт ещё одного «нового» | Искать существующую запись до создания новой |

| Номер события | Одно уведомление обработано повторно | Запоминать уникальный код события вместе с источником |

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

Например, документация Calltouch об обмене с Microsoft Dynamics разделяет код звонка, телефон клиента и отслеживаемый номер компании. Там же предусмотрена передача сведений в начале и в конце разговора. Если обработчик создаёт карточку на каждое сообщение без учёта фазы и кода звонка, такое поведение надо исправлять в настройке обмена.

Если вы добавляете к звонкам телефоны посетителей, ушедших без заявки, начните со схемы поступления этих записей.

Телефоны сравнивают после приведения к единому виду

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

В настройках Calltouch прямо указано требование передавать телефоны в едином формате для определения уникальности. Настройщику стоит проверить не только удаление пробелов, но и код страны, добавочный номер, пустые значения и ошибочные записи. Зарубежные номера нельзя исправлять по правилам российских.

Условная ситуация для проверки в октябре 2026 года: поставщик оборудования получает запись из сервиса посетителей, а затем входящий звонок с того же личного телефона. Номер в первом источнике записан со скобками, во втором без разделителей. После приведения к общему виду настройка должна найти совпадение и предложить существующий контакт.

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

Для подготовки списка пригодится разбор проверки базы на пересечения.

Обращения сохраняются в истории, сделки разделяются по запросам

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

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

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

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

Новые контакты считают после сверки с клиентской базой

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

По данным LEADLIFE на 2 сентября 2026 года, 98% посетителей уходят без заявки. Ориентир из материалов компании нельзя выдавать за замер вашего сайта. Процент ничего не говорит о доле новых номеров после сверки с вашей историей и не задаёт ожидаемый результат подключения.

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

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

Общий телефон компании требует ручной проверки совпадений

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

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

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

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

Тестовый прогон проверяет повторную передачу и новый разговор

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

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

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

Команда заранее согласует правила отчёта и обработки исключений

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

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

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

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

Источники

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

  • Типы звонков и период уникальности в Calltouch, редакция от 19 октября 2026 года.
  • Единый формат телефона и проверка повторов между звонками и формами в Calltouch, справка от 20 октября 2026 года.
  • Поля звонка и клиента при обмене Calltouch с Microsoft Dynamics, обновлено 21 октября 2026 года.
  • amoCRM: обработка повторяющихся записей при импорте, проверено 22 октября 2026 года; дата обновления на странице не указана.
  • Битрикс24: объединение дубликатов и выбор сохраняемых полей, обновлено 23 июля 2026 года.

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

Цифры и формулировки - из практики и базы знаний LEADLIFE. Кейсы отражают результаты конкретных клиентов и не являются гарантией аналогичного результата.

Бесплатный разбор

Посчитаем, сколько клиентов вы теряете

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

Купи 3000 - получи 300 до 30.10.2026

Вартан ТахиевОснователь LEADLIFE

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

+7 910 050-01-00
ПозвонитьЗаявка