Перенос клиентской базы в CRM начинается с понимания структуры исходных данных. Если в одной строке смешаны компания, два человека, номер заказа и общий телефон, загрузка файла не превратит эти сведения в аккуратную историю клиента. Она лишь перенесёт неоднозначность в новое место.
Подготовка нужна, чтобы после перехода менеджер нашёл правильную компанию, актуальный контакт и действующее обязательство. Сначала следует определить сущности и связи, затем сопоставить поля и проверить пробную загрузку. Массовый перенос имеет смысл только после понятного результата пилота.
Определите, что именно переносится
Разделите как минимум компании, контактных лиц и отношения между ними. Один человек может представлять несколько площадок или работать с разными подразделениями. У компании может быть общий телефон, который не принадлежит одному конкретному контакту.
Сделки, обращения и открытые задачи — отдельный объём. Не рассчитывайте, что они восстановятся автоматически из комментария «ведём большой проект». Если эти данные нужны для продолжения работы, опишите их структуру и связи отдельно.
Также определите границы архива. Необязательно переносить все устаревшие сведения в активную рабочую очередь. Но решение об исключении должно быть явным: что сохраняется в доступном архиве, что не используется и почему.
Учебный пример исходного файла
Все числа условные. В исходной таблице 120 строк, потому что сотрудники добавляли новую строку при каждом контакте. После разбора выяснилось, что они описывают сорок компаний и семьдесят пять уникальных контактных лиц.
Семь из этих людей связаны с двумя компаниями, остальные шестьдесят восемь — с одной. Число связей: 7 × 2 + 68 = 82. Поэтому в подготовленном наборе будут сорок записей компаний, семьдесят пять записей контактов и восемьдесят две связи между ними.
Не нужно добиваться, чтобы в новой CRM оказалось ровно 120 карточек клиентов. Исходные строки не были единицей клиента. Часть строк повторяла сведения, часть фиксировала связь с дополнительной компанией.
При этом все 120 исходных строк должны иметь понятную судьбу: с какой новой записью связаны, объединены ли с другой или исключены по установленному основанию. Так можно найти происхождение спорного значения.
Сохраните исходные идентификаторы
До очистки добавьте каждой исходной записи устойчивый идентификатор. Он нужен для сопоставления, поиска ошибок и безопасной проверки повторного переноса.
Не используйте номер строки как единственное основание, если файл будут сортировать и редактировать. Отдельный идентификатор должен оставаться связанным с содержанием независимо от текущего положения.
Новая система может назначить свои номера. Сохраните соответствие старого и нового идентификаторов в рабочем регистре переноса. Это особенно важно для контактов, сделок и задач, которые должны связаться с нужной компанией.
Имя человека или название компании не всегда уникальны. Поиск дублей только по полному совпадению текста пропустит варианты написания, а объединение только по похожему имени может соединить разных людей.
Сопоставление полей до загрузки
Подготовьте описание для каждого поля:
- Источник: название столбца и смысл значения.
- Назначение: целевая сущность и поле.
- Формат: текст, дата, число, список или связь.
- Преобразование: как очищаются пробелы, разделители и обозначения.
- Пустое значение: допустимо ли оно и что означает.
- Конфликт: какое основание определяет актуальное значение.
- Проверка: как убедиться, что перенос сохранил смысл.
Пример строки: «Телефон контактного лица → контакт → телефон; значение хранится как текст; добавочный номер отделяется по согласованному правилу; общий телефон компании не назначается человеку без подтверждения».
Вторая строка: «Ответственный менеджер → владелец компании; сопоставляется по утверждённому списку сотрудников; неизвестные имена попадают в список исключений, а не автоматически назначаются случайному действующему менеджеру».
Очистка без потери смысла
Пробелы и разные формы записи обычно можно привести к общему виду. Но любое преобразование, которое меняет идентичность или смысл, требует осторожности.
Не удаляйте ведущие нули из идентификаторов. Не превращайте все похожие названия в одну компанию. Не подставляйте сегодняшнюю дату вместо неизвестной даты последнего контакта.
Если в одном поле находятся два телефона, разделите их только после проверки принятого формата. Если в комментарии описано обещание клиенту, выделите его в рабочую задачу или иной согласованный объект, сохранив исходное основание.
Неизвестное значение лучше оставить явно неизвестным, чем заполнить правдоподобной догадкой. Массовая загрузка делает ошибочную догадку особенно убедительной для следующего сотрудника.
Пробная партия на сложных случаях
Выберите небольшой набор, в котором есть не только простые записи. Включите компанию с несколькими контактами, человека с двумя связями, общий телефон, неизвестного владельца и действующую задачу.
В примере пилот содержит десять компаний, восемнадцать контактов и двадцать связей. Два контакта связаны с двумя компаниями, остальные шестнадцать — с одной: 2 × 2 + 16 = 20.
После загрузки проверьте количества отдельно по каждому типу. Затем откройте карточки и убедитесь, что связи направлены правильно. Совпадение итоговых чисел не исключает перестановку двух контактов между компаниями.
Проверьте поиск, отображение телефонов, владельцев и доступность исходного контекста. Менеджер должен суметь продолжить работу, а не только увидеть успешно завершённую загрузку.
Контрольный лист до и после переноса
До переноса:
- Исходный набор сохранён в неизменном виде.
- Определены сущности, связи и границы архива.
- Согласованы правила конфликтов и неизвестных значений.
- Подготовлен список исключений.
- Пробная партия проверена ответственными пользователями.
После переноса:
- Сверены количества компаний, контактов и связей.
- Проверены сложные случаи и действующие обязательства.
- Сохранён регистр соответствия идентификаторов.
- Ошибки имеют владельца и способ исправления.
- Определено, как обрабатываются изменения, возникшие во время перехода.
- Повторный запуск проверен отдельно и не предполагается безопасным без испытания.
Последний пункт важен: некоторые способы загрузки добавляют записи повторно. Другие обновляют найденные. Нельзя угадывать поведение по названию кнопки.
Если в ходе пилота обнаружена неверная связь, сначала исправьте правило сопоставления и проверьте все похожие случаи. Ручное исправление одной карточки не гарантирует, что при полной загрузке ошибка не повторится десятки раз.
Отдельно определите, кто принимает результат переноса от имени пользователей. Технический исполнитель проверяет загрузку и соответствия, а руководитель рабочей команды подтверждает, что сотрудники находят нужные контакты и действующие обязательства. Для спорных записей сохраняют список исключений с ответственными, чтобы нерешённые вопросы не исчезли после завершения основной загрузки.
Как организовать рабочий переход
Назначьте момент основного среза и порядок фиксации новых изменений. Если сотрудники продолжают править старую базу, нужен понятный способ перенести эти изменения после основной загрузки.
Не закрывайте доступ к исходным сведениям раньше, чем команда проверит рабочие сценарии. При этом определите единственное место текущего ведения данных после перехода, чтобы две базы не начали расходиться заново.
Спорные совпадения разбирайте по правилам работы с дублями CRM, а набор полей согласуйте с карточкой B2B-клиента.
Для обсуждения ЧатПлюс с ExtentLab подготовьте обезличенный фрагмент базы, схему сущностей и несколько сложных записей. На этом материале можно проверить формат загрузки, сохранение связей и условия перехода до работы с полной клиентской базой.