Две похожие карточки клиента ещё не дают основания объединять сделки и историю общения. Для первого пилота поручите ИИ-сотруднику подготовку очереди проверяемых предложений: какие записи похожи, чем подтверждается совпадение и какое изменение требуется. Решение принимает ответственный за данные, а запись в CRM проходит отдельную проверку.
Такой подход стоит сравнить со штатным поиском дублей и обычными правилами. Ниже — пример, по которому можно определить границы пилота, составить карточку согласования и проверить качество поиска.
Какие проблемы данных CRM стоит включить в первый пилот?
Выберите одну сущность и один тип ошибки: например, повторные регистрации компаний. Назначьте владельца справочника и заранее определите, когда две карточки должны оставаться отдельными. Контакты и связи с подразделениями проверяйте как связанные данные; самостоятельный поиск дублей людей можно выделить в следующий этап.
В исследовании Entity Matching using Large Language Models сопоставление сущностей определяется как проверка того, относятся ли два описания к одному реальному объекту. Для CRM к этому вопросу добавьте правило учёта: даже при общем юридическом лице филиалу может требоваться отдельная карточка.
Запишите границы пилота до настройки поиска:
| Параметр | Решение для первого пилота |
|---|---|
| Объект и ошибка | Компании; предполагаемые повторные регистрации |
| Владелец | Ответственный за клиентский справочник, который подтверждает правила учёта |
| Входные данные | Разрешённые реквизиты, подразделения, источники полей и доступные связи |
| Результат | Очередь пар с основаниями и предлагаемым действием |
| Исключения | Массовое объединение, финансовые изменения, удаление истории, сообщения клиентам |
| Условие остановки | Неизвестная сущность, спорный источник или недостаточные права |
Проверьте также, какие поля разрешено использовать и передавать выбранной модели. Для сопоставления не следует собирать всю доступную переписку «на всякий случай». Согласуйте необходимый состав данных и маршрут их обработки отдельно.
Где достаточно штатных правил CRM, а где стоит проверять ИИ?
Начните с нормализации формата и возможностей своей CRM. Например, Bitrix24 документирует автоматическое объединение дублей лидов, контактов и компаний. Наличие этой функции — повод проверить её условия и настройки в используемой системе до разработки собственного решения.
| Подход | Когда проверять | Ожидаемый результат и ограничение |
|---|---|---|
| Нормализация и точные правила | Заданы допустимые форматы и устойчивые признаки | Приведённые к одному формату значения и список совпадений; формат не подтверждает личность |
| Штатный поиск CRM | Функция доступна и соответствует правилам учёта | Найденные системой кандидаты; отдельно проверяются основания и последствия операции |
| Модельное сопоставление | После базовой проверки остаются неоднозначные пары | Рекомендация с объяснением; каждое основание нужно сверить с исходными данными |
Оценку сходства используйте для порядка рассмотрения, а не как вероятность безопасного объединения. Высокий балл не заменяет доказательства того, что записи относятся к одному клиенту, и не даёт разрешения менять CRM.
Авторы Entity Matching using Large Language Models указывают на необходимость настраивать промпт под сочетание модели и набора данных. Поэтому проверяйте выбранную конфигурацию на своей контрольной выборке. Результаты исследования сами по себе не устанавливают качество работы на вашей CRM.
Если правила уже дают нужный результат, а модель добавляет преимущественно ложные предложения или увеличивает время проверки, оставьте базовый вариант. Полезность ИИ нужно установить сравнением.
Почему одинаковое имя или телефон ещё не означают дубль?
Разберём клиентский справочник, где головная организация и филиал ведутся отдельно. Обстоятельства вымышлены; это не кейс клиента. LEGAL-A, BR-K и PERSON-A/B — условные обозначения примера, не реальные реквизиты и не обязательные поля любой CRM.
Во всех карточках указан общий телефон организации. Владелец данных подтвердил следующие обстоятельства:
| Карточка | Запись и признаки | Подтверждённое обстоятельство | Решение |
|---|---|---|---|
| C-101 | ООО Север; LEGAL-A; головная организация | Основная запись юридического лица | Использовать как базовую |
| C-102 | Север, ООО; LEGAL-A; подразделение не указано; опечатка в адресе | Повторная регистрация той же компании, отдельного назначения нет | Подготовить объединение после проверки полей и связей |
| C-103 | Север — Казанский филиал; LEGAL-A; BR-K | Филиал учитывается отдельно: свои договоры и ответственный | Сохранить и проверить связь с головной организацией |
| P-201 | Иван Петров; головная организация | Подтверждена личность PERSON-A | Сохранить |
| P-202 | Иван Петров; BR-K | Подтверждён другой человек, PERSON-B | Не объединять с P-201 |
| P-203 | И. Петров; подразделение неизвестно | Личность не установлена | Запросить уточнение, ничего не менять |
Для C-101/C-102 основание сильнее сходства названий: подтверждены повторная регистрация и отсутствие отдельного назначения. Но решение о сохранении конкретных значений и связанных данных ещё предстоит принять.
C-103 остаётся отдельной записью по заданным правилам учёта. Контакты P-201/P-202 сохраняются раздельно, поскольку владелец подтвердил разных людей. Одна лишь работа в разных подразделениях такого вывода не позволяет. У P-203 данных для решения недостаточно.
Как выбрать: исправить поле, связать карточки или объединить?
Сначала установите, что именно неверно. Исправление адреса меняет значение поля; нормализация приводит подтверждённое значение к согласованному формату; связь сохраняет отдельные записи; объединение требует выбора сохраняемых данных и проверки последствий.
| Установленное обстоятельство | Действие | Кто подтверждает и когда остановиться |
|---|---|---|
| Отличается только формат известного значения | Применить согласованное правило нормализации | Владелец поля утверждает правило; без него изменение откладывается |
| Ошибка в адресе подтверждена источником | Исправить адрес по этому источнику | Ответственный проверяет источник; при конфликте сведений нужно уточнение |
| Совпали имя или общий телефон | Отправить пару на проверку | Владелец данных устанавливает личность; без подтверждения записи сохраняются |
| Филиал учитывается отдельно | Проверить или добавить связь | Владелец справочника подтверждает модель учёта; при неясных правилах запись запрещена |
| Подтверждена повторная регистрация одной сущности | Подготовить план объединения | Ответственный согласует поля и связи; неизвестная судьба истории останавливает действие |
| Данные изменились после согласования | Перечитать предложение и текущие записи | Ответственный заново оценивает существенные изменения |
| Исход операции неизвестен | Сверить CRM и журнал | Исполнитель устанавливает результат до любого повтора |
Для каждого конфликтующего поля назначьте авторитетный источник. Самое новое или непустое значение не следует автоматически считать правильным: сначала установите, откуда оно получено и кто вправе его подтвердить.
Решение по паре также не разрешает объединить всю похожую группу. Если первая карточка похожа на вторую, а вторая — на третью, отдельно проверьте идентичность всей предполагаемой группы и её связи.
Что должен увидеть сотрудник перед подтверждением исправления?
Покажите исходные записи, подтверждения и точное предлагаемое действие рядом. Сотрудник должен иметь возможность проверить каждое основание, отклонить предложение или вернуть его на уточнение.
Продолжим вымышленный пример. Пусть у C-101 версия v7, у C-102 — v3. В первой записан адрес «ул. Полевая, 8», во второй — «ул. Полевя, 8». Запись владельца справочника в журнале проверки подтверждает повторную регистрацию компании; источник правильного адреса ещё нужно приложить.
| Поле записи очереди | Показанное содержание |
|---|---|
| Исходные записи | C-101/v7: ООО Север; C-102/v3: Север, ООО; обе содержат LEGAL-A |
| Основание | Запись владельца в журнале: одна компания, отдельного назначения у C-102 нет |
| Расхождение | «ул. Полевая, 8» и «ул. Полевя, 8»; опечатка установлена, источник сохраняемого адреса не приложен |
| Предлагаемые значения | Сохранить C-101, название «ООО Север», LEGAL-A и адрес «ул. Полевая, 8» после подтверждения источника |
| Связанные данные | Требуется сверить сделки, контакты, историю и внешние связи обеих карточек; полный состав ещё не подтверждён |
| Неизвестные последствия | Перенос каждой связи и возможности восстановления в используемой CRM не проверены |
| Текущее решение | Вернуть на уточнение; объединение не разрешено |
Это готовая запись очереди с конкретным следующим действием: приложить источник адреса, перечень связей и результат проверки восстановления. После этого ответственный сможет оценить точный план изменения.
Объяснение ИИ не становится отдельным доказательством. Сверяйте его с указанными записями и подтверждениями. Кнопка согласования должна относиться к показанным полям, связям и версиям; истечение времени ожидания не означает согласия.
Как внести подтверждённое изменение и проверить связи?
Вводите запись отдельным этапом после проверки очереди. Первый пилот можно закончить рекомендациями, сохранив только согласованный доступ на чтение. Для объединения нужен отдельный допуск к поддерживаемой операции CRM.
Перед выполнением используйте такую последовательность:
- Перечитайте обе карточки и связанные данные. Сравните их с состоянием, которое проверял ответственный.
- При существенных изменениях верните предложение на согласование. Не применяйте прежнее решение к новым реквизитам или связям.
- Проверьте полномочия исполнителя и допустимость операции средствами CRM или интеграции. Ограничения доступа должны исполняться вне модели.
- Сохраните доступный снимок исходных данных, точный план, подтверждение и запись в журнале. Заранее проверьте процедуру восстановления на тестовых данных.
- Выполните согласованное изменение и заново прочитайте результат. Сверьте сохраняемые поля, доступную историю, сделки, контакты и внешние связи.
- Если ответ операции потерян или неоднозначен, сначала установите фактическое состояние по CRM и журналу. До сверки повторную запись не выполняйте.
Границы операции зависят от продукта. Microsoft Learn прямо указывает: в описанном сценарии объединения записей с библиотекой документов SharePoint объединяются записи, но не сами библиотеки. Для пилота это основание отдельно включить внешние связи в проверку результата.
В документации Bitrix24 предусмотрено восстановление удалённых после автоматического объединения карточек из корзины CRM. Однако эта возможность сама по себе не подтверждает полный возврат всех прежних связей и внешних последствий. Определите требуемый результат восстановления и испытайте именно его.
Технические вопросы разграничения полномочий подробнее разобраны в материале «Права и контроль действий при интеграции ИИ с CRM».
Как оценить качество поиска дублей и решить, продолжать ли пилот?
Используйте полностью размеченную контрольную выборку, включая пары, которые система не предложила. Иначе можно оценить качество предложений, но нельзя посчитать пропущенные дубли. Для сравнения правил и ИИ возьмите одну отложенную выборку, которую не использовали при настройке.
Вымышленный расчёт: все 100 пар заранее размечены. Числа ниже иллюстрируют арифметику; это не результат продукта и не пороги приёмки.
| Результат проверки | Число пар |
|---|---|
| Предложены и подтверждены как дубли — TP | 9 |
| Предложены ошибочно — FP | 3 |
| Настоящие дубли пропущены — FN | 6 |
| Разные сущности правильно не предложены — TN | 82 |
| Всего | 100 |
Система предложила 12 пар: 9 верных и 3 ошибочных. Доля подтверждённых среди предложенных, или precision, равна 9 / 12 = 75%.
Всего в выборке 15 настоящих дублей: 9 найдены, 6 пропущены. Доля найденных среди известных дублей, или recall, равна 9 / 15 = 60%. Знаменатель здесь — все известные дубли выборки, включая пропуски.
Включайте в оценку весь путь: от первоначального отбора кандидатов до итогового предложения. Если пара потеряна при отборе, исключать её из подсчёта пропусков нельзя. Эти парные показатели также не доказывают безопасность объединения группы карточек.
Отдельно измеряйте время проверки сотрудником, затраты на обработку и ошибки фактически выполненных изменений. До пилота владелец процесса задаёт приемлемые значения с учётом последствий ложного объединения.
Продолжайте пилот, если выбранный подход выполняет согласованные критерии и даёт полезное дополнение к базовому. Если причина пропусков устранима, доработайте её и повторно проверьте результат. При отсутствии дополнительной пользы остановитесь на штатных средствах. Ошибочная запись или нарушение доступа требуют остановить запись и разобрать причину.
Что подготовить для обсуждения пилота с DYNAMICSUN?
Подготовьте обезличенные примеры и правила, по которым ответственный принимает решение. Для первой оценки полезны:
- название CRM, используемые интеграции и доступные операции;
- один выбранный тип ошибки и границы справочника;
- правила учёта компаний, филиалов и контактов;
- примеры подтверждённых дублей, разных сущностей и спорных пар;
- источники значений, ограничения доступа и передачи данных;
- ответственный за согласование, текущие показатели и критерии пилота.
Разделите готовые штатные функции CRM, настройку собственных правил и разработку интеграции ИИ. Это поможет обсуждать конкретный объём работ.
DYNAMICSUN предлагает оценку пилота ИИ-сотрудника под выбранный процесс с согласованием источников данных, прав и действий, требующих проверки человеком. Сценарий качества CRM требует отдельной оценки и проектирования.
В опубликованном проекте CRM для приёма заявок DYNAMICSUN проектировала рабочий экран под задачи операторов: найти клиента, создать заказ и посмотреть его статус. Это смежный опыт организации работы с карточками; он не подтверждает внедрение ИИ-дедупликации или достигнутые показатели очистки базы.
Опишите один сценарий качества данных CRM, подготовьте обезличенные примеры и правила учёта — запросите у DYNAMICSUN оценку пилота.
Частые вопросы
Можно ли объединять контакты по одинаковому телефону?
Одного совпадения недостаточно. В разобранном примере телефон общий, а похожие имена относятся к разным или пока не установленным людям. Сверьте личность по разрешённым дополнительным сведениям и подтверждению владельца данных. Неопределённую пару верните на уточнение.
Почему филиал может быть отдельной карточкой при одном юридическом идентификаторе?
Решение зависит от модели учёта. Если подразделению нужны отдельные договоры, ответственный или отчётность, сохраните карточку филиала и явную связь с головной организацией. Сначала утвердите это правило с владельцем CRM; совпадение идентификатора его не отменяет.
Нужен ли ИИ, если в CRM уже есть поиск дублей?
Сначала проверьте штатные средства и правила на контрольной выборке. Модель имеет смысл испытывать для оставшихся неоднозначных пар. Если она не улучшает согласованный результат с учётом нагрузки на проверяющего, используйте базовое решение.
Нужен ли доступ на изменение для первого пилота?
Для поиска кандидатов и подготовки очереди достаточно согласованного чтения необходимых данных. Запись вводите отдельным этапом после проверки полномочий, поддерживаемых операций, связанных данных и порядка восстановления. Само предложение исправления не должно открывать доступ на изменение.
Что делать, если карточка изменилась после согласования?
Перечитайте актуальные данные и сравните их с проверенным состоянием. Существенные изменения требуют новой оценки. Прежнее подтверждение относится к показанному набору полей и связей, поэтому автоматически переносить его на изменившуюся карточку нельзя.
Можно ли отменить ошибочное объединение?
Установите, какие данные и связи восстанавливает процедура вашей CRM, и проверьте её на тестовом примере. Возврат удалённой карточки ещё не доказывает восстановление всей истории связей и последующих действий. До допуска к записи согласуйте порядок разбора ошибки и ответственного.
Как понять, что система пропускает дубли?
Нужна размеченная выборка, содержащая также пары, которые система не показала. Сравните найденные дубли со всеми известными дублями этой выборки. Проверяйте и отбор кандидатов, и последующее сопоставление: проверка только предложений не показывает полноту всего процесса.
