Миграция данных в CRM: поля, дедупликация и загрузка

Что такое миграция данных и где чаще всего возникают проблемы

Миграция данных в CRM - это перенос клиентской базы и истории работы из старых файлов и систем в новую CRM так, чтобы информация осталась полной и пригодной для ежедневной работы. Обычно переносят не только телефон и email, но и контекст: кто с кем связан, на какой стадии продаж находится сделка, какие были звонки и встречи.

Чаще всего переносят контакты, компании, сделки и активности (задачи, звонки, письма, встречи, комментарии). Важно понимать: если загрузить только «справочник», менеджеры увидят карточки без истории и начнут вести работу параллельно в старом месте.

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

Самые неприятные риски обычно такие:

• потеря связей «контакт-компания-сделка»
• неверно назначенные ответственные и права доступа
• мусор в полях (обрывки, лишние пробелы, странные статусы)
• невозможность повторить перенос так же аккуратно второй раз

Успех миграции можно измерить четырьмя признаками: полнота (все нужные записи на месте), точность (поля и статусы соответствуют правилам), сохраненные связи (ничего не «осиротело»), повторяемость (есть понятный план и настройки, чтобы загрузить обновления или переехать еще раз).

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

Инвентаризация источников и требований перед стартом

Перед миграцией важно понять, что именно вы переносите и зачем. Большая часть проблем появляется не на этапе загрузки, а из-за того, что источники и правила не были зафиксированы заранее.

Сначала составьте полный список источников и решите, какие из них считаются «истиной», а какие будут только дополнять. Обычно данные лежат в нескольких местах: Excel-файлы, старая CRM, почта, ERP, формы на сайте, иногда еще мессенджеры или таблицы отдельных менеджеров. Если не договориться, откуда брать приоритетные значения (например, телефон или название компании), вы получите конфликты и много ручной работы.

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

• Владелец данных (обычно руководитель продаж или CRM-администратор)
• Эксперт по источнику (например, бухгалтерия для ERP)
• Тот, кто утверждает правила (руководитель направления)
• Исполнитель миграции (внутренний специалист или подрядчик)

Параллельно зафиксируйте обязательные для бизнеса поля. Например, без «ответственного» лид или сделка может оказаться бесхозной, без «стадии» воронка сломается, без «источника» пропадет аналитика. Ориентируйтесь не на то, «как устроено в системе», а на то, как вы работаете каждый день.

И еще одна вещь перед стартом: объем. Посчитайте количество записей и уникальных сущностей (контактов, компаний, сделок) и оцените дубликаты. Простой ориентир: 20 000 строк в Excel не означают 20 000 контактов. Эти цифры нужны, чтобы спланировать сроки, тестовую загрузку и объем ручной проверки.

Модель данных: как связать контакты, компании и сделки

Перед переносом данных договоритесь о простой модели: какие сущности вы переносите и как они связаны. Обычно базовый набор - контакт, компания и сделка. Ошибка на этом шаге приводит к «сиротским» сделкам без клиентов или к дублям, которые потом трудно разгрести.

Самая понятная схема выглядит так: контакт может работать в компании, а сделка ведется либо с компанией, либо с конкретным контактом (в зависимости от правил CRM). Но в реальной жизни один человек может быть связан с несколькими компаниями (например, совмещает роли или раньше работал в другом месте), а у компании может быть много контактов. Эти случаи нужно явно описать заранее.

Ключи, по которым вы узнаете одни и те же записи

Определите, какие поля считаются «якорями» для связи и поиска совпадений. Лучше сразу расставить приоритет:

• Внутренний ID из источника (если он стабилен и сохраняется при выгрузках)
• Email (часто надежен для B2B, но бывает общий)
• Телефон (удобен, но часто меняется или записан по-разному)
• ИИН для контакта и БИН для компании (если у вас они собираются)
• Комбинация: ФИО + компания + телефон, когда уникальных ключей нет

Как хранить историю и сложные связи

Отдельно согласуйте, что делать с заметками, комментариями, статусами и датами. Иногда историю лучше переносить как события (с датой и автором), а не как один «длинный» комментарий.

Пример: если в старой базе контакт «Айгуль Н.» связан с двумя компаниями, заранее определите правило по умолчанию (например, активная компания по последней сделке) и куда класть вторую связь (дополнительная компания, роль, примечание). Так вы сохраните смысл данных и не сломаете отчетность по сделкам.

Схема сопоставления полей: как ее составить без сюрпризов

Схема сопоставления полей - главный документ для миграции. Она отвечает на вопрос: что именно из источника попадет в CRM, куда и в каком виде. Если пропустить этот шаг, вы почти гарантированно получите «кривые» даты, пустые статусы и разорванные связи между контактами, компаниями и сделками.

