Дубли заявок в CRM: как ИИ помогает соединить историю клиента

Команда KM2B · 12 октября 2026 · чтение ~7 минут

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

Коротко — и что с этим делать

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

Записаться на бесплатный аудит →

Почему дубли заявок мешают работе

Повторная заявка может появиться по простой причине: клиент позвонил, затем оставил форму на сайте, а позже написал в Telegram или MAX. Дубль возникает и тогда, когда менеджер заводит запись вручную, а другая заявка автоматически поступает из формы. Для клиента это один разговор и одна потребность, для компании — несколько карточек с разрозненными сведениями.

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

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

Как определить вероятный дубль по нескольким признакам

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

Телефон. Сравнивать номера можно после приведения к единому формату. Совпадение важно, но общий семейный или рабочий номер не доказывает, что речь об одном человеке.
Имя и фамилия. Система может учитывать опечатки, сокращения и разные варианты написания. Одно только совпадение имени — слабое основание для объединения.
Электронная почта. Совпадающий адрес — полезный сигнал, но его тоже стоит сопоставлять с другими данными и обстоятельствами обращения.
Содержание обращения. Похожая услуга, адрес объекта или описание задачи помогают оценить совпадение, но текст может быть общим или скопированным.
Время и канал связи. Несколько обращений за короткий период из разных каналов могут относиться к одному запросу. Большой промежуток времени, наоборот, может указывать на отдельную потребность.
История действий. Совпадение договора, номера заказа или уже состоявшейся встречи может усилить предположение — если эти сведения действительно нужны для проверки.

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

Признак	Чем полезен	Что проверить перед объединением
Совпадающий телефон	Помогает быстро найти повторное обращение	Не является ли номер общим или рабочим
Похожее имя	Учитывает опечатки и варианты написания	Есть ли совпадения по другим полям
Похожая тема заявки	Связывает обращения об одной услуге или задаче	Не является ли описание типовым
Близкое время и разные каналы	Помогает обнаружить повторную отправку	Не появились ли у клиента новые обстоятельства
Номер заказа или договора	Может подтвердить связь с существующей историей	Принадлежат ли документы именно этому клиенту

Что ИИ делает, а что остаётся за сотрудником

В рабочем процессе ИИ не обязательно сразу меняет данные в CRM. Более осторожный вариант — искать пары, присваивать им уровень уверенности и создавать очередь на проверку. Сотрудник видит основания для рекомендации и принимает решение: объединить карточки, отклонить совпадение или запросить уточнение.

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

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

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

Проверьте процесс до внедрения

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

Бесплатный аудит за 30 минут →

С чего начать пилот по поиску дублей

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

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

У пилота должны быть понятные границы: конкретный тип заявок, ответственный сотрудник и срок оценки. Это снижает нагрузку на команду и позволяет отказаться от неподходящего сценария до того, как он затронет все клиентские данные. Небольшой пилот обычно проще оценить и по затратам; ориентир по окупаемости пилота часто составляет 2–4 месяца, но фактический срок зависит от объёма дублей, цены ошибок и стоимости внедрения. Точную стоимость можно определить после аудита.

Как проверить пользу и не перепутать эффект с впечатлением

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

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

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

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

Какие данные и действия ограничить

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

Если используются персональные данные, до запуска проверьте, на каком основании компания их обрабатывает, кто получает к ним доступ, где они хранятся и как удаляются. Требования 152-ФЗ необходимо учитывать в процессе обработки, а не добавлять задним числом. Важно также выяснить, передаются ли данные внешнему поставщику и какие меры защиты предусмотрены договором и настройками решения.

Ограничьте права доступа по ролям. Сотруднику, который проверяет совпадения, может быть достаточно имени, телефона, даты и темы обращения; полный доступ к финансовым сведениям ему не нужен. Зафиксируйте, кто подтвердил объединение и можно ли восстановить прежние записи. Для сообщений клиентам учитывайте применимость требований 38-ФЗ: найденный дубль сам по себе не является согласием на рекламную рассылку.

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

Как встроить поиск дублей в ежедневную работу

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

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

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

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

Источники

Сайт KM2B — информация о компании и направлениях работы.
Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».
Федеральный закон от 13.03.2006 № 38-ФЗ «О рекламе».

Начните с одного участка

Команда KM2B поможет описать процесс, определить безопасный набор данных и подготовить пилот с проверкой сотрудником. На аудите обсудим, как измерить время обработки, ошибки и потери до и после запуска.