В исходной таблице есть имя, телефон и никнейм. В CRM часть этих людей уже заведена, но данные распределены по разным полям. Загрузить файл несложно. Гораздо труднее решить, кого создать, с кем связать новую сделку и какую строку оставить на ручную проверку.
Импорт контактов в Битрикс24 стоит проектировать как последовательность решений по каждой записи. Итог «файл обработан» слишком неопределённый: за ним могут скрываться дубли, потерянные связи и контакты, которые система не смогла прочитать. Разберём процесс, результат которого можно проверить и безопасно продолжить после ошибки.
Сначала описываем результат переноса #
До подготовки файла определяют, какие объекты нужны в CRM: контакты, компании, сделки и связи между ними. Создать контакт и создать сделку — разные действия. Человеку, который уже есть в базе, может понадобиться новая сделка, но повторная загрузка того же файла не должна создавать её снова.
Также выбирают владельца каждого поля. Например, импорт может добавлять новый внешний идентификатор, но не должен без согласования заменять телефон, который менеджер проверил вчера. Для пустого значения отдельно определяют смысл: «нет данных» или «удалить существующее». Считать эти варианты одинаковыми опасно.
Хороший результат переноса — не только список созданных карточек. Это ещё и таблица соответствий исходной строки объектам CRM, отчёт о спорных совпадениях и понятное правило повторного запуска.
Телефоны, внешние коды и значения с ведущими нулями лучше обрабатывать как строки. Табличный редактор способен превратить идентификатор в число или изменить его отображение. Поэтому файл проверяют после сохранения и чтения тем инструментом, который будет выполнять импорт.
Для CSV заранее выбирают кодировку, разделитель и правила кавычек. Для XLSX — нужный лист, строку заголовков и допустимые типы ячеек. Формулы не стоит молча считать готовыми значениями: способ получения результата необходимо определить. Пустые строки, повторяющиеся заголовки и случайные итоги внизу таблицы не должны попадать в CRM как люди.
Перед записью полезен режим предварительного просмотра. Он показывает нормализованные значения, ошибки и предлагаемое действие. Менеджер видит проблему до создания карточек, а не после появления нескольких сотен дублей.
По каким признакам искать существующий контакт #
Устойчивый внешний идентификатор обычно полезнее имени. Но он должен иметь понятный источник: одинаковое значение из двух разных сервисов не обязательно обозначает одного человека. Для него задают пространство имён — например, конкретную исходную систему — и сохраняют связь с CRM.
Телефон и email помогают найти кандидатов. В Битрикс24 метод crm.duplicate.findbycomm ищет совпадения по этим типам коммуникаций. Он не выполняет произвольный поиск по никнеймам или другим пользовательским полям. Это ограничение указано в официальном описании .
Совпадение всё равно требует правил интерпретации. Один телефон может принадлежать семье, ресепшену или нескольким сотрудникам компании. Общая почта отдела тоже не доказывает тождество людей. Поэтому несколько кандидатов не следует автоматически объединять в один контакт.
Что делать с никнеймами и исторически неверными полями #
Если никнейм раньше записывали в поле сайта или email, сначала определяют, как распознать такие записи и перенести их в подходящее поле. У никнейма должен быть контекст платформы. Одинаковое написание в двух сервисах не гарантирует одного владельца, а само имя пользователя иногда меняется.
Для сопоставления по дополнительным полям может потребоваться отдельная выборка и приложение. Доступность поля и способ поиска проверяют через документацию и пробные запросы конкретного портала. Не стоит заранее обещать, что стандартный контроль дублей автоматически учтёт любую историческую запись.
В спорных случаях сотруднику показывают исходную строку и кандидатов: какие значения совпали, какие отличаются, когда обновлялись данные. Решение должно быть осмысленным: связать с существующим, создать новый контакт или отложить разбор. Простая кнопка «пропустить ошибку» теряет полезный контекст.
Как избежать повторного создания после сбоя #
Импорт хранит идентификатор партии и ключ исходной записи. После успешного создания контакта сохраняет его идентификатор, затем выполняет следующие необходимые действия. Если связь оборвалась между контактом и сделкой, повторный запуск должен продолжить работу с уже найденным контактом.
Для каждой строки полезно различать состояния: проверена, требует решения, контакт сопоставлен, сделка создана, завершена или ошибка. Точный набор зависит от задачи, но одного общего флага недостаточно. Особенно когда часть записей прошла, а часть остановилась из-за временной недоступности API.
Потеря ответа после запроса не означает, что запись не создана. Перед повтором нужно проверить журнал и результат по устойчивому ключу. Иначе технический повтор сам становится источником дублей. Механизм такого контроля нужно реализовать в импортёре; он не возникает только от использования REST.
Пробная загрузка и сверка #
Для пилота берут выборку с разными ситуациями: новый клиент, известный телефон, несколько совпадений, пустые контакты, никнейм и связанная компания. Проверяют не только число карточек, но и ответственных, воронки, связи и сохранение прежних данных.
- — Число исходных строк равно сумме завершённых, отложенных и отклонённых с объяснением.
- — Для каждой завершённой строки известны созданные либо найденные объекты CRM.
- — Повтор партии не создаёт повторные контакты и сделки.
- — Спорное совпадение не объединяет карточки без принятого решения.
- — Отсутствие значения не стирает действующие сведения без отдельного правила.
- — Сотрудник без нужных прав не получает доступ к полной выгрузке базы.
Отдельно планируют откат. Безусловно удалять всё, что затронул импорт, нельзя: после загрузки менеджеры уже могли добавить работу в карточки. Для исправления нужны журнал изменений и согласованный сценарий, который отличает созданные объекты от обновлённых.
Когда достаточно штатного импорта #
Если структура файла проста, поля соответствуют CRM, а правила сопоставления покрываются штатным механизмом, отдельная разработка может не понадобиться. Сначала проверяют этот вариант на пилоте. Приложение оправдано сложными ключами, нестандартными связями, повторяемой загрузкой или обязательным разбором неоднозначных записей.
Если источник продолжит регулярно передавать изменения, задача становится обменом, а не разовым импортом. Тогда нужно определить направление обновлений, удаление, конфликты и владельца данных. Это уже отдельная логика, и её не стоит прятать за обещанием «загрузить Excel».
Поможем перенести клиентскую базу в Битрикс24 #
Если в файлах смешаны контакты, есть дубли и непонятно, какие записи обновлять, обратитесь в NetLab. Проверим структуру базы, согласуем правила сопоставления, выполним пробную загрузку и сверим результат перед основным переносом. Обсудить перенос контактов в Битрикс24 .