Удобнее всего делать сопоставление в таблице. В ней нужны не только названия полей, но и правила преобразования:

• Поле источника (название колонки в Excel, CSV или базе)
• Объект и поле в CRM (Контакт: телефон, Компания: ИИН/БИН, Сделка: сумма)
• Тип данных (текст, число, валюта, дата/время, список)
• Правило преобразования (обрезать пробелы, заменить значения, объединить колонки)
• Комментарий по загрузке (обязательное поле, заполняем по умолчанию, не грузим)

Отдельно зафиксируйте форматы: даты (например, ДД.ММ.ГГГГ), время, часовой пояс, разделители в числах (1 000,50 или 1,000.50). Одна и та же «01.02.2025» может стать 1 февраля или 2 января - типичная причина тихих ошибок.

Заранее решите, какие значения должны стать справочниками в CRM: статусы сделок, источники лидов, отрасли, типы клиентов. Например, если в файле есть «Холодный/Теплый/Горячий», не переносите это как свободный текст. Иначе появятся варианты с опечатками.

Продумайте, что делать с данными, для которых в CRM нет поля. Обычно есть три безопасных варианта: создать новое поле, временно положить значение в «Примечание/Комментарий» или не загружать (но обязательно указать это в таблице).

Небольшой пример: в источнике есть «Ответственный менеджер» как ФИО, а в CRM нужен пользователь. В сопоставлении прямо пишут правило: «ФИО -> логин» по заранее подготовленному списку соответствий. Если совпадения нет - назначить на дежурного и добавить пометку для ручной проверки.

Подготовка данных: очистка и нормализация перед загрузкой

Перед импортом стоит привести таблицы к единому и предсказуемому виду. Это скучный шаг, но именно он чаще всего спасает от «кривых» карточек, лишних дублей и хаоса в отчетах.

Начните с телефонов. Выберите один стандарт и придерживайтесь его везде: код страны, формат разделителей, обработка добавочных. Например, решите, что все номера хранятся как +7XXXXXXXXXX, а добавочный записывается отдельным полем или единым правилом (например, "доб. 123"). Тогда поиск и дедупликация по телефону будут работать стабильно.

С email тоже важна дисциплина: приводите к нижнему регистру, убирайте пробелы, отделяйте реальные адреса от служебных и пустых значений. Частая проблема: в поле email лежит «нет», «-», «test@test» или общий ящик вроде info@. Такие значения лучше либо перенести в комментарий, либо пометить специальным признаком, чтобы не склеивать разных людей в один контакт.

ФИО и названия компаний нормализуйте по одному правилу: единый регистр, одинаковые кавычки, аккуратная работа с сокращениями (ТОО, ИП, LLC). Полезно заранее договориться, как писать «ТОО "Компания"» и что делать с вариантами типа «Компания, ТОО».

Перед загрузкой сделайте короткий контроль:

• удалите тестовые записи и автосгенерированный мусор (например, «123», «qwe», «нет данных»)
• найдите дубли столбцов и «почти одинаковые» поля (Телефон, Phone, Моб.)
• проверьте обязательные поля и заполните по правилам (стадия сделки по умолчанию, валюта, ответственный)
• выровняйте справочники (города, отрасли, статусы) до одного набора значений
• зафиксируйте решения в документе, чтобы одинаково чистить все источники

Если сделать это заранее, импорт пройдет быстрее, а данные будут выглядеть одинаково в контактах, компаниях и сделках.

Правила дедупликации: как не удалить нужное

Дедупликация нужна, чтобы после миграции у вас не было трех «одинаковых» клиентов с разной историей. Главный риск - случайно склеить разных людей или компании и потерять важные детали.

Сначала определите, что значит «уникальная запись». Для контактов обычно достаточно 1-2 надежных признаков, но лучше сразу описать, какие варианты считаются совпадением:

• Email (если корпоративный - почти всегда самый надежный)
• Телефон в нормализованном виде (один формат для всех)
• Связка ФИО + компания (как запасной вариант)
• Дополнительный идентификатор из источника (ID из ERP/сайта)
• Статус «ключевой контакт» (чтобы не слить случайно)

Дальше решите, что делать при конфликте полей. Например, в одной записи телефон актуальный, а в другой - должность. Заранее зафиксируйте «правило главного значения»: брать последнее обновление, брать из доверенного источника (например, ERP) или хранить оба значения в разных полях (рабочий и личный телефон).

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

Для компаний правила отличаются: одинаковое название не всегда значит одно и то же. Надежный ключ - БИН. А для групп компаний полезно завести отдельное поле «Группа/холдинг», чтобы не склеить бренд и юрлицо.

