Как мы устранили дубли в amoCRM за 5 дней: решение, которое сэкономит ваше время и нервы

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

Мы разработали уникальное решение, использующее Google Таблицы, Apps Script и триггеры от F5* для автоматизации процесса импорта данных в amoCRM. Мы проверяем каждую строку в системе на наличие дублей и распределяем номера телефонов по соответствующим сущностям: мобильные номера — в Контакты, городские — в Компании. Это решение обеспечивает полную автономность и безопасность, позволяя клиенту самостоятельно управлять импортом данных в любое время.

1. Загрузка данных:
Клиент загружает данные через специальную URL-страницу, просто вставив ссылку на Google Таблицу и нажав кнопку «Запустить загрузку». Оттуда они передаются в amoCRM через специально разработанный скрипт. Скрипт написан на языке Apps Script и интегрирован с amoCRM через API. Структуру импортируемых таблиц можно настроить индивидуально под клиента.

2. Проверка на дубли:
Каждая строка данных при импорте проверяется на наличие дублей на стороне триггеров amoCRM. Анализируются номера телефонов и email-адреса, чтобы убедиться, что такие контакты или компании уже не существуют в системе клиента.
Проверка ведется не только по контактам, но и по компании.
Возможные сценарии:

• Если нет дубля по контакту и компании, то создаются обе сущности и связываются между собой;
• Если есть компания, но нет контакта — то создается контакт и, что очень важно, привязывается к соответствующей компании;
• Если компании с имеющимися данными еще не существует в amoCRM, то она создается с указанными контактами (мобильный номер), email-адресом и другими сущностями.

3. Разделение данных:
Если в базе есть как мобильные, так и городские номера телефонов, они автоматически разделяются: мобильные номера добавляются в сущность «Контакт», а городские — в сущность «Компания». Это особенно важно для клиентов, которые используют WhatsApp Business API (WABA) для рассылок.

4. Нормализация номеров:
Одной из ключевых особенностей решения является нормализация номеров телефонов. Это особенно актуально для российских номеров, где часто встречаются разные форматы: например, номер может начинаться с +7, 7 или 8. Наш скрипт автоматически приводит все мобильные номера к единому международному формату (+7).

• Для российских номеров: все номера, начинающиеся с 8 и 7, автоматически заменяются на +7. Единый формат упрощает работу с данными и предотвращает дубли из-за разных форматов записи.
• Для международных номеров: номера других стран, состоящие из 12 символов (в свою очередь российские номера включают только 11 символов), остаются без изменений. Они сохраняются в исходном формате, что исключает ошибки при работе с иностранными клиентами.
• Ручной ввод: Даже если менеджер вручную вводит номер, система автоматически нормализует его, чтобы избежать ошибок и дублей. Тем самым исключается человеческий фактор, что особенно важно в крупных компаниях с большим количеством менеджеров.

В процессе работы над проектом выявилась дополнительная потребность клиента в особом формате автоматизации импорта данных, а именно импорта данных с оффлайн-мероприятий (выставки, встречи, конференции), а также других внешних клиентских баз:

• Необходимо обрабатывать данные посетителей, собранных на мероприятиях и другие клиентские базы, учитывая уже существующие сделки в amoCRM.
• Если у компании, представленной в данных, уже имеется активная сделка на стадии продажи или сопровождения, создание новой сделки не требуется. Вместо этого ставится задача менеджеру в рамках имеющейся сделки.
• Только при отсутствии активных сделок происходит создание новой сделки.

В процессе работы над проектом выявилась дополнительная потребность клиента в особом формате автоматизации импорта данных, а именно импорта данных с оффлайн-мероприятий (выставки, встречи, конференции), а также других внешних клиентских баз:

• Необходимо обрабатывать данные посетителей, собранных на мероприятиях и другие клиентские базы, учитывая уже существующие сделки в amoCRM.
• Если у компании, представленной в данных, уже имеется активная сделка на стадии продажи или сопровождения, создание новой сделки не требуется. Вместо этого ставится задача менеджеру в рамках имеющейся сделки.
• Только при отсутствии активных сделок происходит создание новой сделки.

Сложности и решение задачи «со звездочкой»
Эта задача выявила ряд проблем в структуре данных клиента:

• Дубликаты компаний: Часто встречались ситуации, когда в amoCRM уже существовали две идентичные компании, но одна из них имела активные сделки, а другая — нет. Это создавало сложности при автоматической проверке и принятии решений.
• Отсутствие четкой стратегии объединения данных: Вопрос о том, какие данные оставлять при объединении дубликатов, требовал участия руководства клиента (РОПа).

Для решения этих проблем было принято следующее:

1. Маркировка дубликатов: Дублирующие компании помечались, и задача ставилась РОПу/менеджеру клиента для дальнейшего анализа и принятия решения.
2. Автоматическая проверка сделок: Если находили активную сделку, в нее добавлялись новые данные (контакты, задачи и т. д.). Если активной сделки не было, создавалась новая.

Процесс импорта внешних баз осуществляется по ранее описанному пути («Как это работает», пункты 1−4), но на этапе проверки на дубли компаний на стороне триггеров amoCRM также производится проверка на наличие активных сделок

• Проверка на дубли осуществляется по телефону и электронной почте.
• Если найдены дубликаты, они помечаются, и ставится задача РОПу/менеджеру для последующего объединения. При чем в задаче сразу имеется ссылка, которая открывает фильтр, отражающий компании с таким же номером. Таким образом сотрудник переходит по ссылке и может сразу объединить компании учитывая содержание имеющихся дублей.
• Если найденная компания имеет активные сделки в двух определенных воронках, все возможные сущности, которые нам были переданы из выгрузки (теги, контакты и т. д.) прикрепляются к существующей сделке.
• Если активных сделок нет, создается новая сделка.

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

Отметим, что доработка для импорта внешних баз (задача «со звездочкой) потребовала 12 часов работы с учетом уже готового скрипта! Столько времени потребовалось на выстраивание логики, поиск сущностей и формирование сценариев.

Работа над решением продолжается. Мы активно занимаемся доработками, чтобы сделать процесс еще более удобным и универсальным.

Проблема дублей — одна из самых распространённых среди пользователей amoCRM. Особенно остро она стоит у компаний, которые:

• Работают с большими базами данных.
• Регулярно импортируют данные из внешних источников (например, после мероприятий или покупки баз).
• Используют интеграции с другими системами, такими как сайты, мессенджеры или CRM.

Решение Madison Consult универсально: оно легко адаптируется под любого клиента и различные бизнес-процессы; не только устраняет дубли, но и обеспечивает безопасность данных и их единообразие, а также автономность процессов.