Поиск возможных дублей в CRM
Сценарий помогает найти записи с разным написанием компании, домена или контакта, не удаляя данные автоматически. Сначала применяются точные правила, затем ИИ объясняет только пограничные совпадения и показывает противоречия.
Цель и граница автоматизации
Что меняем
Сценарий помогает найти записи с разным написанием компании, домена или контакта, не удаляя данные автоматически. Сначала применяются точные правила, затем ИИ объясняет только пограничные совпадения и показывает противоречия. Практическая цель этой схемы - получить очередь пар с основаниями, конфликтами и предлагаемой основной записью в форме, которую ответственный может проверить по исходным данным. Скорость полезна только вместе с понятной границей ответственности и журналом изменений.
Где останавливается ИИ
Не поручайте модели объединение или удаление карточек. История, согласия, сделки и владельцы должны сохраняться до решения администратора CRM. ИИ завершает работу на стадии подготовки и разметки. Любое действие, которое меняет учетные данные, публикует текст, связывается с человеком или создает обязательство, выполняется только после явного подтверждения владельца процесса.
Эта страница построена как проектная схема. Сначала зафиксируйте цель и границу, затем опишите входы, переходы и результат. Такой порядок удобен, когда процесс только создается: команда может обсудить контракт до выбора конкретного конструктора автоматизаций.
Не начинайте с промпта. Большинство опасных ошибок появляется в маршрутизации, правах доступа, повторах и неясном владельце решения. Промпт становится полезным после того, как система уже умеет отклонить плохой вход и сохранить проверяемое основание.
Владелец, журнал и критерий готовности
До технической настройки назначьте одного владельца сценария «Поиск возможных дублей в CRM». Он утверждает справочники, определяет допустимые исключения и решает, когда результат «Очередь пар с основаниями, конфликтами и предлагаемой основной записью» можно использовать дальше. Администратор конструктора отвечает за доставку и права, а владелец процесса - за смысл полей и решение человека. Эти роли могут выполнять разные сотрудники.
В журнале храните идентификатор входа, время каждого шага, версию промпта, использованную модель, статус проверки и причину остановки. Не записывайте полный чувствительный текст только ради отладки. Готовность пилота подтверждается не одним удачным примером, а серией обычных, пограничных и ошибочных случаев, для которых известен ожидаемый маршрут и возможен безопасный повтор. Отдельно зафиксируйте, кто получает уведомление, если проверка не завершена в установленный срок или очередь исключений растет.
Какие входные данные подготовить
Нормализовать ключи
Телефон, email, домен и регистрационные идентификаторы приводятся к единому формату обычными правилами. Для входа 1 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Найти точные совпадения
Запрос создает кандидатов по устойчивым ключам и исключает записи, которые уже были проверены человеком. Для входа 2 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Разобрать пограничные пары
ИИ сравнивает названия и адреса, перечисляет совпадения и конфликты, не вычисляя окончательную вероятность личности. Для входа 3 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Показать историю
Администратор видит сделки, согласия, заметки, владельцев и даты обеих карточек до выбора основной записи. Для входа 4 сохраняйте источник, время получения и технический идентификатор. Пустое или противоречивое значение должно остановить обычную ветку, а не заменяться догадкой.
Как работает сценарий
Нормализовать ключи
Телефон, email, домен и регистрационные идентификаторы приводятся к единому формату обычными правилами.
Найти точные совпадения
Запрос создает кандидатов по устойчивым ключам и исключает записи, которые уже были проверены человеком.
Разобрать пограничные пары
ИИ сравнивает названия и адреса, перечисляет совпадения и конфликты, не вычисляя окончательную вероятность личности.
Показать историю
Администратор видит сделки, согласия, заметки, владельцев и даты обеих карточек до выбора основной записи.
Объединить штатным инструментом
После подтверждения используется функция CRM с журналом, а отказ от пары сохраняется против повторного предложения.
Две карточки компании с общим телефоном приемной
В CRM есть ООО Альфа и Альфа Сервис. У записей одинаковый телефон приемной, разные домены, разные владельцы и активные сделки по разным направлениям. Название и контакт дают высокий внешний признак сходства, но автоматическое объединение способно смешать две организации группы.
Точное правило создает пару, а смысловое сравнение перечисляет совпадающий телефон и противоречащие домены, реквизиты и сделки. Администратор помечает записи связанными, но не дублями. Решение сохраняется, чтобы следующая проверка не предлагала слияние снова.
Если карточки содержат разные согласия на коммуникацию или историю удаления контакта, объединение блокируется до проверки ответственного. Модель не выбирает основную запись по числу заполненных полей и не переносит email между юридическими лицами без подтвержденного основания.
Что должно появиться на выходе
Поле 1: Ключи нормализованы правилами
Результат должен позволять проверить условие «ключи нормализованы правилами» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Поле 2: Точные совпадения найдены до ИИ
Результат должен позволять проверить условие «точные совпадения найдены до ии» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Поле 3: Проверены сделки и согласия
Результат должен позволять проверить условие «проверены сделки и согласия» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Поле 4: Конфликты показаны явно
Результат должен позволять проверить условие «конфликты показаны явно» без повторного чтения всего массива. Рядом храните основание, статус ручной проверки и дату последнего изменения.
Правила решений и остановки
- Остановить обычный маршрут, если возникает риск: Однофамильцы и общие корпоративные контакты создают ложные пары.
- Передать ответственному случай, в котором возможно следующее: Слияние способно потерять согласие, владельца или историю сделки.
- Не публиковать и не записывать итог автоматически, пока не исключен риск: Повторный запуск может снова предложить уже отклоненную пару.
- При повторном запуске использовать устойчивый идентификатор и сохранять ранее подтвержденную версию результата «Очередь пар с основаниями, конфликтами и предлагаемой основной записью».
Что передать модели
Промпт задает формат черновика, но не заменяет проверки входных данных и ограничений платформы. Скопируйте его как основу и подставьте собственный справочник полей.
Сравни две карточки как кандидатов в дубли. Верни matching_fields, conflicting_fields, name_variants, missing_checks и review_note. Не утверждай, что это один человек или одна компания, не выбирай запись для удаления и не объединяй данные.
Контрольные примеры для пилота
Запустить минимально заполненный пример для сценария «Поиск возможных дублей в CRM» и убедиться, что недостающие поля отмечены явно.
Повторить один вход дважды и проверить, что автоматизация не создает вторую запись и не стирает ручные исправления.
Передать противоречивые данные, связанные с риском «Однофамильцы и общие корпоративные контакты создают ложные пары.», и проверить переход к ручному разбору.
Искусственно отключить одно действие связки «CRM + нормализация полей + правила совпадения + ИИ + очередь слияния» и проверить уведомление, журнал ошибки и безопасный повтор.
Проверочный список
Какие показатели отслеживать
Измеряйте путь до подтвержденного результата «Очередь пар с основаниями, конфликтами и предлагаемой основной записью», а не только скорость ответа модели.
Считайте изменения фактов, категорий и решений отдельно от стилистических правок. Так видно, где схема действительно ошибается.
Ошибки доставки, дубли и остановленные входы относятся к надежности автоматизации и не должны смешиваться с качеством текста.
Основные риски
Однофамильцы и общие корпоративные контакты создают ложные пары.
Слияние способно потерять согласие, владельца или историю сделки.
Повторный запуск может снова предложить уже отклоненную пару.
Что уточнить перед внедрением
С чего начать безопасный пилот?
Возьмите небольшой исторический набор без лишних персональных данных, оставьте все действия в режиме черновика и сравнивайте результат с решением владельца процесса. Для связки «CRM + нормализация полей + правила совпадения + ИИ + очередь слияния» заранее проверьте права доступа и журнал ошибок.
Когда можно уменьшить ручной контроль?
Только после того, как накоплена выборка по типовым и сложным случаям, отдельно посчитаны смысловые исправления и подтвержден безопасный откат. Даже тогда исключения из раздела рисков остаются у человека.