Чтобы не ошибиться на «похожих» данных, задайте порог похожести (например, совпало 2 из 3: название, телефон, адрес) и отправляйте такие пары в ручную проверку. Это особенно важно, когда база большая и данные приходят из разных источников.

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

Правильный порядок загрузки важен не меньше, чем сама очистка. Если загрузить сделки раньше, чем компании и контакты, CRM либо создаст «пустые» связи, либо начнет плодить дубликаты, пытаясь угадать, к кому привязать запись. В миграции обычно работает простой принцип: сначала справочники и «родители», потом «дети».

Самый надежный сценарий: сначала загрузите компании, затем контакты, и только потом сделки. При этом в каждой сущности должен быть внешний ID (из исходной системы), который вы не меняете между этапами. Тогда связи строятся не по названию или телефону (они могут отличаться), а по точному ключу.

Чтобы связи восстановились без ручной правки, заранее решите, какие поля отвечают за привязки:

• В контакте храните внешний ID компании (или отдельное поле «Company External ID»).
• В сделке храните внешний ID компании и, если нужно, внешний ID контакта.
• Если в CRM «главный» контакт в сделке один, выберите правило: по роли (ЛПР), по последней активности или по отмеченному флагу в исходных данных.
• Для владельца сделки согласуйте логику заранее: переносите конкретного менеджера, назначайте по региону или по источнику лида.

Перед загрузкой сделок проверьте, что стадии и вероятности совпадают с вашей воронкой. Частая ошибка - перенести названия стадий текстом, когда в CRM они хранятся как коды. Результат: сделки оказываются в «неизвестной» стадии или падают в первый этап по умолчанию.

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

Пример: если в исходной таблице сделка привязана к «ТОО Альфа» по названию, а в CRM компания уже есть как «Альфа, ТОО», то привязка по названию сломается. Если же в компании и в сделке есть один и тот же внешний ID, связь восстановится автоматически, даже при разном написании.

План миграции по этапам: пошаговая схема

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

Этап 1: тест и настройка правил

Начните с небольшого, но показательного набора: 200-500 записей по контактам, компаниям и нескольким сделкам. Обязательно сохраните копию в отдельном файле, чтобы можно было сравнить «до/после» и откатить изменения.

Дальше действуйте так:

• Загрузите тестовый набор в тестовую среду или в изолированный сегмент (например, один филиал или одна команда).
• Проверьте отчеты и выборки: сколько объектов создалось, сколько «потерялось», какие поля не заполнились, сохранились ли связи.
• По результатам поправьте сопоставление полей, форматы (телефоны, даты, валюты) и правила дедупликации.

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

Этап 2: основная загрузка и контроль

Основную загрузку делайте партиями, чтобы ошибки не распространялись на всю базу сразу. Удобные разрезы - по регионам, по диапазонам дат или по источникам данных.

• Загружайте партиями и фиксируйте результаты: сколько записей добавлено, обновлено, объединено.
• Проведите постпроверки (контрольные отчеты, поиск дублей, проверка связей «сделка-компания-контакт») и только потом открывайте доступ пользователям.
• Зафиксируйте процедуру: шаблон файла, правила, кто отвечает за правки и как подключать новые источники, чтобы следующий перенос не начинался с нуля.

Частые ошибки и ловушки при переносе данных

Одна из самых болезненных ошибок - загрузить сделки, не сохранив связи с контактами и компаниями. В итоге менеджер видит сделку, но не понимает, кому звонить и с кем велись переговоры. А отчеты по воронке и источникам начинают показывать неправильную картину.

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

Еще одна ловушка - импорт справочников (статусы сделок, отрасли, источники, типы клиентов) без согласования значений. Если в исходных данных есть «Переговоры», «переговоры» и «Переговоры » (с пробелом), после импорта вы получите три разных статуса. Это ломает аналитику и усложняет работу.

Ошибки, которые встречаются чаще всего и обычно дорого стоят:

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

Отдельный риск - отсутствие плана отката и журнала изменений. Реальный пример: команда импортировала 20 000 контактов, а через день выяснила, что часть имен и должностей подтянулась из старого файла. Без лога непонятно, что именно поменялось, а без отката приходится исправлять вручную.

Перед каждым импортом полезно зафиксировать простые правила: какие поля считаются «истиной», что обновляем, а что никогда не трогаем, и как ведем лог загрузок (дата, файл, кто запускал, сколько записей изменено). Это экономит часы, когда что-то пошло не так.

Быстрый чеклист контроля качества после загрузки

После загрузки легко выдохнуть и идти дальше, но 30-60 минут контроля обычно экономят дни разборов с продажами. Этот чеклист подходит для любой миграции и помогает быстро понять, где «поехали» поля или связи.

Проверьте по порядку:

