Дубли в amoCRM: как найти, объединить и предотвратить

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

Контакт, компания и сделка: разные виды повторов

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

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

Что сделать до первого объединения

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

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

Поиск дублей среди существующих сделок

В официальной инструкции amoCRM по поиску и объединению сделок описан поиск через меню «Ещё» в разделе «Сделки». Функция работает в браузере и требует полных прав на соответствующие операции. Предложения строятся на совпадениях телефонов и email связанных контактов. Среди действий есть объединение, пропуск и отметка, что записи не являются дублями. Перед подтверждением всё равно проверьте содержание заказа.

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

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

Контроль дублей входящих заявок

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

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

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

Как не размножить базу при импорте

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

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

Почему интеграция создаёт один заказ дважды

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

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

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

Кто отвечает за спорные данные

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

Какие сценарии проверить перед запуском

Проверяйте успешное совпадение и ситуации, где объединения быть не должно. Нужны новый заказ постоянного клиента, два сотрудника с общим номером, обращение по закрытой сделке, ошибочный email и одновременная заявка из двух каналов. Для каждого случая заранее запишите ожидаемый результат: число контактов, компаний и сделок, ответственный, задача и сохранённый источник. Без ожиданий тест сводится к субъективному «вроде работает».

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

Как поддерживать порядок после очистки

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