
ИИ помогает находить похожие карточки клиентов, сделки и контакты, которые могли случайно завести дважды. Безопасный сценарий — не сливать записи автоматически, а показать сотруднику подозрительную пару, объяснить совпадения и предложить вариант объединения. Начинать стоит с одного повторяющегося процесса и заранее определить, какие сведения можно анализировать. Изменения в рабочих данных лучше вносить только после подтверждения человеком.
Коротко — и что с этим делать
Выберите небольшой участок CRM, например поиск дублей контактов. Зафиксируйте, сколько времени уходит на проверку и сколько ошибок или потерь возникает сейчас. Настройте помощника так, чтобы он только находил подозрительные записи и предлагал объединение, а сотрудник проверял и подтверждал каждое изменение. Так можно проверить пользу на ограниченном объёме данных, не рискуя всей базой.
Записаться на бесплатный аудит →Две карточки одного клиента могут выглядеть как мелочь. Но если в одной записан телефон, во второй — электронная почта, а история обращений разделена между ними, сотрудник не видит полной картины. Он может повторно уточнять уже известные сведения, пропустить договорённость или отправить предложение не тому человеку. В автосервисе это, например, затрудняет поиск истории обслуживания по номеру телефона; в клинике — мешает сотрудникам быстро найти нужную запись клиента.
Дубли появляются по разным причинам: сведения вводят вручную, клиент обращается через несколько каналов, в CRM загружают таблицу или меняют формат номера телефона. Даже разные написания имени или опечатка в адресе могут помешать обычному поиску. При этом похожие записи не всегда означают, что перед нами один и тот же человек. У членов семьи может быть общий номер, у компании — несколько контактных лиц, а один клиент может оставить разные адреса для связи.
Поэтому задача ИИ — не решить за бизнес, какую запись удалить, а помочь быстрее заметить возможную связь. Система сравнивает доступные поля, оценивает совпадения и выносит пару записей на проверку. Удалять или объединять их без подтверждения нельзя: ошибочное действие способно стереть важную историю, нарушить связь со сделкой или сделать данные менее точными.
Начните с одного повторяющегося процесса, а не с генеральной уборки всей CRM. Выберите тот участок, где сотрудники регулярно тратят время на ручной поиск: например, проверяют новые контакты перед созданием карточки или разбирают списки после импорта. Чем уже задача, тем проще описать правила и сравнить результат до и после запуска.
До настройки зафиксируйте, какие поля доступны для проверки и откуда они поступают. Для поиска дублей могут понадобиться имя, телефон, электронная почта и дата обращения, но не обязательно передавать заметки о здоровье, содержимое переписки или сведения о платежах. Объём данных должен соответствовать конкретной задаче. Если для сопоставления достаточно нескольких полей, остальные не следует включать «на всякий случай».
Затем договоритесь, что считается подозрительным совпадением. Например, одинаковый телефон и близкое написание имени могут стать поводом показать записи сотруднику, но не основанием для автоматического слияния. Совпадение только по имени обычно недостаточно. В правилах можно предусмотреть несколько уровней: явное совпадение, вероятное совпадение и слабое сходство, которое не требует внимания.
Для первого этапа полезно сохранить прежний порядок работы: помощник формирует список пар, показывает, по каким признакам они похожи, и предлагает сотруднику варианты — подтвердить, отклонить или отложить проверку. Так команда видит, какие ошибки система находит и где правила нужно уточнить. Подходы к внедрению ИИ в отдельные процессы мы описываем на странице услуг KM2B.
Обычная проверка ищет точные совпадения: например, одинаковый номер телефона. Более гибкий поиск может учитывать различия в написании, пробелы, тире, порядок имени и фамилии, распространённые сокращения. Система не просто сообщает «дубль», а оценивает несколько признаков и формирует повод для проверки. Конкретные правила зависят от того, какие поля ведёт компания и как именно сотрудники заполняют CRM.
Результат должен быть понятным. Сотруднику важно увидеть две сравниваемые карточки, совпавшие и различающиеся поля, а также объяснение, почему система предлагает проверить именно эту пару. Если видно только итоговую метку без оснований, проверяющему сложнее принять решение и заметить ошибку. Возможность отклонить предложение не менее важна, чем сама рекомендация.
После подтверждения объединение должно сохранять нужные связи: историю обращений, сделки, задачи, примечания и сведения о том, кто внёс изменение. Перед запуском стоит проверить, как CRM ведёт себя при слиянии карточек и можно ли отменить операцию. Если отмена недоступна, на первом этапе можно ограничиться рекомендациями без изменения исходных записей.
Важно различать очистку данных и изменение бизнес-решений. Помощник может указать на две похожие карточки, но он не должен самостоятельно менять сумму сделки, предоставлять скидку, назначать права доступа или отправлять клиенту обещание от имени компании. Эти действия должны оставаться под контролем сотрудника.
| Подход | Что делает система | Риск ошибки | Когда уместен |
|---|---|---|---|
| Точное совпадение | Показывает записи с одинаковым значением выбранного поля | Может пропустить дубль с опечаткой или изменённым номером | Для первого простого правила, например поиска одинаковой электронной почты |
| Поиск похожих записей | Сравнивает несколько полей и выделяет вероятные совпадения | Может предложить объединить карточки разных людей | Когда сотрудник проверяет каждую пару до изменения данных |
| Автоматическое объединение | Меняет записи без проверки человеком | Высокий: ошибку можно не заметить сразу, а история может быть нарушена | Только для узкого сценария с проверенными правилами и возможностью восстановления |
При работе с клиентскими сведениями учитывайте требования 152-ФЗ о персональных данных. Определите, кто отвечает за обработку, какие данные нужны для задачи, где они хранятся и кому доступны. Не стоит передавать полную выгрузку CRM в сторонний сервис, пока компания не проверила условия обработки и не убедилась, что такой способ соответствует её правилам и требованиям закона.
Практически это означает, что для поиска повторов можно выделить ограниченный набор полей и небольшой тестовый массив. Доступ к нему получают только сотрудники, которым он нужен для проверки. Полезно заранее установить срок хранения промежуточных файлов и удалить их, когда проверка завершена. Если задача затрагивает особые категории сведений, например информацию о здоровье, требования к выбору данных и их защите нужно оценить отдельно.
Ограничьте не только сведения, но и полномочия системы. На этапе проверки помощник может читать нужные поля и готовить рекомендацию, но не удалять записи, менять права пользователей или запускать рассылку. Деньги, скидки, договорённости и обещания клиенту, а также необратимые изменения оставляйте на одобрение сотрудника. Это не формальность: одна неверно объединённая карточка может повлиять на обслуживание, расчёт и дальнейшее общение.
Если система всё же вносит изменения после подтверждения, сохраняйте журнал: кто одобрил действие, когда оно произошло, какие записи были затронуты и как восстановить прежнее состояние. Резервная копия и понятный способ отмены помогают не только исправить ошибку, но и спокойно разобраться, почему она возникла.
Проверьте задачу до подключения к рабочей базе
На бесплатном аудите можно обсудить, какой процесс выбрать первым, какие поля действительно нужны и где оставить обязательное подтверждение сотрудника. Мы поможем оценить, подходит ли вашей CRM пробный запуск без автоматического изменения карточек.
Бесплатный аудит за 30 минут →Чтобы оценить результат, измерьте исходное состояние до запуска, а не после. Выберите показатели, которые можно одинаково посчитать в обеих точках: сколько минут сотрудники тратят на поиск дублей, сколько подозрительных пар они проверяют, сколько подтверждённых повторов обнаруживается и сколько ошибочных предложений приходится отклонять. Если компания уже учитывает потери из-за разрозненных карточек, зафиксируйте и их, но не приписывайте каждое изменение только ИИ.
После запуска повторите измерение на сопоставимом объёме данных и за тот же период. Если до пилота проверяли входящие контакты в течение двух недель, сравните с таким же участком работы после настройки. Отдельно оцените нагрузку на сотрудников: иногда система находит много возможных совпадений, но почти все требуют отклонения. В таком случае правила сопоставления нужно улучшить, а не считать большой список предложений успехом.
Для оценки пользы можно учитывать сэкономленное время и снижение числа подтверждённых ошибок. При этом важно включить стоимость настройки, проверки и дальнейшего сопровождения. Точная цена зависит от используемой CRM, качества данных, объёма интеграций и требований к безопасности, поэтому её определяют после аудита. Начинать обычно разумно с недорогого пилота на узком участке; окупаемость пилота часто оценивают в диапазоне 2–4 месяцев, но фактический срок зависит от исходной нагрузки и результата измерений.
Не ограничивайтесь числом найденных дублей. Запишите, сколько предложений оказалось верными, сколько было ошибочными и сколько времени ушло на подтверждение. Такой набор показателей помогает понять, приносит ли процесс пользу именно вашей команде. Примеры решений для разных задач бизнеса можно посмотреть в каталоге продуктов KM2B, а подход к оценке экономического эффекта — на странице расчёта окупаемости.
Первая ошибка — сразу разрешить массовое слияние. Даже хорошие правила могут неверно связать записи из-за общего номера, семейной электронной почты или неполных данных. Сначала проверяйте предложения вручную. Автоматическое действие можно обсуждать только после того, как на ограниченной выборке понятны причины ошибок и предусмотрено восстановление.
Вторая — пытаться исправить качество всей базы одним запуском. В карточках могут быть разные форматы, устаревшие контакты, пустые поля и собственные особенности подразделений. Если не определить приоритет, команда получит длинный список замечаний без ясного порядка действий. Лучше выбрать один источник дублей, например импортированные контакты, и проверить его отдельно.
Третья — считать, что совпадение двух полей всегда доказывает тождество клиента. Имя и телефон могут быть общими, телефон может перейти другому владельцу, а адрес электронной почты — измениться. Поэтому система должна показывать основания для сравнения, а сотрудник — учитывать контекст и историю взаимодействий.
Наконец, опасно забывать о правилах после пилота. Новые поля и этапы работы могут изменить качество сопоставления. Назначьте ответственного за проверку рекомендаций, пересматривайте правила при заметных изменениях процесса и сохраняйте понятную инструкцию для сотрудников. Тогда очистка данных станет управляемой задачей, а не разовой операцией, после которой никто не знает, что именно изменилось.
Для небольшого бизнеса последовательность может быть такой:
Если предложения часто оказываются ошибочными, не нужно сразу подключать больше данных. Сначала проверьте, какие признаки дают ложные совпадения, и уточните правила. Если система находит полезные пары, но сотрудникам сложно разбирать результат, улучшите отображение различий и порядок подтверждения. Расширять задачу стоит только после того, как команда понимает, что именно помощник делает и как исправить его ошибку.
Главный принцип прост: ИИ помогает быстрее заметить возможный беспорядок, но не получает безусловного права менять клиентскую базу. Для старта достаточно одного участка, ограниченного набора сведений и человека, который проверяет результат. Такой подход позволяет измерить пользу, сохранить контроль над данными и не превращать очистку CRM в рискованную массовую операцию.
Нужен безопасный первый шаг?
Команда KM2B поможет выбрать процесс для пилота, определить границы доступа к данным и подготовить измеримые критерии проверки. Начнём с аудита задачи и обсудим, как оставить решение об изменении CRM за вашим сотрудником.
Записаться на бесплатный аудит →