• Сверьте количество записей с планом: отдельно контакты, компании и сделки. Сравните итог в CRM с тем, что было в файлах или в старой системе, и зафиксируйте расхождения (например, «минус 12 компаний из-за пустого ИНН»).
• Оцените дубли: сколько дублей было найдено до загрузки и сколько осталось после. Отдельно запишите, сколько записей объединили и по какому правилу.
• Проверьте связи: у контакта должна быть привязка к компании (если это правило вашей модели), у сделки должен быть контакт или компания, стадия и воронка. Быстро найдите 5-10 «сиротских» записей без связей и выясните причину.
• Сделайте ручную выборку 20-50 записей из разных источников. Для каждой записи проверьте имя, телефон, email, компанию и последнюю активность. Если из 30 проверок 3-4 ошибки одного типа, это уже системная проблема сопоставления.
• Проверьте форматы и справочники: даты (не перепутаны ли день и месяц), суммы и валюты, ответственные, источники лидов, статусы. Частая ошибка - «Ответственный» загрузился текстом вместо пользователя, а валюта ушла в пустое значение.

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

Реалистичный пример сценария: миграция для отдела продаж

Отдел продаж переезжает в новую CRM. Данные лежат в двух местах: Excel-файл с 12 000 строк (лиды за 3 года) и старая CRM, где есть компании и часть истории по сделкам. Цель простая: собрать одну воронку продаж, чтобы менеджеры видели актуальные контакты, компании и активные сделки, а руководитель мог доверять отчетам.

Сначала команда фиксирует, что именно переносим. Например: из Excel - контакты и «сырые» сделки (статус, сумма, источник), из старой CRM - компании и текущие сделки по ключевым клиентам. Исторические заметки решают не тянуть целиком, а перенести только последние 6 месяцев, остальное оставить в архиве.

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

• Контакты: основной ключ - телефон в нормализованном виде (только цифры). Если телефона нет, тогда email. Если нет обоих, тогда ФИО + компания (как «мягкое» совпадение для ручной проверки).
• Компании: BIN/БИН, если есть. Если нет, тогда ИНН/БИН из договора или точное название компании после нормализации (убрать «ТОО», кавычки, лишние пробелы).

Дальше решают, как хранить связи. В одной компании может быть 3-10 контактов (директор, бухгалтер, ИТ, закупки). А у одного контакта может быть несколько сделок (прошлые закупки и текущий запрос). Поэтому делают так: компания - «родитель», контакты привязываются к компании, а сделки привязываются к компании и, при наличии, к основному контактному лицу по сделке.

Чтобы не спорить в день загрузки, распределяют ответственность. Продажи подтверждают правила стадий воронки, обязательные поля и приоритет источников (что считать «правдой», если в Excel одно, а в старой CRM другое). Поддержка или администратор CRM отвечает за шаблоны импорта, проверку форматов дат/сумм и протокол ошибок.

В конце фиксируют итоги письменно: сколько компаний, контактов и сделок загрузили, по каким правилам объединили дубликаты, сколько записей ушло в список «на ручную доработку» (например, 640 контактов без телефона и email) и какие поля решили оставить пустыми до следующего этапа. Это экономит недели разбирательств, когда менеджер спрашивает: «Почему у клиента две карточки?» или «Куда делась сделка?».

Следующие шаги: как закрепить результат и не испортить данные снова

После миграции самый частый откат происходит не из-за импорта, а из-за того, что люди продолжают вводить данные по-разному. Поэтому закрепите договоренности письменно и назначьте ответственных.

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

• какие поля обязательны для контакта, компании и сделки
• что считается уникальным (email, телефон, ИИН/БИН, домен)
• какие значения допустимы в справочниках (статусы, источники, отрасли)
• кто имеет право создавать новые поля и менять справочники
• как обрабатываются спорные случаи (дубликат с разными владельцами, разные реквизиты)

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

Чтобы данные не «поплыли» через месяц, нужен простой регламент ввода: единый формат телефонов, правила заполнения ФИО, запрет на свободный текст там, где должен быть список. Хорошая практика - раз в неделю быстрый контроль качества по 20-30 свежим записям и разбор типовых ошибок с командой.

Отдельно оцените, какие интеграции реально нужны, иначе CRM начнет расходиться с другими системами:

• почта и календарь (история коммуникаций)
• телефония (звонки и записи)
• ERP/бухучет (реквизиты и оплаты)
• BI и отчетность (единые показатели)
• сайт и формы (источники лидов)

Если не хватает времени или компетенций, имеет смысл привлечь системного интегратора, особенно если параллельно нужно выстроить интеграции и поддержку. Например, GSE.kz (gse.kz) как технологический производитель и системный интегратор может помочь с инфраструктурой, интеграционными задачами и дальнейшей технической поддержкой, чтобы правила работы с данными закрепились не «в презентации», а в ежедневных процессах.